Поддокументы Mongoose против вложенной схемы

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

var subDoc = new Schema({
  name: String
});

var mainDoc = new Schema({
  names: [subDoc]
});

или

var mainDoc = new Schema({
  names: [{
    name: String
 }]
});

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

Согласно документам , это точно так же. Однако использование схемы также добавит _idполе (если оно не отключено) и, предположительно, использует дополнительные ресурсы для отслеживания вложенных документов.

Альтернативный синтаксис объявления

Новое в версии 3 Если вам не нужен доступ к экземпляру схемы вложенного документа, вы также можете объявить вложенные документы, просто передав литерал объекта [...]

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

Вы должны использовать встроенные документы, если это статические документы или их не более нескольких сотен из-за снижения производительности. Я уже говорил об этой проблеме некоторое время назад. Недавно Ася Камский, которая работает архитектором решений для MongoDB, написала статью об «использовании вложенных документов».

Я надеюсь, что это поможет тем, кто ищет решения или передовой опыт.

Оригинальный пост на http://askasya.com/post/largeembeddedarrays . Вы можете получить доступ к ее профилю stackoverflow на https://stackoverflow.com/users/431012/asya-kamsky

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

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

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

Наиболее очевидная проблема с этим состоит в том, что в конечном итоге вы достигнете предела документа в 16 МБ, но это совсем не то, о чем вам следует беспокоиться. Документ, который постоянно растет, будет нести все более высокие затраты каждый раз, когда его необходимо перемещать на диск, и даже если вы предпримете шаги для смягчения последствий фрагментации, ваши записи в целом будут излишне длинными, что повлияет на общую производительность всего вашего приложения.

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

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

По сути, создайте переменную nestedDovи поместите ее сюдаname: [nestedDov]

Простая версия:

var nestedDoc = new Schema({
  name: String
});

var mainDoc = new Schema({
  names: [nestedDoc]
});

Пример JSON

{
    "_id" : ObjectId("57c88bf5818e70007dc72e85"),
    "name" : "Corinthia Hotel Budapest",
    "stars" : 5,
    "description" : "The 5-star Corinthia Hotel Budapest on the Grand Boulevard offers free access to its Royal Spa",
    "photos" : [
        "/photos/hotel/corinthiahotelbudapest/1.jpg",
        "/photos/hotel/corinthiahotelbudapest/2.jpg"
    ],
    "currency" : "HUF",
    "rooms" : [
        {
            "type" : "Superior Double or Twin Room",
            "number" : 20,
            "description" : "These are some great rooms",
            "photos" : [
                "/photos/room/corinthiahotelbudapest/2.jpg",
                "/photos/room/corinthiahotelbudapest/5.jpg"
            ],
            "price" : 73000
        },
        {
            "type" : "Deluxe Double Room",
            "number" : 50,
            "description" : "These are amazing rooms",
            "photos" : [
                "/photos/room/corinthiahotelbudapest/4.jpg",
                "/photos/room/corinthiahotelbudapest/6.jpg"
            ],
            "price" : 92000
        },
        {
            "type" : "Executive Double Room",
            "number" : 25,
            "description" : "These are amazing rooms",
            "photos" : [
                "/photos/room/corinthiahotelbudapest/4.jpg",
                "/photos/room/corinthiahotelbudapest/6.jpg"
            ],
            "price" : 112000
        }
    ],
    "reviews" : [
        {
            "name" : "Tamas",
            "id" : "/user/tamas.json",
            "review" : "Great hotel",
            "rating" : 4
        }
    ],
    "services" : [
        "Room service",
        "Airport shuttle (surcharge)",
        "24-hour front desk",
        "Currency exchange",
        "Tour desk"
    ]
}

Пример:

Я думаю, что это обрабатывается в другом месте в нескольких сообщениях на SO.

Немного:

• Отношения MongoDB: встраивание или ссылка?
• Как мне реализовать эту схему в MongoDB?
• Дизайн схемы MongoDB - много маленьких документов или меньше больших документов?

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

Между ними есть некоторая разница:

• Использование вложенной схемы полезно для проверки.

• Вложенную схему можно повторно использовать в других схемах.

• Вложенная схема добавляет во вложенный документ поле _id, если вы не использовали "_id: false"