Шардинг и партиционирование

Репликации мало

Репликация копирует весь датасет на каждый узел, так что масштабирует чтения и переживает отказы — но каждый узел всё ещё держит всё и принимает каждую запись. Как только данные не влезают на один диск или темп записи превышает то, что один лидер может впитать, копирование не помогает; надо дробить. Шардинг (горизонтальное партиционирование) делит датасет на непересекающиеся куски — шарды или партиции — и кладёт каждый на свой узел, так что каждый держит лишь 1/N данных и принимает лишь свою долю записей.

(О словах: «партиционирование» внутри одного движка БД — скажем, декларативные партиции Postgres — и «шардинг» по отдельным серверам БД — это одна идея в разных масштабах. Юнит sharding трека databases уходит вглубь механики одного движка; здесь мы рассуждаем о самом выборе распределения.)

Решение, управляющее всем, — ключ партиционирования: поле, чьё значение решает, на каком шарде живёт строка. Выбери хорошо — нагрузка распределяется ровно, а частые запросы остаются на одном шарде. Выбери плохо — получишь горячий шард из hook и межшардовые запросы, расходящиеся веером на все узлы.

Три способа назначить ключи шардам

Выбор стратегии — решение, с которым ты живёшь годами: стоит разобраться в точном компромиссе каждого варианта прежде, чем написать первый скрипт миграции.

range:      [А–Е] → шард 0   [Ж–Н] → шард 1   [О–Я] → шард 2
hash:       шард = hash(key) mod N         (растаскивает соседей)
directory:  таблица поиска: key → шард      (явно, гибко, ещё один хоп)

• Range-партиционирование держит ключи в сортированном порядке, так что range-сканы («все заказы за март») бьют в один шард и остаются эффективны. Опасность — упорядоченные ключи кучкуются: шардируй по timestamp, и все сегодняшние записи лягут на последний шард — движущаяся горячая точка.
• Hash-партиционирование прогоняет ключ через хеш и назначает по результату, растаскивая соседние ключи по шардам ради ровной нагрузки. Цена — range-сканы теперь бьют в каждый шард, ведь соседние ключи нарочно далеко друг от друга.
• Directory-партиционирование держит явную таблицу, отображающую ключи (или диапазоны) на шарды. Максимум гибкости — горячий ключ можно переселить на собственный шард — ценой лишнего поиска и директории, которая сама по себе критическая инфраструктура.

Вместе эти три стратегии образуют ручку: range даёт эффективность запросов ценой горячих точек на упорядоченных ключах; hash — ровную нагрузку записей ценой range-сканов; directory — гибкость ценой лишнего хопа и новой критической инфраструктуры. Без понимания этой ручки ты потянешься к hash по умолчанию и обнаружишь штраф за range-сканы только в продакшн-инциденте.

Проблема горячего шарда / знаменитости

Даже ровное партиционирование по числу ключей не партиционирует ровно по нагрузке. Знаменитость из hook — канонический случай: один ключ (пользователь, товар, видео) получает на порядки больше трафика, чем средний, так что его шард насыщается, пока остальные дремлют. Это перекос (skew), и он побеждает наивный ответ «просто хешируй ключ», ведь весь трафик одного горячего ключа всё равно ложится на один шард, который им владеет.

Меры все сводятся к размазыванию нагрузки горячего ключа:

• Разбить горячий ключ: добавить случайный суффикс (celebrity_id:00…:09), чтобы его записи рассыпались по десяти логическим ключам на разных шардах, а чтения свести веером обратно. Меняешь простоту на размазывание.
• Закешировать горячий ключ перед шардом, чтобы большинство чтений до него не доходили (уроки кеширования следующего юнита).
• Изолировать его: дать известному горячему ключу собственный выделенный шард (directory-партиционирование делает это изменением в одну строку).

Вместе эти три меры снижают нагрузку на горячий шард с разных сторон — разбивка рассеивает записи, кеш поглощает чтения до того, как они дойдут, изоляция даёт ключу собственный бюджет ёмкости. Без хотя бы одной из них один ключ-знаменитость способен насытить шард, сколько бы узлов ни было в остальном кластере.

Senior-рефлекс: равномерное распределение ключей не означает равномерное распределение нагрузки. Надо рассуждать о паттерне доступа, а не только о просторе ключей.

Боль решардинга

Рано или поздно ты перерастаёшь число шардов и должен сделать решардинг — добавить шарды и перераспределить данные. С наивной схемой hash(key) mod N это жестоко: меняешь N — и почти каждый ключ отображается на другой шард, так что приходится двигать почти весь датасет разом, обслуживая живые чтения и записи по ключам, которые в полёте. Это ровно та боль «перехешировать всё», ради которой существует consistent hashing (следующий урок) — он даёт добавить шард и сдвинуть лишь ~1/N ключей, а не все.

Даже с consistent hashing решардинг — операционный марафон: копируешь данные, пока они меняются, держишь старый и новый дом записи в синхроне до cutover, делаешь двойную запись или change-data-capture, чтобы не потерять записи во время переезда, и атомарно переключаешь маршрутизацию. Команды, спроектировавшие под решардинг (больше логических шардов, чем физических узлов, так что рост — это «передвинуть шард», а не «переразбить простор ключей»), живут куда легче тех, кто впервые разбивает живой простор во время кризиса ёмкости.

Межшардовые джойны, транзакции и вторичные индексы

Дробление ломает две вещи, что одна база давала бесплатно:

• Межшардовые джойны больше не происходят в движке. Джойн данных на разных шардах надо делать приложению (или слою запросов): собрать куски scatter-gather и сджойнить в памяти. Работает, но медленно и хрупко — поэтому ключи шардинга выбирают так, чтобы джойнимые данные жили вместе (колокация — например, шардировать заказы клиента на тот же шард, что и клиента).
• Межшардовые транзакции теряют одноузловую ACID-атомарность. Атомарно обновить две строки на двух шардах нужна распределённая транзакция (двухфазный коммит) или сага — последовательность локальных транзакций с компенсирующими откатами. Оба куда дороже и отказоопаснее одноузлового BEGIN…COMMIT; юнит sagas трека distributed разбирает паттерн вглубь.
• Вторичные индексы перестают быть глобальными. Если шардируешь по user_id, но нужно искать по email, индекс email разбросан по всем шардам. Либо держишь локальный индекс на шард (тогда запрос по email бьёт в каждый шард — scatter-gather), либо глобальный индекс как отдельную шардированную структуру (согласуемую с базовыми данными, часто асинхронно, так что может отставать). Глобальные вторичные индексы DynamoDB, например, eventual-консистентны ровно поэтому.