Дизайн схемы MongoDB по конкретному случаю использования

Question

Я моделирую мою схему данных в данный момент, и я не уверен, что мой мыслительный процесс имеет смысл. Так я думал, что я мог бы задать некоторые из более опытных ребят MongoDB здесь:

---

Допустим, мое приложение производит до 10,000 событий-документов в день. Я хочу, чтобы обращался к ним по времени. Например: «Дайте мне все события этих трех дней!».

Мои знания РСУБД, которые я собрал в университете, сначала сказали мне: «Сделайте сборку событий и дайте каждому документу« Дата »события.« Сделано ».

Но тогда я наткнулся на идею сделать коллекцию на каждый день!. Затем я мог получить доступ к этим событиям очень быстро, просто получив все события за один день, просто позвонив в свою соответствующую коллекцию.

Имеет ли это смысл? Могу ли я иметь сотни/тысячи коллекций, не жертвуя скоростью и эффективностью?

---

Спасибо за советую :-)

Answer 1

10,000 документов в день не очень много. В течение одного года это составляет 3,65 млн. Документов. Это, конечно, не очень маленькая коллекция, но я не вижу большого смысла в их разломе.

Недостатков в данном конкретном случае являются

• Это трудно изменить шаблоны запросов позже. Если вам вдруг понадобится точность часов, у вас проблемы. Если вы хотите найти все события за последний год с некоторым полем x, установленным в y, вам придется запрашивать 365 или 366 коллекций.
• Ваши шаблоны запросов будут более сложными, поскольку вам придется иметь дело с различными именами коллекций. Кроме того, вам необходимо несколько раундов в базу данных.
• Интернационализация очень сложная, поскольку «день» не является четко определенным моментом во времени по всему миру. С другой стороны, поле UTC DateTime позволяет запрашивать в разных часовых поясах, если это потребуется.
• Управление большим количеством коллекций может быть утомительным, работа с оболочкой будет весьма раздражающей.
• Швартование обычно выполняется на основе сбора. Если у вас много небольших коллекций, вы не можете делать автоматическое очертание.

Однако, работая с большим количеством коллекций возможно, хотя есть limits you should understand. Как объяснить документы, вы можете иметь 12,000 коллекции ж/один индекс каждого с настройками по умолчанию. См. Там для более подробной информации.

Плотность сервера, связанная с блогами об их подходе, также использует a lot of collections, но они жевают 650-миллионные документы, и они утверждают, что это не делает большой разницы в производительности.