MongoDB одна коллекция против многих

Question

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

Если общее количество документов невелико, вы можете сгруппировать документы в коллекцию по типу

Здесь подразумевается, что если общее количество документов достаточно велико , Я должен склоняться к сохранению их в одной коллекции?

Отдельные коллекции очень важны для высокопроизводительной пакетной обработки

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

Моя проблема в том, что мне нужно сделать полдюжины или около того типов документов доступными для поиска с помощью произвольного текста. Они должны быть доступны для поиска по:

1. имени и тегам с текстовым поиском
2. производителю_id и в некоторых редких случаях document_type по точному значению

Интуитивное решение состоит в том, чтобы хранить все мои доступные для поиска документы в одной и той же коллекции, потому что он сохраняет атомарность обновлений указанных документов и согласуется с «сворачивающимися» документами меньшего размера, в отличие от наличия второй доступной для поиска коллекции. (или, альтернативно, другая БД, такая как ElasticSearch или что-то в этом роде). Я ожидаю, что моя БД будет расти бесконечно, пока нерелевантные документы не будут архивированы.

Я что-то упускаю?

Answer 1

Размер документа в MongoDB ограничен 16 МБ. В конечном итоге это приводит к необходимости разделения документов на части.

Когда приложение обменивается данными с базой данных, обычно есть два соображения, которые влияют на производительность:

• Приложение не хочет извлекать ненужные данные из базы данных.
• Приложение хочет получить необходимые данные за наименьшее количество запросов / циклов.

Итак, если вам удалось поместить ВСЕ свои данные в один документ, вы бы отлично справились по второму требованию, но ужасно по первому, и если бы каждое поле было отдельным документом, вы бы хорошо справились с первым, но ужасно по второму.

Разработка схемы - это в значительной степени акт (и искусство) балансирования этих требований.

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

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