|
|
|
|
|
|
by sh00s
2838 days ago
|
|
|
Some strengths of LogDevice include: - It's designed to work with a large number of logs (roughly equivalent to partitions in Kafka), hundreds of thousands per cluster is common. - Sequencer failover is very quick, typical failover time when a sequencer node fails is less than a second. - It supports location awareness and can place data according to replication constraints specified (e.g. replicate it in 3 copies across 2 different regions and 3 racks). - Because of non-deterministic data placement, it is very resilient to failures in terms of write availability. - If a node/shard fails, it detects the failure and rebuilds the data that was replicated to failed nodes/shards automatically |
|
|
I am happy to expand more on this point.
We have this concept of "node set" of a log which is the set of storage nodes available to receive record copies sent by the sequencer. It is typically made of 20-30 nodes in typical deployments at Facebook. Write availability is maintained as long as enough storage nodes in the node set are available to accept copies. When storage node failures are detected, the sequencer can just exclude these nodes from the list of potential recipients for new records. It does not need to update a view that needs to be synchronized with readers, which is a heavy-weight operation. This model allows preserving high write availability even if many nodes in the node set are unhealthy.
Additionally, this record copy placement flexibility allows the sequencer to quickly route around latency spikes on individual storage nodes, which helps guarantee low append latency.