Шардирование (Sharding)

Шардирование — это техника горизонтального масштабирования базы данных, при которой большой набор данных разбивается по нескольким серверам («шардам»), где каждый шард хранит подмножество от общего числа строк, а не полную копию на каждом сервере. Это основная стратегия масштабирования пропускной способности записи и общего объёма данных за пределы возможностей одного сервера базы данных, когда вертикальное масштабирование (покупка более мощного сервера) достигает убывающей отдачи или жёсткого потолка. Почему это важно для разработчиков AI/SaaS: большинству SaaS-продуктов шардирование вообще не требуется — хорошо проиндексированный экземпляр Postgres справляется с удивительно большими нагрузками, — но AI-продукты, поглощающие данные в высоком объёме (эмбеддинги для миллионов документов у тысяч арендаторов, логи событий от каждого AI-взаимодействия, векторные индексы, которые должны оставаться в памяти), упираются в потолок быстрее типичных CRUD-приложений, потому что и векторные, и событийные данные, как правило, растут намного быстрее традиционных реляционных данных. Понимание шардирования важно даже командам, которые ещё не достигли этой точки, потому что выбранный на раннем этапе ключ шардирования (часто, в многотенантном SaaS, ID клиента/тенанта) должен быть заложен в модель данных с первого дня — встраивание его в нешардированную схему годы спустя — это жестокая миграция. Как это работает: ключ шардирования (или ключ партиционирования) определяет, на каком шарде живёт данная строка — обычно это хэш ID клиента, ID пользователя или географического региона. Диапазонное шардирование размещает смежные диапазоны ключа на каждом шарде (просто, но рискует создать «горячие точки», если активность кластеризуется в одном диапазоне); хэш-based шардирование распределяет ключи более равномерно между шардами, но затрудняет диапазонные запросы («все записи за март»), поскольку они теперь охватывают каждый шард. Распределённые векторные базы данных (Pinecone, Qdrant, Milvus) автоматически шардируют под капотом по мере роста индекса, разбивая векторное пространство между узлами, чтобы запросы веерно распределялись по релевантным шардам параллельно, а не ложились целиком на один узел. Компромисс, который всегда привносит шардирование: межшардовые запросы (объединения или агрегации, охватывающие несколько шардов) становятся значительно сложнее и медленнее, чем на одной нешардированной базе данных, поэтому схему и запросы стоит проектировать так, чтобы минимизировать частоту межшардовых операций. Практический пример: многотенантный AI-аналитический SaaS шардирует свою базу логирования событий Postgres по `customer_id % 16`, получая 16 шардов. Крупный корпоративный клиент с 500 млн событий в месяц никогда не замедляет всю систему для остальных клиентов, потому что его события физически живут на одном-двух шардах, не конкурируя за тот же дисковый I/O и пул соединений, что данные всех остальных, — при этом слой маршрутизации шардов приложения прозрачно направляет каждый запрос на нужный шард на основе `customer_id` в запросе.