Infolunch Presenation

The main takeaway from the talk seemed to be that RAMCloud should be into two separate layers:

1. The storage layer, offering maybe a blob key, value model (or block access?)
2. Library layer, which can be used to implement many different data models, and other functionality such as trust and indexing

It was even suggested that RAMCloud should just expose the storage layer to a traditional RDBMS application which would just use this in the place of a disk.

A number of interesting points were mentioned:

• It was pointed out the the type of logging we propose is already being done on a smaller scale by in memory data bases.
• Also, how we implement durability depends on how how we handle single object vs multiple object transactions (a la Google Megastore).
• We could use RAID at the level of racks, where a rack would play the role of one disk in a RAID system
• Facebook computes joins from data in their data base and then caches the result in memory. They are looking at using Flash instead of disk.
• In a large RDBMS system like OracleDB, more and more memory is being set aside for communication buffers, which leaves less space for storing the actual data. Low latency transactions would drastically reduce the amount of space required for the communication buffers
• A question was raised about the frequency of access to some of the data in the RAMCloud. If it is only being accessed once in a while, why should it live in memory?