Resource Information Retrieval Using SENS A Scalable and Expressive Naming System

Resource Information Retrieval Using SENS A Scalable and Expressive Naming System tài liệu, giáo án, bài giảng , luận vă...

Resource Information Retrieval Using SENS A Scalable and Expressive Naming System Hoaison NGUYEN1 , Hiroyuki MORIKAWA2 and Tomonori AOYAMA3 College of Technology, Hanoi University School of Frontier Sciences, The University of Tokyo Research Institute for Digital Media and Content, Keio University Abstract We design a scalable and expressive naming system called SENS, which can retrieve information of computing and content resources distributed widely on the Internet by exact queries and multi-attribute range queries over resource names Our system utilizes a descriptive naming scheme to name resources and a multi-dimensional resource ID space for message routing through the overlay network of name servers (NSs) The resource ID space is constructed on the overlay network based on CAN routing algorithm We propose a novel mapping scheme between resource names and resource IDs, which can preserve the locality of resource IDs while still achieving a good degree of load balancing regarding resource information distribution We also propose a multicast routing algorithm to deliver resource information and a broadcast routing algorithm to route query messages to corresponding NSs at small cost Our simulation results show that our system can achieve good routing performance and load balancing Introduction At present, to provide autonomous information systems such as web services, ubiquitous computing systems[1] or Grid computing systems [2] with resource information, the general approach is to publish the description of resources to a directory service MDS-2 provides directory services for Grid computing systems It uses LDAP [4], a hierarchical directory service, as a uniform interface for accessing and managing information about the status of Grid computing resources For Web services, Universal Description, Discovery and Integration (UDDI) [3] is used to discover services A service provider describes its service using WSDL and publish the description to UDDI directory service Service consumers will ask UDDI directory service for requested services However, conventional directory services can only provide exact query function, but not support rich query functions such as range query Since the evolution of the Internet now brings us the ability to access huge number of ubiquitous computing resources, we consider that a scalable and expressive information retrieval services is essential for autonomous information systems We design a scalable and expressive naming system called SENS to provide a resource information retrieval service based on resource names In our system, a descriptive naming scheme that names each resource by a tuple of attribute/value pairs is used Resource information is stored at a large number of name servers (NSs) Our system retrieves resource information by exact queries (i.e query information of a resource whose resource name is the same as the query name) and multiple-attribute range queries (i.e querying information of resources whose names have attribute values satisfying a query range) It routes query messages to NSs that are responsible for queried resource names Our challenge is to design a message routing protocol on the overlay network of NSs to achieve scalable and efficient resource information distribution and query Our SENS system constructs a high-dimensional resource ID space (i.e DHT key space) on the overlay network of NSs and map resource names to the resource ID space such that the locality of resource names in the resource ID space and the load balancing are both maintained Message routing for resource information queries is performed based on the locality of resource names We propose a multicast routing algorithm to deliver resource information and a broadcast routing algorithm to route query messages to corresponding NSs at small cost Our simulation results show that our system can achieve good routing performance and load balancing The rest of this paper is structured as follows We present the background of our research in Section 2, the design of our system in Section Section describes our simulation and the results Section discusses the application of our SENS system and Section presents conclusions and future works 2.1 Background Related works Several works such as INS[7] or ENS [8] have challenged an expressive naming system with the approach of routing messages based on resource names However, this approach is not scalable since the size of routing table will become unacceptably large when the number of resources increases Recently, Distributed Hashing Tables (DHTs) such as CAN[9], Chord[10], etc attract lots of attention since they can offer a promising solution for scalable message routing on overlay networks However, DHTs realize range queries with very large overhead because their consistent hashing function maps resource names in a range of attribute values to a large number of DHT keys To resolve this problem, a locality preserving hash function is utilized to map each attribute/numerical value pairs of a resource name to a DHT key [12–14] The resource information location and query resolution is performed based on DHT keys mapped by attribute values corresponding to one attribute in the query name However, this approach does not scale well because the distribution of attribute/value pairs in resource names is often skewed NSs responsible for popular attribute/value pairs will suffer from heavy load of resource information registrations and queries 2.2 CAN routing We utilize CAN routing [9] as a message routing algorithm on the overlay network of NSs The reason of using CAN is that in addition to the advantages of a DHT routing algorithm, CAN routing can construct a d-dimensional resource ID space on the overlay network of NSs CAN routing is performed as followed The resource ID space is partitioned into hyper-rectangles, called zones Each NS is responsible for a zone When a new NS joins the overlay network, it will choose an initial point Pi in the resource ID space and send a request to an existing NS responsible for the zone within which the point Pi lies The existing NS will split in half, retaining half and handing the other half to the new NS Destination node Sending node Routing table Fig A sample of 2-dimensional CAN routing The NSs maintain a coordinate routing table that holds the address and the zone of its neighbor NSs Two NSs are neighbors if their zone overlaps along d − dimensions and abut along one dimension Using its coordinate routing table, a NS routes a message towards the NS responsible for the destination ID by simple greedy forwarding to the neighbor NS whose zone is closest to the destination ID (Fig 1) CAN routing algorithm can achieve good routing performance on the overlay network of NSs As shown in [9], in a d-dimensional resource ID space with N NSs with d is a small number, the size of a coordinate routing table is O(d) and the path length between two NSs is O(N 1/d ) In the case of a high-dimensional resource ID space with d > log2 N , if the space is divided along the dimension determined by a fixed cyclical ordering of the dimensions, the size of a coordinate routing table and the path length between two NSs will be O(logN ) [15] 3.1 Design of SENS Overview Our system achieves expressiveness on resource naming by utilizing a descriptive naming scheme which names a resource by a tuple of attribute/value pairs For example, a computer is named as: (string OS = “linux”, string CPU-name = “Pentium 4”, int CPU-clock (Mhz) = 1000 , int memory (MB) = 1024,int harddiskunusedspace (GB ) = 20 , int network-bandwidth (Mbps) = 1000 ) The attribute includes a data type and a name The data type (e.g string, integer, Boolean) will decide a type of value that an attribute value can take The name of attributes expresses the semantics of (attribute/value) pairs Each kind of resources has a set of attributes used for naming The number of attribute/value pairs in a resource name may be dozens of pairs In the case of an exact query, a NS queries information of a resource that has the same resource name as the queried name In the case of a range query, a NS queries information of resources that have resource names satisfying query ranges of attribute values A query range is expressed by the use of inequality operators (>, vj then Hv (vi ) > Hv (vj )[12] An example of a locality preserving hashing function is (v − vmin ) ∗ (2m − 1) Hv (v) = , (vmax − vmin ) where vmax and vmin are the maximum and minimum values that the attribute value may take In the case of an attribute value of string type, a uniform hash function is used as Hv All resource names that match a range query will be mapped into a segment of the resource ID space, limited by the hash values of the upper and lower limit of queried value ranges in each dimension If a resource name matches a range query, its attribute values will be between the upper and lower limit of the value range corresponding to each attribute Since attribute values associated with an attribute will be mapped to coordinate values in the same dimension and the mapping between an attribute value and a coordinate value is locality-reserved, each coordinate value of the resource ID will be between the hash values of the upper and lower limit of queried value ranges in each dimension Our mapping scheme is not injective Several resource names with different attribute/value pairs may be mapped to the same resource ID However, the resource ID does not need to be unique since the resource information is identified by the resource name, not the resource ID When looking up a query resource ID, the NS will check the resource name before returning the lookup result of the queried resource ID If multiple attributes in a resource name are hashed to the same value (e.g Ha (attri ) = Ha (attrj ), the corresponding attribute values will be mapped to multiple coordinate values in the same dimension (i.e a set of collided coordinate values) In this case, to preserve the locality property, the resource name is mapped to multiple resource IDs, each of them contains a set of collided coordinate values For example, a resource name is identified by a tuple of six attribute-value pairs as shown in Fig and its attributes attr1 , attr5 are hashed to the same value Ha (attr1 ) = Ha (attr5 ) = and attributes attr3 , attr6 are hashed to the same value Ha (attr3 ) = Ha (attr6 ) = In this case, since {v1 , v5 } and {v3 , v6 } are two sets of collided coordinate values, the resource name will be mapped to four resource IDs: (v1 , v3 ),(v1 , v6 ),(v5 , v3 ),(v5 , v6 ), each of them contains two values from each set Resource information will be replicated and delivered to NSs that are responsible for these resource IDs Large number of collided coordinate values will force a large amount of resourceIDs to be generated The probability that a collision occurs depends on the number of attribute/value pairs in a resource name To limit the number of resource IDs per resource name, the number of attribute/value pairs in a resource name should be limited to a reasonable value If a resource has the number of attribute/value pairs that is over the limited number, the set of attribute/value pairs should be divided to multiple sets of attributes which correspond to multiple resource names The way of dividing resource names is out of the scope of this paper 3.3 Load balancing The number of resource IDs distributed to a zone that a NS is responsible depends on not only the volume of the zone but also the number of the default value that coordinate values of a zone contain It is because in a mapping between a resource name and a resource ID, the default value will be assigned to a number of coordinates values which are not mapped with any hash value of attribute values To keep the gap between the numbers of resource IDs stored in each NS to be small, for each zone assigned to a NS, the number of coordinate values containing default value and the volume of the zone should be in inverse proportion We simply realize this requirement by randomly assigning the default value to a number of coordinates of each initial point Pi , which is assigned to a NS when it newly joins the overlay network As a result, the probability that a zone whose coordinates contain a large number of default values is split will be high and therefore, the volume of such a zone will be small 3.4 Resource information distribution A resource ID is mapped to a point P of the resource ID space and information of the resource is delivered to the NS that owns the zone within which the point P lies If a resource name is mapped to multiple resource IDs, information of the resource will be replicated at NSs responsible for these resource IDs If a NS is responsible for several resource IDs of the same resource, only one copy is replicated at the NS To deliver information of a resource to multiple NSs responsible for resource IDs, we propose a multicast routing algorithm based on spanning binomial tree ([2,4],[2,4],[2,4]) ([0,2],[2,4],[2,4]) (0,3,3)({1}) (3,3,3)({1}) ({0|1|3},{0|1},{0|3|4}) ({0|1|3},{0|1},{0|3|4}) ([0,2],[0,2],[2,4]) ([2,4],[0,2],[2,4]) (0,0,3)({1}) ({0|1|3},{0|1}, {0|3|4}) Middle NS ([0,2],[0,2],[0,2]) Agent NS ([2,4],[2,4],[0,2]) (0,3,0)({2}) ({0|1|3},{0|1}, {0|3|4}) (3,3,0)({2}] ({0|1|3},{0|1},{0|3|4}) ([2,4],[0,2],[0,2]) (3,0,0)({3}) ({0|1|3},{0|1},{0|3|4}) (0,0,0)({3}) ({0|1|3},{0|3},{0|3|4}) Message forwarding ([0,1],[0,1],[0,1]) The zone that a NS is responsible for multicast dimension (0,0,0)({0}) ({0|1|3},{0|3},{0|3|4}) destination ID resource IDs Fig Multicast routing protocol for sending information of a resource to NSs responsible for resource IDs (SBT) [16] In our algorithm, only one registration message is sent to each NS responsible for resource IDs of a resource name Thus, our multicast routing algorithm only sends minimum amount of messages to deliver information of a resource to corresponding NSs The algorithm is performed as follows The resource IDs corresponding to a resource name will construct a hypercube in the resource ID space The SBT is constructed on the hypercube (Fig 4a) and the message is routed from the root node of the SBT to nodes in lower level Supposing that the resource IDs corresponding to a resource name are expressed as ({v11 , , v1n1 }, , {vi1 , , vini }, , {vd1 , , vdnd }) where {vi1 , , vini } is the set of coordinate values in ith dimension (i ∈ [1, d]) The registration message containing information of the resource is first delivered to the NS responsible for the resource ID created from lowest values of each list (i.e (v1n1 , , vi1 , , vd1 )) This NS becomes the root node of the spanning binomial tree The NS creates new destination resource IDs, which correspond to lower level nodes of the SBT and then forwards the message to these destination resource IDs The NSs receiving the message will create another destination resource IDs based on the SBT and relay the message recursively (Fig 4b) 3.5 Query resolution In the case of an exact query, the agent NS (i.e the NS that the query host sends the query message) will map the query resource name to queried resource IDs and select the nearest query resource ID as the destination resource ID The query message including the queried resource name will be sent to the destination resource ID based on the CAN routing algorithm The NS responsible for the resource ID will lookup its database to find the queried information and send the information back to the agent NS In the case of a range query, an agent NS will map the query range to a range query segment in the resource ID space A query message will be broadcasted to all NSs whose zones overlap the segment NSs receiving the query message will check their database to find the information of resources whose names match the query ([0,2],[2,4],[2,4]) ([0,2],[0,2],[2,4]) ([2,4],[2,4],[2,4]) ([4,6],[2,4],[2,4]) ([2,4],[0,2],[2,4]) ([4,6],[0,2],[2,4]) ([2,4], [0,2], [0,2]) d=3, dr=0 d=3, dr=1 d=1, dr=1 ({1},{1}) ([1,5],[1,3],[1,3]) ({2},{1}) ([1,5],[1,3],[1,3]) ([0,2], [0,2], [0,2]) ([0,2], [2,4], [0,2]) ([4,6], [0,2], [0,2]) ([2,4], [2,4], [0,2]) d=2, dr=1 d=1, dr=1 d=1, dr=1 d=1, dr=1 ([4,6], [2,4], [0,2]) ([2,4], [2,4], [2,4]) ([0,2], [0,2], [2,4]) d=1, dr=1 ([4,6], [0,2], [2,4]) d=1, dr=1 ([4,6], [2,4], [2,4]) ([0,2], [2,4], [2,4]) ([2,4],[2,4],[0,2]) ([4,6],[2,4],[0,2]) l=2, dr=1 ([2,4], [0,2], [2,4]) d=2, dr=1 ([0,2],[2,4],[0,2]) ({1},{1}) ([1,5],[1,3],[1,3]) d: broadcast dimension dr: broadcast direction ([0,2],[0,2],[0,2]) ({2},{1}) ([1,5],[1,3],[1,3]) ({3},{0}) ({3},{1}) ([4,6],[0,2],[0,2]) ([1,5],[1,3],[1,3]) ([1,5],[1,3],[1,3]) ({3},{0}) ([1,5],[1,3],[1,3]) broadcast dimension Message forwarding ({0},{0}) ([1,5],[1,3],[1,3]) broadcast direction query segment Agent NS a) The spanning polynomial tree created from a range query segment ([1,5],[1,3],[1,3]) b) Broadcast routing to NSs responsible for the range query segment ([1,5],[1,3],[1,3]) Fig Broadcasting routing algorithm for sending a query message to the range query segment based on spanning binomial tree To reduce the cost of broadcasting, we propose a broadcasting algorithm based on SBT to broadcast a query message to all NSs in a range query segment with minimum number of sending messages The number of messages to be sent is about the number of NSs in the range query segment The SBT is constructed on NSs in the query segment (Fig 5a) The query message is first sent to a NS in the range query segment by CAN routing algorithm The NS then forwards the query message to its neighbor NSs which correspond to lower level nodes in the SBT These NSs then recursively forward the query message to their neighbor NSs which correspond to lower level nodes of the SBT (Fig 5b) Evaluation We evaluate the performance of SENS by simulation from the following aspects – Routing performance: Logical hop count required to route a query message to a NS responsible for the query – System efficiency: Replication number of resource information corresponding to a resource name and number of NSs responsible for a query – The degree of load balancing: The number of resource information stored at each NS We implemented a simple simulator to evaluate our system We assume that the number of attribute/value pairs in a resource name varies from 10 to 20 We set the dimension number of the resource ID space to be 20 The default value is randomly set to 12 coordinate values of an initial point assigned to each NS when they newly join the overlay network The resource names are generated based on the Zipf dataset, which reflects the popularity of an attribute/value pair based on a parameter called a rank The probability that an attribute/value pair appears in a resource name is in proportion to 1/rα Here, r is the rank of the attribute/value pair and α is a constant number We set α as 0.9 and r as a random number between and the total number of attribute/value pairs Our data set has 400 attributes, each of which can take on 1024 values Exact queries and range queries are also generated based on the same Zipf dataset The next subsection shows our simulation results Routing performance 8 Evera ge routing hops for a n exa ct query Hop count (hop) Hop count 4.1 Size of a value range: 20% Size of a value range: 30% Evera ge pa th length Size of a value range: 40% 1000 5000 20000 NS number 100000 a) Path length and evarage logical hop count in the case of exact queries 12 Number of value rang es per query 16 b) Everage logical hop count for a range query in the case of range queries Fig Routing performance of SENS We first study the increase in the average path length (i.e average logical hop count required to route a message between two NSs) in the overlay network due to the increase of the number of NSs 100,000 messages are sent to random destination resource IDs from a randomly selected NS The simulation result (Fig a)) shows that the average path length increases on a logarithm scale of NS number In the case of a 100,000-node system, the average path length is about 6.9 hops Fig a) also shows the logical hop count required to route an exact query message to the NS responsible for the queried resource information The average logical hop count required to route an exact query message (5.0 hops in the case of 20,000-node system) to the corresponding NS is smaller than the average path length(5.9 hops in the case of 20,000-node system) It is because information of a resource may be replicated in a number of NSs and the nearest resource ID is always selected as the destination resource ID to delivery query messages We study the logical hop count required for a range query in 20,000-node SENS system by fixing the size of each value range to be 20%, 30%, 40% of the maximum coordinate value and increasing the number of value ranges to be queried As shown in Fig b), the average logical hop count required to route a range query message to responsible NSs increases only 1.3 hop when the number of value ranges to be queried increases from to 16 It means that our broadcast routing protocol can achieve good routing performance System efficiency Number of replications per name 10 10 10 12 14 16 18 20 Attribute/value pair number per resource name a) Average resource ID number and replication number corresponding to a resource name Size of a value range: 40% Size of a value range: 20% Size of a value range: 30% 100 100 Number of NS Average number of replication number per name Average number of resource ID s per name Number of resource per name 4.2 10 12 16 Number of value ranges per query b) Number of NSs to be responsible for a range query in the case of range queries Fig Evaluation result of system efficiency We study the average number of resource IDs and average number of replications per a resource name in 20,000-node SENS system As shown in Fig a), the resource ID number per resource name is large and the resource ID number increases on a exponential scale of the number of attribute/value pairs in a resource name However, because a NS may be responsible for a number of resource IDs of a resource, the replication number per resource name is relatively small For a 20-attribute/value pair resource name, the resource ID number per resource name is 94.7 while the replication number per resource name is 7.8 on average The average number of NSs to be queried in a range query increases exponentially with the number of value range per query (Fig b)) It is because the volume of query segment increases exponentially However, we consider that number of NSs to be queried is small enough to be viable In the case the number of value ranges is 10 and each value range is 20% of the value, the average number of queried NSs is 2.2 while in the case the number of value ranges is 12 and each value range is 30% of the maximum value, the average number of queried NSs is 7.1 4.3 Load balancing In order to evaluate the degree of load balancing in SENS system, we measured the number of resource names stored on each NS by delivering 1,000,000 resource names to 20,000-nodes SENS system Number of attribute/value in a resource name varies from 10 to 20 Fig 8.a shows the attribute/value pair appearance probability in resource names Fig 8.b shows the ratio of resource name number stored in each NSs to total name number Our simulation shows that even there are several attribute/value pairs which appear in resource names with high probability (about 13.96% of total number of resource names), the maximum number of resource names stored in a NS is not over 0.23 % of total number of resource names (Fig 8.b) 1.00% 0.10% 0.01% 10 100 1000 10000 100000 Attribute/value pair ID (a) 1.000% 1.000% 0.100% 0.100% 0.010% 0.010% Percentage of total queries(%) Percentage of total resource names (%) 0.001% 10 100 1000 10000 Percentage of total resource names (%) 10.00% Percentage of total queries (%) Percentage of total resource name (%) 100.00% 0.001% 100000 NS ID (b) Fig a) Attribute/value pair appearance probability in resource names b) Number of resource information stored in each NS Applications of SENS By the use of attribute/value pairs, our naming scheme can sufficiently express properties of resources and range queries for retrieving information of resources Descriptive naming schemes have been used in a number of conventional researches [8, 13, 14] We also consider that our naming system can provide an information retrieval service for existing naming schemes such as Resource Description Framework (RDF) [5] and Directory service [6] In the RDF, since the URI is not always known in advance, we must search information of resources including the URI based on the properties of resources Our system can rename such a resource with attribute/value pairs corresponding to property-types and property values of the resource The RDF name of a resource will be considered as a full name of the resource and will be kept in the database of naming servers as resource information for further searches (i.e search for resources whose full name satisfies given constraints) Our naming scheme can also express a resource that is named in a Directory service A hierarchical tree structure in Directory services can clearly express the relationship between attribute/value pairs, which is necessary when attribute names of different attribute/value pairs are very similar Our naming scheme can express the relation between attribute/values pairs by the use of attribute hierarchies For example, the format of audio and video for an audio/video converter can be expressed as (string audio.input.format = “AVI”, string audio.output.format = “wav”, string video.input.format = “mpeg2”, string video.output.format = “mov”) Conclusions We have proposed SENS naming system which can retrieve information of resources by exact queries and multi-attribute range queries over resource names In our system, resource information distribution and query are performed based on resource ID space constructed on the overlay network of NSs Our mapping scheme between resource names and resource IDs allows SENS system to realize exact queries and multiple-attribute range queries effectively but still achieve good load-balancing even in the case the distribution of attribute/value pairs in resource names is skewed We also propose a multicast routing algorithm to deliver resource information to corresponding NSs and a broadcast routing algorithm to send query messages to all NSs in the query segment with minimum cost Our simulation results validated the system’s routing performance and load balancing properties Our future work is to implement the SENS system in a test-bed system and develop applications for the SENS system Acknowledgment This work is supported partially by the National Fundamental IT research project “Modern Methods for Building Intelligent Systems” References M Satyanarayanan, ”Pervasive computing: Vision and Challenges” , IEEE Personal Communications, vol 8, no 4, pp 10-17, Aug 2001 I Foster, C Kesselman, J Nick, S Tuecke, ”Grid Services for Distributed System Integration”, vol 35, iss 6, IEEE Computer, June 2002 http://www.uddi.org M Wahl, T Howes and S Kille, “Lightweight Directory Access Protocol (v3)”, RFC 2251, Dec 1997 G Klyne and J Carroll, “Resource Description Framework (RDF): Concepts and Abstract Syntax”, http://www.w3.org/ TR/rdf-concepts/, W3C Recommendation, Feb 2004 W Yeong, T Howes and S Kille, “X.500 Lightweight Directory Access Protocol”, RFC 1487, July 1993 W Adjie-Winoto, E Schwartz, H Balakrishnan and J Lilley, “The Design and Implementation of an Intentional Naming Systems”, In P roceedings of ACM Symposium on Operating Systems Principles, Dec 1999 A Carzaniga, D Rosenblum and A Wolf, “Design and Evaluation of a Wide-Area Event Notification Service”, vol 19, no 3, ACM Transactions on Computer Systems, August 2001 S Ratnasamy, P Francis, M Handley and R Karp, “A Scalable Content-Addressable Network”, In P roceedings of ACM SIGCOMM’01, Aug 2001 10 I Stoica, R Morris, D Karger, M.F Kaashoek, H Balakrisnan, “Chord: A Scalable peer-to-peer lookup service for Internet applications”, In P roceedings of ACM SIGCOMM’01, August 2001 11 A Rowstron and P Druschel, “Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems”, In P roceedings of IFIP/ACM International Conference on Distributed Systems Platforms, Nov 2001 12 M Cai, M Frank, J Chen, P Szekely, “MAAN: A Multi-attribute Addressable Network for Grid Information Services”, In P roceedings of Fourth International Workshop on Grid Computing, Nov 2003 13 D Oppenheimer, J Albrecht, D Patterson, and A Vahdat, “Scalable Wide-Area Resource Discovery”, UC Berkeley Technical Report UCB//CSD-04-1334, 2004 14 A Bharambe, M Agrawal and S Seshan, “Mercury: Supporting Scalable MultiAttribute Range Queries”, In P roceedings of ACM SIGCOMM’04, 2004 15 C Tang, Z Xu and S Dwarkadas, “Peer-to-Peer Information Retrieval Using SelfOrganizing Semantic Overlay Networks”, In P roceedings of ACM Sigcomm 03, August 2003 16 S Johnsson and C Ho, “Optimum Broadcasting and Personalized Communication in the Hypercube”, vol 38, no 9, pp 1249-1268, IEEE Transaction on Computers Sep 1989 ... in the case attributes attr1 , attr5 are hashed to the same value a1 = a5 = and attributes attr3 , attr6 are hashed to the same value a3 = a6 = a hash function Hv hashes each attribute value from... Hv(val i ) attr i :val i : the i th attribute/value pair in the resource name Fig An example of a mapping between a resource name and a resource ID A resource name is mapped to a resource ID by assigning... 0.9 and r as a random number between and the total number of attribute/value pairs Our data set has 400 attributes, each of which can take on 1024 values Exact queries and range queries are also