По работе мы с командой плотно занимались вопросами масштабирования баз данных в целом и шардирования в частности. Поэтому я много читал о том, как другие компании решали похожие задачи.
Особенно мне запомнилась эпопея Figma из двух статей. Их заряженный по железу монолитный PostgreSQL всё-таки начал упираться в свои пределы, и команде пришлось последовательно менять архитектуру хранения данных.
Как выиграть время
В первой статье инженеры разбирают:
- базовые тактические действия, когда база начинает не вывозить;
- причины отказа от переезда на другую СУБД;
- вертикальное партиционирование — вынос таблиц в отдельные базы без даунтайма, но с нюансами.
Эти решения помогли Figma выиграть время, но не сняли ограничение окончательно. Инженеры понимали, что рано или поздно снова упрутся в тот же предел.
Как снять ограничение
Во второй статье команда рассказывает, как проектировала горизонтальное шардирование:
- разделила таблицы на группы colocations, объединённые ключом шардирования и физическим размещением данных;
- написала собственный роутер подключений к БД;
- проверяла поведение продакшен-трафика до релиза в продакшен.
В итоге Figma построила решение под собственный спектр задач. Бездумно повторять его у себя не стоит: масштаб, история системы и требования к миграции слишком специфичны. Но обе статьи хорошо показывают путь от тактического продления жизни базы к архитектуре, которая снимает ограничение системно.
Рекомендую прочитать их всем, у кого база потенциально может начать задыхаться. Будете знать, к чему готовиться и какой ад бывает в мире больших баз данных.