NoSQL-datamodelleringExplained

28 of 28 rows

Mönster↕	Vad det är↕	Används för↕
Dokument
⤢Embedding	Nestlade underdokument bor inuti ett överordnat dokument i stället för separata tabeller.	Ett-till-få-relationer som läses tillsammans. En order med sina orderrader. En användare med tre adresser.
⤢Referencing	Lagra ett främmande id, inte data. Lös upp det med en ny läsning eller en $lookup.	Stora, delade eller självständigt uppdaterade underentiteter. Många-till-många-länkar mellan samlingar.
⤢One-to-few	Föräldern bäddar in en kort array av barn; hela mängden får plats och laddas som ett dokument.	En handfull telefonnummer eller inställningar på en profil. En läsning returnerar förälder och barn.
⤢One-to-many	Barnen bor i sin egen samling; varje barn bär förälderns id, eller föräldern håller en begränsad id-array.	Mängder för stora eller för självständiga att bädda in. Hämta barn via förälder-id.
⤢One-to-squillions	Barnet lagrar förälderns id; föräldern listar aldrig barnen, eftersom mängden är obegränsad.	Händelser, loggar eller röster knutna till en värd eller användare. Filtrera barnen på förälder-id och paginera.
⤢Polymorphic document	Dokument av olika entitetstyper delar en samling, åtskilda av ett typfält.	Kommentarer eller aviseringar kopplade till många slags föräldrar, alla frågade på samma sätt.
⤢Outlier pattern	Några få extrema entiteter bryts ut ur den gemensamma formen så att deras storlek eller trafik inte förvränger resten.	Kändiskonton vars följlistor eller räknare annars skulle växa ifrån det normala dokumentet.
⤢Document versioning	Varje revision är ett nytt dokument med samma id och ett stigande versionsnummer; frågan väljer den senaste.	Spårloggar och redigeringshistorik där gamla revisioner förblir sökbara.
⤢Computed pattern	Härledda värden beräknas vid skrivning och lagras bredvid de data de sammanfattar.	Summor, betyg och topp-N som annars skulle köra en aggregering vid varje läsning.
Nyckel-värde och wide-column
⤢Single-table	DynamoDB-designterm: slå ihop många entitetstyper till en tabell med överlagrade partitions- och sorteringsnycklar.	Hämta heterogena objekt i en enda fråga, utan join.
⤢Overloaded key	Ett nyckelattribut betjänar många entitetstyper, markerat med prefix som USER# eller ORDER#.	Single-table-design. Klustra besläktade objekt under en partition och hämta dem i en fråga.
⤢Partition + sort	En partitionsnyckel sprider rader över noder; en sorteringsnyckel ordnar varje partition.	Cassandra och DynamoDB. Intervallsökningar, ordnade loggar, hierarkiska sammansatta nycklar.
⤢Composite sort key	Stapla flera attribut i en sorteringsnyckel med avgränsare — country#region#city — så går en prefixmatchning ner i hierarkin.	Hierarkier och multifasettfilter. En ordnad intervallfråga ersätter många indexuppslag.
⤢Time bucketing	Gruppera händelser i fasta fönster — timme, dag, månad — under egna partitioner eller tabeller.	Mätvärden, loggar och IoT-telemetri. Begränsar partitionsstorleken och faser ut kall data.
⤢Denormalization	Duplicera läsintensiva fält över poster så att en fråga aldrig jagar ett andra uppslag.	Läsintensiva arbetsbelastningar där eventuell konsistens är acceptabel och lagring billig.
⤢GSI / sparse index	Ett sekundärindex byggt på ett attribut som bara vissa objekt har; objekt utan det hamnar aldrig i indexet.	Alternativa åtkomstvägar. Hitta den glesa delmängden — öppna ordrar, oskickade varor — utan en full genomsökning.
⤢Query-first modeling	Skriv ner de exakta frågorna först; tabellayouten härleds ur dem, inte ur entiteter eller normalform.	Schemaarbete i Cassandra och DynamoDB. En tabell per frågefamilj; datamodellen kopierar frågan.
⤢Scatter-gather anti-pattern	En fråga måste träffa många partitioner eller noder parallellt, eftersom ingen nyckel matchar frågan.	En lukt att designa bort, inte ett mål. Ändra nycklarna så att den vanliga frågan landar på en partition.
⤢Fan-out on write vs read	Kopior skickas till varje läsares vy vid skrivning, eller samlas och sammanfogas vid läsning.	Flöden och tidslinjer. Fan-out vid skrivning för små publiker, vid läsning för enorma.
⤢Materialized view	Ett förbyggt frågeresultat lagrat som egen tabell, hållet aktuellt allteftersom basen ändras.	Alternativa läsformer över en enda skrivväg. Betjänar frågor som bastabellen inte kan svara på.
Graf
⤢Adjacency list	Varje kant är en rad eller tuppel som pekar från en källnod till en målnod.	Graf- och egendskapslager. Vänners-vänner-uppslag, routing, rekommendationer.
⤢Edge document	Varje relation är ett dokument i egen samling, med from-id och to-id plus länkattribut.	Grafer i dokumentlager. Attribut på själva länken — betyg, roll, tidsstämpel.
⤢Nested sets	Varje nod lagrar vänster- och högerräknare från ett djupet-först-varv; ett delträd bor inom förälderns intervall.	Läsintensiva träd. En BETWEEN-fråga returnerar ett delträd; infogningar omnumrerar varvet.
⤢Closure table	En egen tabell registrerar varje förfader-till-ättling-par, inklusive varje nod på djup noll.	Frågor på hela grenar på varje djup. Enkla joins, betalda med lagring och underhåll.
⤢Property graph vs RDF	Egenskapsgrafer fäster nyckel-värde-attribut på noder och kanter; RDF uttrycker allt som subjekt-predikat-objekt-tripler.	Egenskapsgrafer för rika traverseringar (Neo4j); RDF för länkade öppna data och ontologiutbyte.
Vektor
⤢Vector embedding	En högdimensionell float-array ligger bredvid metadata. Ett ANN-index hittar närmaste grannar.	Semantisk sökning, RAG-hämtning, rekommendationer och likhet över ostrukturerat innehåll.
⤢Chunking strategy	Källdokument delas upp — efter storlek, överlapp eller struktur — innan varje del bäddas in för sig.	RAG-hämtkvalitet. Chunkstorleken väger precision mot recall; överlapp skyddar delade meningar.
⤢Hybrid search	Tät vektorlikhet körs bredvid nyckelordssökning; de två rankade listorna smälter samman till ett resultat.	Frågor som behöver exakta termer och mening på en gång, med metadatafilter ovanpå.