Optymalizacja wydajności schematu MongoDB

Pierwszą rzeczą, która przychodzi mi do głowy, jest:dlaczego przechowywanie referencji kosztuje 5000 razy więcej niż przechowywanie w poddokumencie?

Dobra, patrząc na twój schemat, uważam, że najlepszą metodą jest oddzielne zbieranie słów, a nie pakietów.

Pierwsza czerwona flaga, jaką zobaczyłem, to twoje podwójne zagnieżdżenie tutaj:

packages : [{
    package : {type: Schema.Types.ObjectId, ref: 'Packages'},
    from : {type : Schema.Types.ObjectId, ref :'Languages'},
    to : {type : Schema.Types.ObjectId, ref :'Languages'},
    words : [{
        word: {type: String},
        progress: {type: Number,default : 0}
    }]
}]

words Poddokument będzie bardzo trudny do pracy w obecnej wersji MongoDB, zwykle 2-3 poziomy głębokości zaczynają mieć problemy, szczególnie z operatorami pozycyjnymi.

Teraz biorąc pod uwagę, że zawsze powinieneś pracować z najwyższą możliwą wartością, jaką możesz uzyskać tutaj:

Musisz również wziąć pod uwagę koszty utrzymania tego dokumentu. Potrzebne będą operatory w pamięci, takie jak $pull , $push , $addToSet itp., co oznacza, że ​​cały dokument będzie musiał zostać zserializowany i załadowany do natywnych struktur MongoDB C++. Będzie to niezwykle czasochłonne zadanie w zależności od ruchu do tych dokumentów.

Biorąc pod uwagę Twój komentarz:

po prostu wkłada kolejny gwóźdź do trumny osadzania słów w głównym dokumencie użytkownika. Biorąc pod uwagę to, co powiedziałem w poprzednim akapicie, nie będzie to dobrze działać z kosztem używania operatorów w pamięci na words tablica.

Będzie to działać znacznie lepiej, jeśli słowa zostaną podzielone, $slice jest również operatorem w pamięci i prawdopodobnie miałby tutaj zmniejszoną wydajność.

I to jest szybka, uzasadniona odpowiedź. Jestem pewien, że mogę wyjaśnić więcej na temat mojego powodu, ale to powinno wystarczyć.