Зачем нужен distributed SQL — горизонтальный масштаб с сохранением SQL и ACID-транзакций, как под капотом работают шардинг и консенсус (Raft у трёх движков, Paxos у OceanBase), чем платим латентностью распределённых транзакций и когда это оправдано против одиночного PostgreSQL с репликами. Все числа сняты на одном стенде: четыре движка, одинаковые замеры, назначенная задержка между узлами
Разложить данные по узлам — самая простая часть. Дальше начинается счёт: запрос без ключа шардирования идёт во все шарды, join между по-разному распределёнными таблицами Citus по умолчанию вообще отказывается планировать, глубокая страница тащит с шардов сотни тысяч строк ради двадцати, а добавленный узел сам по себе не берёт на себя ни одного шарда. Всё — замерами на живом кластере Citus
Hashed и ranged shard key, chunk splitting, balancer, роутинг через mongos, config servers, zone sharding, jumbo chunks и resharding — на живом шардированном кластере, с хотспотами и тем, как их ловить
Как устроено распределение данных — от классического token ring к tablets, как ведёт себя multi-DC репликация при отказе ДЦ и что происходит с tablets при decommission узла
Как устройство shard-per-core (Seastar, без блокировок между ядрами) распределяет нагрузку по шардам, что это даёт в задержке и throughput — на живом 3-узловом кластере
Как ClickHouse масштабируется горизонтально: шардирование и репликация через ClickHouse Keeper, ReplicatedMergeTree и Distributed-таблицы, что ломается при падении узла — реплика недоступна против шард недоступен. Живой кластер 2 шарда × 2 реплики
