Структура MongoDB: единая коллекция против нескольких меньших коллекций

У меня есть общий вопрос структуры базы данных. В моем сценарии я использую mongodb.

Я создаю приложение, в котором пользователь может загружать список песен (название, исполнитель и т.д.), но я не уверен, что мне нужно иметь одну коллекцию songList для всех пользователей или отдельную коллекцию songList.user # для каждого индивидуальный пользователь. Пользователи могут только запрашивать связанные с ними песни, поэтому пользователь A НИКОГДА не будет знать о песнях пользователя B.

Примеры кода:

Несколько коллекций на пользователя

db.songList.userA.find()
{"title": "Some song of user A", "artist": "Some artist of user A"}

db.songList.userB.find()
{"title": "Some song of user B", "artist": "Some artist of user B"}
  • Pros
    • Меньший размер коллекции для запроса
  • Cons
    • ремонтопригодность
      • 1000 пользователей означают 1000 коллекций

vs single collection с полем "пользовательское" пользователя

db.songList.find({"user":"A"})
{"title": "Some song of user A", "artist": "Some artist of user A", "user": "A"}
  • Pros
    • Гибкость запросов к пользователям в случае необходимости
  • Cons
    • Производительность

Я пытаюсь создать список pro/con, но все же на заборе. Учитывая, что каждая песня пользователя будет изолирована друг от друга, какой подход лучше? Моя главная задача - обслуживание и выполнение запросов.

Спасибо заранее.

Ответы

Ответ 1

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

Так что, имея меньший размер коллекции, на самом деле не профессионал, и я не уверен, что эта теория приходит, что она есть, это не в SQL, и это не в MongoDB. Производительность sharding, если все сделано хорошо, должна относиться к производительности запроса небольшого набора данных (с небольшими накладными расходами). Если это не так, вы неправильно настроили свой осколок.

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

Таким образом, если каждая коллекция имела один индекс, мы можем создать до 12 000 коллекций. Параметр -nssize позволяет увеличить этот предел (см. Ниже).

Ответ 2

Я бы рекомендовал NOT сделать отдельную коллекцию для каждого пользователя.

Прочитайте документацию

По умолчанию MongoDB имеет ограничение примерно 24 000 пространств имен в база данных. Каждое пространство имен составляет 628 байт, файл .ns - 16 МБ по умолчанию.

Каждая коллекция считается пространством имен, как и каждый индекс. Таким образом, если каждая коллекция имела один индекс, мы можем создать до 12 000 коллекции. Параметр --nssize позволяет увеличить этот предел (см. ниже).

Имейте в виду, что на каждую коллекцию приходится определенная минимальная накладная. несколько КБ. Кроме того, для любого индекса потребуется не менее 8 Кбайт пространства данных, как размер страницы b-дерева составляет 8 КБ. Некоторые операции могут замедляться, если много коллекций, и метаданные выгружаются.

Таким образом, вы не сможете изящно обращаться с ним, если ваши пользователи превышают лимит пространства имен. Также он не будет высоким по производительности с ростом вашей пользовательской базы.

UPDATE

Как отметил в комментариях Хенри Лю. Для Mongodb 3.0 или выше, используя механизм хранения WiredTiger, он больше не будет пределом.

docs.mongodb.org/manual/reference/limits/#namespaces