MongoDB sharding: что это и когда нужен шардинг

MongoDB sharding — это способ распределить данные по нескольким серверам, которые называются шардами. Он нужен не для каждого проекта, а только когда одной машине уже не хватает ресурсов: слишком много данных, слишком тяжелая запись, высокая нагрузка на чтение или большой рост коллекции

Если у вас учебный проект, небольшой backend, Telegram-бот или CRM на несколько тысяч документов, шардирование обычно не нужно. Сначала проверьте индексы, структуру документов, запросы и ресурсы сервера. Шардинг добавляет мощность, но также добавляет сложность

Из чего состоит sharded cluster

В MongoDB-кластере с шардингом обычно есть:

• shards — серверы или replica set, где лежат данные;
• config servers — хранят метаданные о распределении данных;
• mongos — роутер запросов, через который приложение общается с кластером.

Приложение подключается не напрямую к каждому шарду, а к mongos. Он понимает, куда отправить запрос

Главная идея shard key

Shard key — поле или набор полей, по которым MongoDB распределяет документы между шардами

Пример:

sh.shardCollection("shop.orders", { userId: 1 })

Здесь коллекция orders распределяется по userId

Плохой shard key может испортить всю схему. Например, если почти все записи идут одному пользователю, один шард будет перегружен, а остальные простаивать

Как выбрать shard key

Хороший shard key должен:

• часто присутствовать в запросах;
• равномерно распределять документы;
• не создавать постоянную запись только в один шард;
• подходить под будущий рост данных.

Для заказов это может быть userId, tenantId, дата вместе с другим полем или другой бизнес-ключ. Выбор зависит от того, как приложение читает и пишет данные

Когда шардирование действительно нужно

Шардирование стоит рассматривать, если:

• коллекция растет быстрее, чем вы можете обслуживать на одном сервере;
• индексы и оптимизация запросов уже не помогают;
• запись упирается в ресурсы одной машины;
• нужно горизонтально масштабировать большой сервис;
• проект уже работает на replica set и есть понятная картина нагрузки.

Если причина медленной работы — отсутствие индексов, шардинг не решит проблему красиво. Он просто распределит плохо устроенную нагрузку

Частые ошибки

Включили sharding слишком рано

Для маленькой базы шардинг чаще усложняет поддержку. Начинайте с нормальных индексов, explain() и мониторинга

Выбрали поле с плохим распределением

Если shard key имеет мало разных значений, данные могут лечь неравномерно. Например, поле status с тремя значениями почти никогда не подходит

Не учитывают основные запросы

Если запросы не содержат shard key, mongos может отправлять их на несколько шардов. Это снижает пользу от шардирования

Думают, что sharding заменяет backup

Шардинг распределяет данные, но не отменяет резервное копирование, мониторинг и проверку восстановления

Как проверить готовность к sharding

Соберите медленные запросы, проверьте индексы, посмотрите размер коллекций и частоту записи. Если узкое место понятно и связано именно с масштабом одной машины, можно проектировать shard key. Если причина неясна, сначала разберите explain() и мониторинг

Что почитать дальше по MongoDB

Если нужен общий маршрут по теме, откройте рубрику MongoDB. Для соседних задач пригодятся эти разборы:

• Discord bot на Python и MongoDB: как задать проверку
• Failed to start MongoDB database server: что проверить
• MongoDB Atlas: облачная база для первого проекта
• MongoDB Compass: подключение и первая коллекция без командной строки