Темная сторона шардирования

Если шардирование так хорошо масштабирует систему, почему его так боятся? Потому что оно ломает фундаментальные свойства реляционных баз данных. Давай разберем главные боли.

Даже при математически идеальном хешировании возможны Hotspots (горячие точки). Представь Twitter: у обычного юзера 100 фолловеров, а у мировой знаменитости — 400 миллионов. Тот физический шард, на который алгоритм положит данные знаменитости, просто расплавится от нагрузки, пока остальные сервера будут простаивать.

Решение: Выделять таких пользователей на отдельные шарды вручную (Directory sharding) или агрессивно кешировать их данные в Redis.

Сделать быстрый JOIN между таблицами, которые физически лежат на разных серверах, силами самой базы данных почти невозможно. Базе придется гонять гигабайты данных по сети.

Решение: Денормализация (хранить все связанные данные вместе, как это делает Uber) или делать несколько простых SELECT-запросов и склеивать данные уже в коде твоего backend-приложения.

Списать деньги у юзера А на Шарде 1 и зачислить юзеру Б на Шарде 2 в рамках одной строгой ACID-транзакции — невероятно сложно, медленно и чревато блокировками (deadlocks).

Решение: Избегать кросс-шардовых транзакций на уровне дизайна (класть юзера А и Б в один шард) либо использовать паттерн Saga и переходить к Eventual Consistency (согласованности в конечном счете).

Писать логику шардирования на уровне приложения (IF шард_1 THEN коннект_1) считается плохим тоном. Для этого есть инфраструктурные инструменты:

• Vitess (для MySQL): Инструмент родом из YouTube. Ставится прокси-слоем перед базой и берет маршрутизацию на себя. Backend-приложению кажется, что оно общается с одной огромной БД. Читай кейс, как GitHub распилил свой монолит с помощью Vitess.
• Citus (для PostgreSQL): Официальное расширение, которое превращает обычный Postgres в распределенную СУБД. Отлично справляется с аналитическими кросс-шардовыми SQL-запросами.
• NewSQL (CockroachDB, TiDB): Современный класс баз данных, созданных с нуля для облаков. Шардирование и распределенные транзакции в них работают «из коробки» на уровне самого движка.