Какой дизайн схемы MondoDB лучше?

#mongodb #database-design #nosql

#mongodb #database-design #nosql

Вопрос:

В общем, какая схема лучше и почему? Я сталкиваюсь с этой же проблемой снова и снова, и, похоже, она смешивается в Интернете с тем, что лучше.

Первая схема содержит один документ для идентификатора местоположения с вложенным меню:

 {
    locationID: "xyz",
    menu: [{item: "a", price: 1.0}, {item: "b", price: 2.0}...]
}
  

Вторая схема содержит несколько документов для заданного идентификатора местоположения

 {
    locationID: "xyz",
    item: "a",
    price: 1.0
},
{
    locationID: "xyz",
    item: "b",
    price: 2.0
}
  

Кажется, что первая схема работает быстрее и не дублирует идентификатор местоположения, поэтому использует немного меньше памяти. Вторая схема кажется более медленной, поскольку она должна собирать документы (возможно, она проиндексирована в алфавитном порядке?), Но ее намного проще модифицировать.

Есть ли «твердый» ответ или руководство по этому вопросу?

Ответ №1:

Для фактических данных, которые вы показали выше, я бы выбрал первый дизайн. Первый дизайн позволяет сохранять все пункты меню для одного местоположения и извлекать их из одного документа Mongo. Как вы указали, это, вероятно, будет быстрее, чем при использовании второго более нормализованного дизайна.

Что касается того, когда вы можете использовать вторую версию, рассмотрим случай, когда метаданные элемента меню относительно велики. Например, предположим, что вы хотели сохранить изображение размером 10 КБ для каждого пункта меню. MongoDB имеет ограничение в 16 МБ в качестве максимального размера для одного документа BSON. Для местоположений с несколькими сотнями пунктов меню вы не сможете разместить все пункты меню и их метаданные в одном документе. В таком случае первый вариант может отсутствовать, и вы будете вынуждены использовать второй вариант (или что-то еще).