...
- Single global identifier: large flat namespace with all objects for all applications in the same namespace.
- Looks simple and clean.
- Too unstructured; leaves too many problems to be solved by higher-level software, doesn't provide enough hooks for management.
- For example, need to be able to delete all data associated with an application.
- Need to associate access control information with every object.
- Result: system will have to create additional structures for this extra information; why not just design those structures in from the beginning?
- Lookups may be tricky: when an application starts up, how does it locate its own data? Certain identifiers reserved for special purposes?
- Are there any advantages to this approach?
- Hierarchical name, such as (application id) + (table id) + (record id).
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..
- Provides natural places to store metadata.
- Can reserve application id 0 for system information, table id 0 in each application for overall application information, etc.
- What is the right number of levels?
Indexing
One possibility: no indexing provided by RAMCloud
- Implement indexing as a service on top of RAMCloud.
- RAMCloud provides only name-based lookups?
- However, virtually every application will need some kind of indexing; probably better to build it into RAMCloud.
- Also, RAMCloud will need indexing itself (e.g., find the application named "Facebook").
Suppose RAMCloud implements indexing; a minimal approach is to separate the management of the indexes from the generation of index terms:
- Each table can have one or more named indexes associated with it.
- Indexes take two forms:
- Exact match (based on hash table)
- Ordered (based on trees, with keys that can be strings, integers, or floating-point numbers)
- Provide an extension mechanism for custom comparison functions?
- RAMCloud makes no association between index terms and fields in an object; application does this.
- Operations:
- addIndexEntry(objectId, index, term)
- Creates a new entry in an index associated with a particular table.
- "index" name and index associated with objectId's table.
- "term" is the value associated with this index entry (string, integer, etc.)
- findEntries(table, index, term)
- Returns object identifiers for all objects in a particular index for a particular table whose term matches "term".
- findEntries(table, index, term1, term)
- Returns object identifiers for all objects in a particular index for a particular table whose term lies between "term1" and "term2".
- addIndexEntry(objectId, index, term)
Miscellaneous Additional Topics
- 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.