Skip to content
Snippets Groups Projects
Commit 25fdf880 authored by Peter J. Keleher's avatar Peter J. Keleher
Browse files

auto

parent 58be3ac0
No related branches found
No related tags found
No related merge requests found
......@@ -9,87 +9,101 @@
- expensive
- passing mention that CORFU doesn't scale past 20 servers in two adjacent racks
- impossible (consistency w/ partitions)
- single sequencer works well for small clusters, doesn't scale w/ network diameter
![](fuzzyLog.png)
## Approach
- two causes of partial ordering
- data sharding
- geo-replication
**color:** updates to a single shard, made of multiple chains
## linear scaling from:
- storing each color on a different replica set -> appends to single color in one phase
- serializable isolation for multi-color appends
- failure atomicity
- lazy cross-region sync
**chains:** totally ordered set of updates from a single region. Chains connected by causal dependencies.
Captured in the fuzzy log:
Each server has:
- latest copy of local chains
- stale prefixes of other chains
<img src=fuzzyLog.png width=500>
**node append:**
- node added to local chain of specified color
- w/ outgoing cross-links to *last node seen by client of each remote chain* (same color)
- can be atomically appended to multiple (local?) colors, **transaction across shards**
## Abstraction
- **color:** updates to a single shard, made of multiple chains
- **chain:** totally ordered set of updates from a single region, single shard. Chains connected by causal dependencies.
- chains within a color connected by causal cross-links
"toggle between strong and weak consistency during partitions by switching regions"
Each region has:
- latest copy of local chains
- possibly stale prefixes of other chains
linear scaling from:
- storing each color on a different replica set -> appends to single color in one phase
- serializable isolation for multi-color appends
- failure atomicity
- lazy cross-region sync
Application approach:
- apps partition data across shards
- weaken consistency by not using synchronous coordination on critical paths
**Client API:**
<img src=fuzzyAPI.png width=500>
![](fuzzyAPI.png)
- `new_instance`: adding color to local
- `sync`: plays all local nodes not seen by app's previous sync, ordered by chain and cross-edges (causal)
- `append`: added to end of local totally-ordered chain, cross-edges to tail of each other chain (edges from a node define a snapshot)
- `trim`: GC nodes prior to snapshot
- `sync`: plays all local nodes not seen by client's previous sync, ordered by chain and cross-edges (causal)
- `append`: added to end of local totally-ordered chain, cross-edges to tail of other local chains
- `trim`: GC nodes prior to a snapshot
![](fuzzyEvolution.png)
**deets:**
- node added to local chain of specified color
- w/ outgoing cross-links to *last node seen by client of each remote chain* (same color)
- can be atomically appended to multiple (local?) colors (**transaction across shards**)
----
## Implementation
- each color a single partition
- each partition replicated using *chain-replication*
- battery backed-up ram for servers
- local append to single color one phase (send it to the chain replication)
- local append to multiple colors requires two phases (Skeen's)
- logical clocks
- *phase 1:* send out multicast w/ proposed timestamp
- replies return local timestamps
- *phase 2:* send msg again w/ max of local or returned timestamps
- order at all destinations with new timestamp
![](fuzzySkeen.png)
---
<img src=fuzzyEvolution.png width=500>
*Any protocol that provides a total order consistent with a
linearizable order (i.e, if an update B starts in real time after
another update A completes, then B occurs after A in the total order)
is subject to unavailability during network partitions.*
## Semantics
- two `append` operations same color from different regions only
ordered if one already seen by client issuing the other
- never any conflicts when updates to same color by different regions merge
- only partial orders
- not clear how (if) we get eventual consistency
- operations in a single region are serializable
- linearizable iff operations to a single color (chain)
- not externalizable if multiple colors
Is this true?
"toggle between strong and weak consistency during partitions by switching regions" ???
----
## Apps
- LogMap
<img src=fuzzyMaps.png width=600>
- LogMap (corfu)
- single region, single color
- `get` waits until a sync that started after sync issue, then accesses local state
- `put` appends to log, then waits for `sync` to show it applied before returning
- poor scalability, performance, availability
- ShardedMap
- single region, *multiple* color
- says linear scaling with linearizable put/get ops
- linear scaling with linearizable put/get ops
- why? scaling because can scale colors with num servers
- AtomicLog
- multiple colors, which are serializable (because underlying ops are serializable)
- atomic multi-puts (no gets)
- multiple colors, which are serializable (because underlying ops
are serializable), not linearizability
- TxMap
- wants *strict serializability* (externalizable)
- speculative intention *commit* appends
- servers playing the intention node append *yes/no* for a specific color based on
presence of conflicting ops im log between the original appends and the speculative commits
- other servers only apply transaction if they see a *yes* for each color
presence of conflicting ops im log between the original appends
and the speculative commits (tango)
- other servers only apply transaction if they see a *yes* for every used color
- CRDTMap
- CRDT: *conflict-free-replicated-data-type*
- CRDT: *convergent-free-replicated-data-type*
- *causal* consistency
- single color, async replication of remote chains
- **convergence** through
- **convergence** through *observed-remove* sets
- not immediately clear how a CRDT set applies to convergence here
- CAPMap
- consistency
- strong when to partition
- strong when no partition
- causal otherwise
- routes put through proxy in a *primary* region, if avail.
- RedBlueMap:
......@@ -97,21 +111,29 @@ Is this true?
- blue ops not
## Multiple-color append
- to local chains
- operations within a single region are serializable
- appends in some serial order
- linearizable if to a single color
- not necessarily externalizable if to multiple colors
Difference between LogMap and ShardedMap?
## Implementation
- each color a single partition
- each partition replicated using *chain-replication*
- battery backed-up ram for servers
- local append to single color one phase (send it to the chain replication)
- local append to multiple colors requires two phases (Skeen's)
- logical clocks
- *phase 1:* send out multicast w/ proposed timestamp
- replies return local timestamps
- *phase 2:* send msg again w/ max of local or returned timestamps
- order at all destinations with new timestamp
- very reminiscent of paxos w/ prepare and accept phases
<img src=fuzzySkeen.png width=500>
---
Regions vs machines?
*Any protocol that provides a total order consistent with a
linearizable order (i.e, if an update B starts in real time after
another update A completes, then B occurs after A in the total order)
is subject to unavailability during network partitions.*
Guarantees of durability?
### Durability?
- when is an update "committed"?
## Comments, Questions
- (patrick) colors maybe difficult to use
notes/fuzzyAPI.png

307 KiB | W: | H:

notes/fuzzyAPI.png

541 KiB | W: | H:

notes/fuzzyAPI.png
notes/fuzzyAPI.png
notes/fuzzyAPI.png
notes/fuzzyAPI.png
  • 2-up
  • Swipe
  • Onion skin
notes/fuzzyEvolution.png

414 KiB | W: | H:

notes/fuzzyEvolution.png

615 KiB | W: | H:

notes/fuzzyEvolution.png
notes/fuzzyEvolution.png
notes/fuzzyEvolution.png
notes/fuzzyEvolution.png
  • 2-up
  • Swipe
  • Onion skin
notes/fuzzyLog.png

312 KiB | W: | H:

notes/fuzzyLog.png

510 KiB | W: | H:

notes/fuzzyLog.png
notes/fuzzyLog.png
notes/fuzzyLog.png
notes/fuzzyLog.png
  • 2-up
  • Swipe
  • Onion skin
notes/fuzzyMaps.png

632 KiB

notes/fuzzySkeen.png

236 KiB | W: | H:

notes/fuzzySkeen.png

137 KiB | W: | H:

notes/fuzzySkeen.png
notes/fuzzySkeen.png
notes/fuzzySkeen.png
notes/fuzzySkeen.png
  • 2-up
  • Swipe
  • Onion skin
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment