Object Storage on CRAQ
Last updated
Was this helpful?
Last updated
Was this helpful?
Video:
Chain replication. The basic approach organizes all nodes storing an object in a chain, where the chain tail handles all read requests, and the chain head handles all write requests. Writes propagate down the chain before the client is acknowledged, thus providing a simple ordering of all object operations—and hence strong consistency—at the tail. The lack of any complex or multi-round protocols yields simplicity, good throughput, and easy recovery.
Apportioned queries: that is, dividing read operations over all nodes in a chain, as opposed to requiring that they all be handled by a single primary node.
Eventual Consistency in our system implies that writes to an object are still applied in a sequential order on all nodes, but eventually-consistent reads to different nodes can return stale data for some period of inconsistency (i.e., before writes are applied on all nodes).
Each node can store multiple versions on an object. When it receives a write, it's marked as "dirty". When it receives an ack from below it markes it as "clean". When handling a read, if the value is clean - return it. If it's dirty - check with the tail, return its version.
Read-heavy - load distributed mostly uniformly across all nodes in the chain. Life is good.
Write heavy - will need to check with the tail a lot. Not great, but tolerable.