# CS511 vCorfu

## Intro
- System design is all about trade-off.
- At the age of cloud, a system that is simultaneously scalable and consistency is difficult to achieve.

## Another design
- So a shared log system represent a point of design that we can have consisteny without compromising scalability.
- However, there is no free lunch, even though writing in shared log system provides high consistency and throughput, to achieve the consistency, shared log uses a technique call state machine replication and only log the updates. For example, the system will not log the new value of the counter, it will log the updates. The consequnce is that the client need to read all the updates to figure out the current value of counter. And it is expensive

## shared log basic operations
- Shared log system has 2 basic operations
- append(entry): put the entry at the end of the log and returns the address that was written at. The append interface adds an entry to the log and returns its position.

- read(address): Given an address and return the entry that was previously written to the log The read interface accepts a position in the log and returns the entry at that position. If no entry exists at that position, an error code is returned
- These operations really help to maitaion consistency since writer cannot overwrite one another
## Shared log: Compenents
Scalable shared log are composed of these three primary components.
How to append to a shared log?
- the client will contact the sequncer, and it will issue the next address.
- Using the layout, the client determine which replica it should write to
- the client then use the address from the sequencer issued it and replicate that log.
- This design enble clients to append to log at a high throughput without being bottlenecked by I/O

## Tango
In vCrofu, an object store is built on top of shared log system
- Client don't interact with the shared log directly, the interact with the objects
- Object are stored in virtualized log called stream
- Each stream contains a set of updates for the object
- For example, consider a counter object

## Comparison

Here’s the pictorial summary of the big idea for an imagined system tracking the last login time of users:
(a) shows a sequence of operations for two users, alice and nancy
(b) shows the logical table we’d like to present to clients with most recent login for each user
(c) illustrates a NoSQL store partitioning scheme which partitions state, each partition having its own replica(s).
(d) Shows how it might look with a shared log system such as Corfu, partitioning log ranges and then replicating those log partitions
(e) Shows the vCorfu approach – there is a shared log partitioned by log range as in Corfu, but the ‘replicas’ are materialized streams on a per-object basis, not direct copies of the log partition.

## What can we improve
- Client may need to read unnecessary updates in order to service requests.
- since Updates are ordered in the log temporary, update for a single objects might scatter across the log. A client might need to contact multiple nodes just to read a single object.

These 2 API enable shared log systems to operate at unlimited concurrency without sacrificing consistency. Since the writer can never overwrite one another.