Перевоз данных по кусочкам: инженерная кухня SPQR

Вот важная новость с фронта ИИ: denchickkk 14 минут назад Перевоз данных по кусочкам: инженерная кухня SPQR 14 мин 858 Блог компании Яндекс Блог компании Yandex Cloud & Yandex Infrastructure Open source * PostgreSQL * Высоконагруженные системы * На связи Денис из команды платформы данных в Yandex Cloud. Мы занимаемся разработкой системы, которая помогает легко реализовать горизонтальное масштабирование PostgreSQL с помощью шардирования. И это не теоретическая задача на два шарда и десять таблиц.

Необходимо сделать систему, которая в пределе хранит петабайты данных и выдерживает сотни тысяч запросов в секунду. В прошлой статье мы показывали SPQR со стороны пользователя: как выбрать ключ шардирования, как разложить таблицы на распределённые (distributed) и справочные (reference), как создать распределения и определить диапазоны ключей, а затем перевезти монолит на несколько шардов. Эта статья будет про инженерный путь: архитектуру, компромиссы и грабли, которые встретились по дороге.

Технические детали

Представим задачу — нужно построить систему, которая:общается с приложением по протоколу PostgreSQL;позволяет докидывать шарды на лету;держит метаданные о распределении данных в оперативной памяти;не разваливается от «селебрити», когда один ключ приносит непропорционально большую нагрузку;умеет всё это делать без даунтайма. Описание выше может звучать как набор взаимоисключающих требований, но именно из него вырос SPQR. Далее разберём: почему роутер — не главная проблема, зачем SPQR оперирует key range, как координатор перевозит данные маленькими кусками, как балансировщик понимает, что именно надо двигать, и почему всё это в итоге собирается из довольно простых строительных блоков.

Если вам удобнее смотреть и слушать — в докладе на HighLoad 2024 мы уже рассказывали про часть идей, но в тексте самые актуальные данные. Роутинг не самая сложная частьКогда речь заходит о «шардировании PostgreSQL», пожет показаться, что для этого обязательно понадобится очень «умный» роутер, который понимает SQL и знает, куда отправить запрос. Если убрать детали, алгоритм роутинга выглядит довольно просто.

Алгоритм роутингаПриходит SQL‑запрос. Роутер вытаскивает из него ключ шардирования. Если используется хеш‑шардирование, ключ сначала прогоняется через хеш‑функцию.

Отраслевые последствия

Полученное значение ищется в таблице диапазонов. По диапазону находится шард. Запрос уезжает на нужный PostgreSQL‑кластер.

В псевдокоде это выглядит примерно так:func route(query string) Конечно, в реальном роутере всё сложнее: есть транзакции, hints, COPY, prepared statements, кросс‑шардовые сценарии и пограничные случаи парсинга. Но сама идея ровно такая. Отсюда важный вывод: главное требование к маршрутизации — не сложность алгоритма, а дешевизна каждого решения.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.