...
- Traditional SQL approach:
- Indexes are defined in terms of fields stored in a table.
- RAMCloud automatically maintains indexes once defined.
- RAMCloud must parse objects in a table in order to extract fields for indexing.
- This may be more transparent than the approach above; on the other hand, a client-level library may be able to manage indexes just as transparently as this, but using the approach above.
- Requires the server to parse objects, which seems undesirable.
- Same as "minimal" approach, but allow a "primary" index for table, with the objects guaranteed to be co-located on the same server as the index.
- The index would provide a form that returns objects as well as identifiers.
- No need for clustered indexes, where the objects are stored as part of the index: since everything is in RAM, prisoner with a server can retrieve the object extremely quickly once it knows its identifier.
- If our RPCs are fast enough, do we need to worry about this optimization?
Distributed System Issues
Miscellaneous Notes
...
There are several issues that arise because applications run on different machines from the servers, and because there could be thousands of servers; data for a particular application or even a particular table may spread across multiple servers. This section assumes that object names are application-table-id
How does the client know which server to ask for an object, given its identifier?