2016-05-04 5 views
0

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

enter image description here

Мои вопросы:

  • , что я должен делать, когда размер коллекции становится больше, чем предел 16MB? app_log в коллекциях server_log может в некоторых случаях расти больше 16 МБ в зависимости от того, насколько занят сервер.

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

  • Вы видите какие-либо потенциальные проблемы с моим дизайном?

  • Насколько эффективна практика проверки размера сбора чеков и создания новой коллекции по дням и часам ..etc для учета роста размера журнала?

Благодаря

+1

Привет, я не много сделал с MongoDB, но я думаю, что ограничение на 16 МБ - на документ, а не на сбор. Для сохранения файлов журнала вы можете очистить эту коллекцию и использовать резервные копии db за 90 дней – iestync

+0

Почему эта коллекция server1 и server2? – rummykhan

+0

, вероятно, Server1 и Server2 должны быть встроены в коллекцию пользователей – Deano

ответ

1

Будет ли это хороший дизайн или нет, будет зависеть от ваших запросов. В общем, вы хотите избежать использования объединений в Mongo (они все еще возможны, но если вы делаете кучу объединений, вы используете это неправильно и действительно должны использовать реляционную БД :-)

Например, если большинство ваших запросов находятся в коллекции server_log и используются только поля в этой коллекции, тогда все будет в порядке. OTOH, если ваши запросы server_log всегда должны извлекать данные из коллекции сервера (например, имя и поля userId), тогда, возможно, стоит выборочно денормализовать эти данные. Это причудливый способ сказать, вы можете скопировать поля имени и пользователя в свои документы server_log, чтобы ваши запросы могли не совпасть с тем, чтобы присоединиться к серверной коллекции. Конечно, каждый раз, когда вы денормализуете, вы добавляете сложность в свое приложение, которое теперь должно гарантировать, что данные согласованы между несколькими коллекциями (например, при изменении имени сервера вы также должны убедиться, что вы также изменили его в server_logs) ,

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

2

Ваш размер коллекции не ограничивается 16Мб, так как один из комментариев отметили, вы можете проверить in the MongoDB manual, что это самый большой размер документа. Таким образом, нет необходимости отделять один и тот же класс данных между разными коллекциями, на самом деле это будет серьезной головной болью для вас: одна коллекция user, одна для ваших server и одна для вашего server_log. Затем вы можете создавать ссылки из одной коллекции на следующую, используя поле id.

Смежные вопросы