Wzorce modelowania dla baz dokumentowych, klucz–wartość, szerokokolumnowych, grafowych i wektorowych — kiedy osadzać, referencjonować, denormalizować lub grupować w okna czasowe.
Bazy NoSQL wymieniają sztywne schematy i złączenia na skalowanie poziome. Każda rodzina modeluje relacje po swojemu, więc to wzorzec dostępu — nie postać normalna — decyduje o strukturze.
Tabela referencyjna · 28 wpisy
Modelowanie danych NoSQLExplained
28 of 28 rows
Dokumentowe
Zagnieżdżone poddokumenty żyją wewnątrz jednego dokumentu nadrzędnego zamiast w osobnych tabelach.
Relacje jeden-do-nielu czytane razem. Zamówienie z pozycjami. Użytkownik z trzema adresami.
Przechowuj obce id, nie dane. Rozwiązuj je drugim odczytem albo $lookup.
Duże, współdzielone lub niezależnie aktualizowane podencje. Powiązania wiele-do-wielu między kolekcjami.
Rodzic osadza krótką tablicę potomków; cały zestaw mieści się i ładuje jako jeden dokument.
Kilka numerów telefonów lub preferencji w profilu. Jeden odczyt zwraca rodzica i potomków.
Potomkowie żyją we własnej kolekcji; każdy nosi id rodzica, albo rodzic trzyma ograniczoną tablicę id.
Zbiory zbyt duże lub zbyt niezależne do osadzenia. Pobieraj potomków po id rodzica.
Potomek przechowuje id rodzica; rodzic nigdy nie listuje potomków, bo zbiór jest nieograniczony.
Zdarzenia, logi lub głosy powiązane z hostem lub użytkownikiem. Filtruj potomków po id rodzica i stronicuj.
Dokumenty różnych typów encji współdzielą jedną kolekcję, rozróżniane polem typu.
Komentarze lub powiadomienia przypięte do wielu rodzajów rodziców, odpytywane jednym sposobem.
Kilka skrajnych encji wydziela się ze wspólnej formy, by ich rozmiar lub ruch nie zniekształcał reszty.
Konta celebrytów, których listy obserwatorów lub liczniki przerosłyby zwykły dokument.
Każda rewizja to nowy dokument z tym samym id i rosnącym numerem wersji; zapytanie wybiera najnowszą.
Ścieżki audytowe i historia edycji, gdzie stare rewizje pozostają odpytywalne.
Wartości pochodne liczone w chwili zapisu i przechowywane obok danych, które podsumowują.
Sumy, oceny i top-N, które inaczej uruchamiałyby agregację przy każdym odczycie.
Klucz–wartość i szerokokolumnowe
Termin projektowy DynamoDB: zwiń wiele typów encji w jedną tabelę używając przeciążonych kluczy partycji i sortowania.
Pobieraj niejednorodne elementy jednym zapytaniem, bez złączenia.
Jeden atrybut klucza obsługuje wiele typów encji, oznaczony prefiksami jak USER# lub ORDER#.
Projekty single-table. Grupuj powiązane elementy pod jedną partycją i pobieraj jednym zapytaniem.