Skip to content

Modelowanie danych NoSQL wyjaśnione

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
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.
Klucz partycji rozkłada wiersze po węzłach; klucz sortowania porządkuje każdą partycję.Cassandra i DynamoDB. Skany zakresowe, uporządkowane logi, hierarchiczne klucze złożone.
Nanieś kilka atrybutów na jeden klucz sortowania z separatorem — country#region#city — by dopasowanie prefiksu schodziło po hierarchii.Hierarchie i filtry wieloaspektowe. Jeden uporządkowany zakres zastępuje wiele odczytów z indeksów.
Grupuj zdarzenia w stałe okna — godzina, dzień, miesiąc — pod dedykowanymi partycjami lub tabelami.Metryki, logi i telemetria IoT. Ogranicza rozmiar partycji i wygasa zimne dane.
Duplikuj często czytane pola między rekordami, by zapytanie nigdy nie goniło drugiego odczytu.Obciążenia odczytowe, gdzie spójność ostateczna jest akceptowalna, a magazyn tani.
Indeks dodatkowy zbudowany na atrybucie, który mają tylko niektóre elementy; elementy bez niego nigdy nie wchodzą do indeksu.Alternatywne ścieżki dostępu. Znajdź rzadki podzbiór — otwarte zamówienia, niespedycjonowane pozycje — bez pełnego skanu.
Zapisz najpierw dokładne zapytania; układ tabeli wynika z nich, nie z encji ani postaci normalnej.Praca nad schematami w Cassandrze i DynamoDB. Jedna tabela na rodzinę zapytań; model danych kopiuje pytanie.
Zapytanie musi równolegle uderzyć w wiele partycji lub węzłów, bo żaden klucz nie pasuje do pytania.Zapach do wyprowadzenia z projektu, nie cel. Przekluczuj tabelę, by typowe zapytanie lądowało na jednej partycji.
Kopie są wypychane do widoku każdego czytelnika przy zapisie, albo zbierane i scalane przy odczycie.Feedy i osie czasu. Fan-out przy zapisie dla małych audytoriów, przy odczycie dla ogromnych.
Wstępnie zbudowany wynik zapytania przechowywany jako własna tabela, utrzymywany na bieżąco względem bazy.Alternatywne kształty odczytu nad jedną ścieżką zapisu. Obsługuje zapytania, na które tabela bazowa nie odpowie.
Grafowe
Każda krawędź to wiersz lub krotka wskazująca z węzła źródłowego na docelowy.Bazy grafowe i własnościowe. Zapytania przyjaciel-przyjaciela, trasowanie, rekomendacje.
Każda relacja to dokument we własnej kolekcji, niosący id from i to plus atrybuty powiązania.Grafy w bazach dokumentowych. Atrybuty na samym powiązaniu — ocena, rola, znacznik czasu.
Każdy węzeł przechowuje liczniki lewy i prawy z przejścia w głąb; poddrzewo żyje w zakresie rodzica.Drzewa odczytowe. Jedno zapytanie BETWEEN zwraca poddrzewo; wstawienia przenumerowują przejście.
Dedykowana tabela zapisuje każdą parę przodek–potomek, włączając każdy węzeł na głębokości zero.Zapytania o całe gałęzie na każdej głębokości. Proste złączenia, opłacone magazynem i utrzymaniem.
Grafy własnościowe przypinają atrybuty klucz–wartość do węzłów i krawędzi; RDF wyraża wszystko trójkami podmiot-orzeczenie-dopełnienie.Grafy własnościowe dla bogatych przejść (Neo4j); RDF dla otwartych danych powiązanych i wymiany ontologii.
Wektorowe
Wielowymiarowa tablica float stoi obok metadanych. Indeks ANN znajduje najbliższych sąsiadów.Wyszukiwanie semantyczne, retrieval RAG, rekomendacje i podobieństwo nad treściami bez struktury.
Dokumenty źródłowe są dzielone — po rozmiarze, nakładce lub strukturze — zanim każda część dostanie własny embedding.Jakość retrievalu RAG. Rozmiar chunku waży precyzję przeciw kompletności; nakładka chroni rozcięte zdania.
Podobieństwo gęstych wektorów działa obok dopasowania słów kluczowych; dwie listy rankingowe zlewają się w jeden wynik.Zapytania wymagające naraz dokładnych terminów i znaczenia, z filtrami metadanych na wierzchu.