Производительность MongoDB: одна коллекция против нескольких коллекций для одновременного чтения / записи

Question

Я использую локальную базу данных на своем веб-сервере для синхронизации c определенных данных из внешних API. Локальная база данных будет использоваться для обслуживания веб-приложения. Данные, которые я синхронизирую, различны для каждого пользователя, который будет посещать веб-приложение. Поскольку задание syn c периодически, но непрерывно записывает данные в БД, а пользователи обращаются к своим данным с веб-страницы, мне интересно, что даст мне лучшую производительность здесь.

Поскольку syn c работа постоянно записывается в БД, я считаю, что коллекция заблокирована, пока не будет сделано. Я думаю, что наличие нескольких коллекций здесь помогло бы, поскольку блокировка была бы для определенной коллекции, в которую пишется, а не для одной коллекции каждый раз.

Правильно ли мое мышление здесь? По сути, я не хочу, чтобы чтения удушались, поскольку операция записи постоянно блокирует одну коллекцию.

Answer 1

Блокировка на уровне коллекции никогда не была чем-то особенным в MongoDB. До появления механизма хранения WiredTiger с MongoDB 4.x было много случаев блокировки всей базы данных.

В настоящее время с WiredTiger запись с несколькими потоками и / или процессами в одну коллекцию чрезвычайно эффективна. Правильный способ распределения очень большой нагрузки записи в MongoDB - это осколок вашей коллекции.

Чтобы протестировать конфигурацию с разделением на части и без защиты, вы можете легко развернуть обе конфигурации параллельно с MongoDB Atlas .

Answer 2

В MongoDB содержится большое количество информации о степени детализации и блокировке в целом. здесь .

В общем, запись в несколько коллекций, для небольшого или среднего значения "несколько "и при условии, что все коллекции созданы заранее, это может быть быстрее, чем использование одной коллекции, за счет того, что запросы становятся неуклюжими, а также потенциально медленными, если вам нужно выполнять объединения через конвейер агрегации вместо выполнения одной коллекции / index scan, например.

Если у вас так много коллекций, что открылось так много файлов, что либо БД, либо ОС начинают выгружать файлы из соответствующих кешей, производительность снова начнет падать.

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