Dokumenty podrzędne Mongoose a schemat zagnieżdżony

Ciekawi mnie zalety i wady używania subdokumentów w porównaniu z głębszą warstwą w moim głównym schemacie:

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

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

lub

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

Obecnie używam subdoców wszędzie, ale zastanawiam się przede wszystkim nad problemami z wydajnością lub zapytaniami, które mogę napotkać.

Według dokumentacji jest dokładnie to samo. Jednak użycie schematu spowodowałoby również dodanie _idpola (o ile nie zostało to wyłączone) i prawdopodobnie wykorzystuje więcej zasobów do śledzenia subdokumentów.

Alternatywna składnia deklaracji

Nowość w wersji 3 Jeśli nie potrzebujesz dostępu do instancji schematu dokumentu podrzędnego, możesz także zadeklarować dokumenty podrzędne, przekazując po prostu literał obiektu [...]

Jeśli masz schematy, które są ponownie używane w różnych częściach modelu, przydatne może być zdefiniowanie indywidualnych schematów dla dokumentów podrzędnych, aby nie trzeba było się powielać.

Z dokumentów osadzonych należy korzystać, jeśli są to dokumenty statyczne lub nie więcej niż kilkaset ze względu na wpływ na wydajność. Omówiłem ten problem już jakiś czas temu. Niedawno Asya Kamsky, która pracuje jako architekt rozwiązań dla MongoDB, napisała artykuł o „używaniu subdokumentów”.

Mam nadzieję, że pomoże to komuś, kto szuka rozwiązań lub najlepszych praktyk.

Oryginalny post na http://askasya.com/post/largeembeddedarrays . Możesz przejść do jej profilu stackoverflow na https://stackoverflow.com/users/431012/asya-kamsky

Przede wszystkim musimy zastanowić się, dlaczego mielibyśmy chcieć coś takiego zrobić. Zwykle radziłbym ludziom osadzać rzeczy, które zawsze chcą odzyskać, gdy pobierają ten dokument. Drugą stroną tego jest to, że nie chcesz osadzać w dokumencie rzeczy, których nie chcesz odzyskać.

Jeśli umieścisz w dokumencie aktywność, którą wykonuję, na początku będzie ona działać świetnie, ponieważ cała moja aktywność jest właśnie tam, a po jednym przeczytaniu możesz odzyskać wszystko, co chcesz mi pokazać: „ostatnio kliknąłeś to i tutaj czy twoje ostatnie dwa komentarze ”, ale co się dzieje po sześciu miesiącach i nie obchodzą mnie rzeczy, które zrobiłem dawno temu i nie chcesz mi ich pokazywać, chyba że specjalnie poszukam jakiejś starej aktywności?

Po pierwsze, w końcu będziesz zwracać coraz większy dokument i dbać o coraz mniejszą jego część. Ale możesz użyć projekcji, aby zwrócić tylko część tablicy, prawdziwym problemem jest to, że dokument na dysku stanie się większy i nadal będzie czytany, nawet jeśli zamierzasz zwrócić tylko część tego użytkownikowi końcowemu, ale ponieważ moja działalność nie ustanie tak długo, jak długo będę aktywny, dokument będzie się rozrastał.

Najbardziej oczywistym problemem jest to, że w końcu osiągniesz limit 16 MB dokumentów, ale wcale nie powinieneś się tym martwić. Dokument, który stale rośnie, będzie generował coraz wyższe koszty za każdym razem, gdy będzie musiał zostać przeniesiony na dysk, a nawet jeśli podejmiesz kroki w celu złagodzenia skutków fragmentacji, twoje zapisy będą ogólnie niepotrzebnie długie, wpływając na ogólną wydajność całej aplikacji.

Jest jeszcze jedna rzecz, którą możesz zrobić, która całkowicie zniszczy wydajność aplikacji, a jest to indeksowanie tej stale rosnącej tablicy. Oznacza to, że za każdym razem, gdy dokument z tą tablicą jest przenoszony, liczba pozycji indeksu, które wymagają aktualizacji, jest wprost proporcjonalna do liczby indeksowanych wartości w tym dokumencie, a im większa tablica, tym większa będzie ta liczba. być.

Nie chcę, aby to odstraszyło Cię przed używaniem tablic, gdy są one dobrze dopasowane do modelu danych - są potężną funkcją modelu danych bazy danych dokumentów, ale podobnie jak wszystkie potężne narzędzia muszą być używane w odpowiednich okolicznościach i należy go używać ostrożnie.

Zasadniczo utworzyć zmienną nestedDovi umieścić go tutajname: [nestedDov]

Prosta wersja:

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

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

Przykład 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"
    ]
}

Przykład:

Myślę, że jest to obsługiwane w innym miejscu przez wiele postów na SO.

Tylko kilka:

• Relacje MongoDB: osadzanie czy odniesienie?
• Jak zaimplementować ten schemat w MongoDB?
• Projekt schematu bazy danych MongoDB - wiele małych dokumentów lub mniej dużych dokumentów?

Najważniejsze jest to, że nie ma tutaj jednej odpowiedzi, a jedynie zestaw dość złożonych kompromisów.

Jest między nimi pewna różnica:

• Korzystanie ze schematu zagnieżdżonego jest pomocne przy sprawdzaniu poprawności.

• Schemat zagnieżdżony można ponownie wykorzystać w innych schematach.

• Schemat zagnieżdżony dodaje pole „_id” do dokumentu podrzędnego, chyba że użyto „_id: false”