This page addresses issues related to naming and indexing objects in RAMCloud. In other words, what are the various mechanisms an application can use to retrieve objects stored in RAMCloud? The choices fall into three general classes:
- Naming: each object has a unique identifying name, such as a 128-bit global identifier, or a multi-part name such as (application identifier) + (table identifier) + (primary key). The name-based lookup returns either zero objects or one object.
- Indexing: the system may provide separate structures that allow objects to be located quickly based on their contents, e.g. "find all student records for students who have grade point averages greater than 3.0". An indexed lookup can return any number of objects.
- Search: return a collection of objects whose contents match a given set of criteria, which can be simple or general. The difference between search and indexing is not very crisp, but search is likely to be more flexible in the criteria that can be specified, but it may require scanning every element (for some definition of "every"), whereas indexing typically implies a table that makes lookups fast.
Naming
Assuming each object has a unique name, what form might that name take and what advantages and disadvantages are associated with that form?
- Single global identifier: large flat namespace with all objects for all applications in the same namespace.
Miscellaneous Additional Topics
- Should indexing be provided by RAMCloud, or implemented as a service about it?
- Seems important enough that it should probably be built into RAMCloud.
- Probably needs to be customizable to meet needs of different applications. For example, perhaps the application computes the value(s) on which to index particular items, and RAMCloud simply implements the low-level index lookup.
- Indexing should be much easier for RAMCloud than for a disk-based database: no need to reorganize the data to match the index.