Tipare de modelare pentru baze de documente, cheie-valoare, coloane late, grafuri și vectori — când să înglobezi, să folosești referințe, să denormalizezi sau să grupezi pe ferestre de timp.
Bazele NoSQL renunță la schemele fixe și la join-uri în favoarea scalării orizontale. Fiecare familie modelează relațiile în felul ei, așa că tiparul de acces — nu forma normală — stabilește structura.
Tabel de referință · 28 intrări
Modelare date NoSQLExplained
28 of 28 rows
Documente
Subdocumentele imbricate trăiesc în interiorul unui singur document părinte, în loc de tabele separate.
Relații unul-către-câțiva citite împreună. O comandă cu liniile ei. Un utilizator cu trei adrese.
Stochează un id străin, nu datele. Rezolvă-l cu a doua citire sau un $lookup.
Subentități mari, partajate sau actualizate independent. Legături mulți-către-mulți între colecții.
Părintele înglobează un scurt array de copii; tot setul încape și se încarcă ca un singur document.
Câteva numere de telefon sau preferințe pe un profil. O citire returnează părintele și copiii.
Copiii trăiesc în propria colecție; fiecare copil poartă id-ul părintelui, sau părintele ține un array de id-uri mărginit.
Seturi prea mari sau prea independente pentru înglobare. Interoghează copiii după id-ul părintelui.
Copilul stochează id-ul părintelui; părintele nu listează niciodată copiii, pentru că setul e nemărginit.
Evenimente, jurnale sau voturi legate de un host sau un utilizator. Filtrează copiii după id-ul părintelui și paginează.
Documente de tipuri de entități diferite partajează o colecție, deosebite printr-un câmp de tip.
Comentarii sau notificări atașate la multe feluri de părinți, toate interogate la fel.
Câteva entități extreme sunt scindate din forma comună, astfel încât mărimea sau traficul lor nu denaturează restul.
Conturi de celebrități ale căror liste de urmăritori sau contoare ar depăși documentul normal.
Fiecare revizie e un document nou cu același id și un număr de versiune crescător; interogarea alege ultima.
Piste de audit și istoric de editare unde reviziile vechi rămân interogabile.
Valorile derivate se calculează la scriere și se stochează lângă datele pe care le rezumă.
Totaluri, evaluări și top-N care altfel ar rula o agregare la fiecare citire.
Cheie-valoare și coloane late
Termen de design DynamoDB: comasează multe tipuri de entități într-un singur tabel cu chei de partiție și de sortare supraîncărcate.
Aduce elemente eterogene într-o singură interogare, fără join.
Un singur atribut-cheie deservește multe tipuri de entități, marcat cu prefixe precum USER# sau ORDER#.
Designuri single-table. Grupează elemente înrudite sub o partiție și adu-le într-o singură interogare.
O cheie de partiție răspândește rândurile pe noduri; o cheie de sortare ordonează fiecare partiție.
Cassandra și DynamoDB. Scanări pe interval, jurnale ordonate, chei compozite ierarhice.
Împilează mai multe atribute într-o singură cheie de sortare cu delimitatori — country#region#city — astfel încât o potrivire de prefix coboară ierarhia.
Ierarhii și filtre multi-fațetă. O singură interogare ordonată pe interval înlocuiește multe căutări în indecși.
Grupează evenimentele în ferestre fixe — oră, zi, lună — sub partiții sau tabele dedicate.
Metrici, jurnale și telemetrie IoT. Limitează mărimea partițiilor și expiră datele reci.
Duplică câmpurile intens citite prin înregistrări, astfel încât o interogare să nu urmărească niciodată a doua căutare.
Sarcini dominate de citiri unde consistența eventuală e tolerabilă și stocarea e ieftină.
Un index secundar construit pe un atribut pe care doar unele elemente îl au; elementele fără el nu intră niciodată în index.
Căi de acces alternative. Găsește submulțimea rară — comenzi deschise, articole netrimise — fără un scan complet.
Scrie mai întâi interogările exacte; aranjamentul tabelului se derivă din ele, nu din entități sau forma normală.
Lucru de schemă în Cassandra și DynamoDB. Un tabel pe familie de interogări; modelul de date copiază întrebarea.
O interogare trebuie să lovească multe partiții sau noduri în paralel, pentru că nicio cheie nu se potrivește întrebării.
Un miros de eliminat din design, nu un scop. Re-cheiază tabelul astfel încât interogarea comună să aterizeze pe o singură partiție.
Copiile sunt împinse în vederea fiecărui cititor la scriere, sau adunate și fuzionate la citire.
Feed-uri și cronologii. Fan-out la scriere pentru audiențe mici, la citire pentru uriase.
Un rezultat de interogare pre-construit, stocat ca propriul tabel și menținut la zi pe măsură ce baza se schimbă.
Forme de citire alternative peste o singură cale de scriere. Deservește interogări la care tabelul de bază nu poate răspunde.
Grafuri
Fiecare muchie e un rând sau un tuplu care indică de la un nod sursă către un nod țintă.
Baze de grafuri și de proprietăți. Căutări prieten-al-prietenului, rutare, recomandări.
Fiecare relație e un document în propria colecție, purtând id-urile from și to plus atributele legăturii.
Grafuri în baze de documente. Atribute pe legătura însăși — evaluare, rol, marcaj temporal.
Fiecare nod stochează contoarele stânga și dreapta dintr-o parcurgere în adâncime; un subarbore trăiește în intervalul părintelui.
Arbori cu multe citiri. O singură interogare BETWEEN returnează un subarbore; inserțiile renumerotează parcurgerea.
Un tabel dedicat înregistrează fiecare pereche strămoș-descendent, inclusiv fiecare nod la adâncime zero.
Interogări pe ramuri întregi la orice adâncime. Join-uri simple, plătite cu stocare și mentenanță.
Grafurile de proprietăți atașează atribute cheie-valoare nodurilor și muchiilor; RDF enunță totul ca triplete subiect-predicat-obiect.
Grafuri de proprietăți pentru traversări bogate (Neo4j); RDF pentru date deschise legate și schimb de ontologii.
Vectori
Un array de float-uri cu multe dimensiuni stă lângă metadate. Un index ANN găsește vecinii cei mai apropiați.
Căutare semantică, regăsire RAG, recomandări și similaritate peste conținut nestructurat.
Documentele sursă sunt divizate — după mărime, suprapunere sau structură — înainte ca fiecare bucată să primească propriul embedding.