Indexes, partitioning и sharding¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Версии в источниках: PostgreSQL 17, MySQL 8.4, Oracle 19c, Cassandra 5.0, Redis 7.4 и ClickHouse 25.8 либо явно названный сервис.

Механизм¶

Index ускоряет access path; partitioning разделяет логический объект на части; sharding размещает части на разных ownership domains/nodes. Эти механизмы могут сочетаться. PostgreSQL partitioned table остаётся внутри server cluster без встроенного распределённого write sharding.

flowchart LR
  Query --> Route[Shard routing]
  Route --> Prune[Partition pruning]
  Prune --> Access[Index or scan]
  Access --> Rows
  Route --> Fanout[Cross-shard coordination when needed]

Операция чтения или записи по шагам¶

Запрос tenant+time сначала маршрутизируется к shard, затем pruning выбирает partitions, затем index/scan читает blocks. Пропущенный tenant predicate может превратить точечный запрос в fan-out; пропущенный time predicate — в scan всех partitions. План надо читать по всем уровням.

Консистентность, отказ и восстановление¶

Unique constraint обычно имеет scope отдельного storage/partition/shard design. PG unique partitioned key должен включать partition columns; Cassandra primary key гарантирует адрес upsert, не global SQL uniqueness. Cross-shard transfer требует 2PC/Saga/другого business protocol, не двух независимых COMMIT.

Выбор, эксплуатация и ограничения¶

Range partitioning упрощает retention и range scans, hash — распределение; монотонный range key концентрирует active writes. Secondary global index добавляет координацию или eventual freshness. Rebalance требует migration routing, read/write ownership и защиты от дублирования.

Типичные ошибки проектирования¶

Выбирать shard key только по ровному распределению, забывая joins/transactions. Вопрос: поможет индекс на невыборочном status? Иногда нет: scan дешевле множества random lookups, а update cost останется.

Вопросы на собеседовании¶

Как доказать применимость механизма? Назвать invariant, scope, isolation/acknowledgement boundary, версию, допустимые interleavings и процедуру восстановления. Один успешный запрос или статическая диаграмма этого не доказывают.

Практические упражнения¶

Спроектируйте tenant/time routing с одним крупным tenant. Укажите scope uniqueness, число fan-out reads и migration protocol при удвоении shards.

Дополнительные источники¶

Политика версий и проверки. Статическая проверка статьи не является runtime/fault verification механизма.