Зачем нужно шардирование: потолок одного Postgres

Postgres Отто работает при 95% CPU, рабочий набор данных перерос объём RAM, а запись перегружает единственный primary. Реплики для чтения помогают с чтением, но узкое место по записи — это сам сервер. Более мощного инстанса попросту не существует.

Потолок одного Postgres

У единственного экземпляра Postgres есть жёсткие пределы:

• Рабочий набор против RAM: когда горячая часть данных перестаёт помещаться в shared_buffers плюс OS page cache, каждый запрос начинает обращаться к диску. Падение cache-hit ratio (blks_hit / (blks_hit + blks_read)) ниже 95–99% — главный сигнал тревоги.
• Пропускная способность записи: единственный primary выдерживает примерно 10–50k транзакций в секунду в зависимости от железа. Выше этого значения генерация WAL доминирует по CPU и primary становится бутылочным горлышком.
• Хранилище: практический потолок — около 1–10 ТБ рабочего набора в RAM на самых больших доступных машинах.

Вертикальное масштабирование (больше RAM, более быстрый NVMe) выигрывает время — нередко годы. Правильный порядок: сначала исправить медленные запросы, добавить индексы, добавить реплики для чтения, вертикально масштабироваться. Шардирование — последнее средство, а не первое.

Что делает шардирование

Шардирование берёт один логический датасет (все ваши orders, все ваши users) и разбивает его по N физическим экземплярам Postgres. Каждая строка живёт ровно на одном шарде, определяемом ключом шарда — колонкой или набором колонок (обычно tenant_id для B2B SaaS, user_id для B2C).

Выигрыш — почти линейное горизонтальное масштабирование: 10 шардов дают примерно 5–8× пропускной способности (накладные расходы на координацию снижают теоретический 10× прирост). Цена — каждая операционная задача: бэкапы, миграции, обновления, VACUUM — должна выполняться на каждом шарде.

Режим отказа hot shard

Самый важный режим отказа, против которого нужно проектировать с первого дня — это горячий шард (hot shard): один шард получает значительно больше трафика, чем остальные, потому что ключ шарда был выбран неудачно или один клиент вырос в 1000× раз по сравнению с медианным.

Пример: SaaS шардирует orders по customer_id. Корпоративный клиент подписывается и его заказы в 5 раз превышают сумму всех остальных клиентов. Их шард достигает 95% CPU, пока остальные шарды работают при 10%. Кластер по факту работает с мощностью одного шарда для доминирующего клиента.

Исправление — перемещение этого клиента на выделенный шард — рассматривается в уроке 05. Главный вывод здесь: выбор ключа шарда — это единственное наиболее важное проектное решение в шардированной системе, а плохой выбор приходится терпеть годами.

Метафора библиотеки

Шардирование — это разница между одной библиотекой с миллионом книг (одно здание, один стол выдачи, найти что угодно можно просто походив по зданию) и десятью библиотеками по 100k книг (десять зданий, нужен каталог «в какой библиотеке эта книга»). Единственная библиотека проще. Десятибиблиотечная установка требует каталога (карта шардов) и правила, в какое здание идти, прежде чем отправиться туда.

Книги, которые выдают миллион раз в год, заполняют одну библиотеку, пока остальные пустуют — это и есть режим отказа hot shard.