InfoQLeela Kumili2 min readintermediate
Uber Redesigns M3DB Sharding with Subclusters to Limit Failure Impact
Summary
Uber reworked M3DB's shard placement by grouping nodes into fixed-size subclusters, each owning a disjoint shard range, to bound the blast radius of node failures. A greedy shard‑move algorithm (O(S log S) + O(S×N)) handles scaling while preserving existing placement tooling.
- Subclusters partition a cluster into equal‑sized groups; each group owns a unique shard slice, limiting a single node failure to affect at most 1/subcluster of the data.
- Scaling adds a new subcluster and greedily selects shards to move, sorting candidates (O(S log S)) and simulating load impact (O(S×N)) to avoid extra rebalancing passes.
- The approach requires equal instance weights, subcluster size multiples of the replication factor, and does not support dynamic replica‑factor changes via AddReplica.
- Uber kept the original instance‑level placement API, avoiding a massive bootstrap and preserving compatibility with existing operational tooling.
Ops teams managing large time‑series databases need predictable failure isolation and low‑overhead scaling, which this subcluster model directly addresses.
6/10
