System Design Cases
Partitioning Strategies
Стратегии партицирования: hash, range, composite, geographic + hot key проблемы и live resharding (Pinterest pattern). 4 сценария.
Partitioning strategies: access path, ownership и migration
Слово partitioning используют для разных вещей. PostgreSQL table partitioning делит одну logical table на physical child tables и позволяет pruning/lifecycle operations. Distributed sharding размещает ownership ranges на разных узлах и требует routing, membership, migration и обработки partial failure.
Выбор ключа
| Стратегия | Хорошо для | Главный риск |
|---|---|---|
| range | range scans, retention windows | monotonic hot tail |
| list | небольшой стабильный набор категорий | skew и рост списка |
| hash | point lookup по high-cardinality key | range scatter, один hot key |
| composite | locality внутри tenant/entity | один giant tenant всё равно hot |
| explicit directory | movable tenants/ranges | catalog availability и epoch correctness |
PostgreSQL pruning зависит от совместимости predicate с partition bounds, а не просто от наличия index. Distributed router должен использовать versioned token/slot/directory map; hash(key) modulo live node count вызывает массовый remap при membership change.
Сценарии
Range partition соответствует запросу по event_date и retention. Это может происходить внутри одного database server; автоматически fault isolation или horizontal writes не появляется.
Immutable tenant_id хэшируется в стабильное ownership space. Catalog version/epoch защищает от двух владельцев во время движения диапазона.
Hash распределяет разные keys, но celebrity key остаётся на одном owner. Для commutative/mergeable writes можно добавить bucket suffix. Цена: read fan-out, merge, ordering и миграция bucket count. Для arbitrary transaction это не бесплатный fix.
Безопасная схема: consistent snapshot, запись log position, idempotent backfill, ordered CDC replay, checksum/count validation, CAS ownership epoch, cutover и rollback window. Бесконечный dual-write без authority rule создаёт divergence.
Математика skew
Среднее keys/shard не является capacity guarantee. Пусть total 1M RPS равномерно делится на 100 shards, но один key даёт 200K RPS. Его owner получает минимум эти 200K независимо от среднего 10K. Нужны heavy-hitter metrics и workload-shaped tests.
Migration invariants
- в каждый epoch у key один authoritative writer;
- copied row имеет version и idempotent apply;
- CDC order определён per key/range;
- stale router получает redirect/error, а не пишет старому owner;
- cutover обратим до удаления source;
- cross-shard constraint имеет явный coordinator или изменённую модель данных.
Связанные темы
Первичные источники
- PostgreSQL partitioning: https://www.postgresql.org/docs/current/ddl-partitioning.html
- Cassandra Dynamo architecture: https://cassandra.apache.org/doc/latest/cassandra/architecture/dynamo.html
- DynamoDB partition key design: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html
- DynamoDB write sharding: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-sharding.html