Modélisation des données NoSQLExplained

28 of 28 rows

Pattern↕	Ce que c'est↕	Utilisé pour↕
Document
⤢Embedding	Des sous-documents imbriqués vivent dans un document parent unique au lieu de tables séparées.	Relations un-à-quelques-uns lues ensemble. Une commande avec ses lignes. Un utilisateur avec trois adresses.
⤢Referencing	Stocker un id externe, pas les données. Le résoudre par une seconde lecture ou un $lookup.	Sous-entités volumineuses, partagées ou mises à jour indépendamment. Liens plusieurs-à-plusieurs entre collections.
⤢One-to-few	Le parent incorpore un court tableau d'enfants ; l'ensemble entier tient et se charge comme un seul document.	Quelques numéros de téléphone ou préférences sur un profil. Une lecture renvoie parent et enfants.
⤢One-to-many	Les enfants vivent dans leur propre collection ; chacun porte l'id du parent, ou le parent garde un tableau d'ids borné.	Ensembles trop grands ou trop indépendants pour être imbriqués. Interroger les enfants par id de parent.
⤢One-to-squillions	L'enfant stocke l'id du parent ; le parent ne liste jamais ses enfants car l'ensemble est sans borne.	Événements, journaux ou votes liés à un hôte ou un utilisateur. Filtrer les enfants par id de parent et paginer.
⤢Polymorphic document	Des documents de types d'entité différents partagent une même collection, distingués par un champ type.	Commentaires ou notifications rattachés à plusieurs sortes de parents, tous interrogés de la même façon.
⤢Outlier pattern	Quelques entités extrêmes sont sorties de la forme commune pour que leur taille ou leur trafic ne déforme pas le reste.	Comptes de célébrités dont les listes d'abonnés ou compteurs dépasseraient le document normal.
⤢Document versioning	Chaque révision est un nouveau document avec le même id et un numéro de version croissant ; la requête prend le dernier.	Pistes d'audit et historique d'édition où les anciennes révisions restent interrogeables.
⤢Computed pattern	Les valeurs dérivées sont calculées à l'écriture et stockées à côté des données qu'elles résument.	Totaux, notes et top-N qui lanceraient sinon une agrégation à chaque lecture.
Clé-valeur et colonnes larges
⤢Single-table	Terme de conception DynamoDB : regrouper plusieurs types d'entité dans une seule table via des clés de partition et de tri surchargées.	Récupérer des éléments hétérogènes en une requête sans jointure.
⤢Overloaded key	Un attribut de clé sert plusieurs types d'entité, marqués par des préfixes comme USER# ou ORDER#.	Conceptions en table unique. Regrouper des éléments liés sous une partition et les récupérer en une requête.
⤢Partition + sort	Une clé de partition répartit les lignes entre les nœuds ; une clé de tri ordonne chaque partition.	Cassandra et DynamoDB. Scans de plage, journaux ordonnés, clés composites hiérarchiques.
⤢Composite sort key	Empiler plusieurs attributs dans une clé de tri délimitée — country#region#city — pour qu'une correspondance de préfixe descende la hiérarchie.	Hiérarchies et filtres multi-facettes. Une requête de plage ordonnée remplace plusieurs recherches indexées.
⤢Time bucketing	Regrouper les événements en fenêtres fixes — heure, jour, mois — sous des partitions ou tables dédiées.	Métriques, journaux et télémétrie IoT. Borner la taille de partition et expirer les données froides.
⤢Denormalization	Dupliquer les champs très lus entre enregistrements pour qu'une requête ne cherche jamais une seconde lecture.	Charges majoritairement en lecture où la cohérence à terme est tolérable et le stockage bon marché.
⤢GSI / sparse index	Un index secondaire bâti sur un attribut que seuls certains éléments portent ; ceux qui en sont dépourvus n'y entrent jamais.	Chemins d'accès alternatifs. Trouver le sous-ensemble creux — commandes ouvertes, articles non expédiés — sans scan complet.
⤢Query-first modeling	Écrire d'abord les requêtes exactes ; la disposition de la table en découle, non des entités ni de la forme normale.	Travail de schéma Cassandra et DynamoDB. Une table par famille de requêtes ; le modèle de données copie la question.
⤢Scatter-gather anti-pattern	Une requête doit toucher en parallèle plusieurs partitions ou nœuds car aucune clé ne correspond à la question.	Une odeur à éliminer par conception, pas un objectif. Recasser la table pour que la requête courante tombe sur une partition.
⤢Fan-out on write vs read	Les copies sont poussées vers la vue de chaque lecteur à l'écriture, ou rassemblées et fusionnées à la lecture.	Flux et fils chronologiques. Fan-out à l'écriture pour petites audiences, à la lecture pour audiences énormes.
⤢Materialized view	Un résultat de requête pré-construit stocké comme sa propre table, maintenu à jour au fil des changements de la base.	Formes de lecture alternatives sur un seul chemin d'écriture. Sert des requêtes auxquelles la table de base ne peut pas répondre.
Graphe
⤢Adjacency list	Chaque arête est une ligne ou un tuple pointant d'un nœud source vers un nœud cible.	Bases de graphes et de propriétés. Recherches ami-d'ami, routage, recommandations.
⤢Edge document	Chaque relation est un document dans sa propre collection, portant les ids from et to plus des attributs de lien.	Graphes dans des bases de documents. Attributs sur le lien lui-même — note, rôle, horodatage.
⤢Nested sets	Chaque nœud stocke des compteurs gauche et droit issus d'un parcours en profondeur ; un sous-arbre vit dans la plage de son parent.	Arbres majoritairement lus. Une requête BETWEEN renvoie un sous-arbre ; les insertions renumérotent le parcours.
⤢Closure table	Une table dédiée enregistre chaque paire ancêtre-vers-descendant, y compris chaque nœud à profondeur zéro.	Requêtes de branche entière à toute profondeur. Jointures simples, payées en stockage et maintenance.
⤢Property graph vs RDF	Les graphes de propriétés attachent des attributs clé-valeur aux nœuds et aux arêtes ; RDF énonce tout en triplets sujet-prédicat-objet.	Graphes de propriétés pour la traversée riche (Neo4j) ; RDF pour les données ouvertes liées et l'échange d'ontologies.
Vectoriel
⤢Vector embedding	Un tableau de flottants de grande dimension se tient à côté des métadonnées. Un index ANN trouve les plus proches voisins.	Recherche sémantique, récupération RAG, recommandations et similarité sur du contenu non structuré.
⤢Chunking strategy	Les documents sources sont découpés — par taille, chevauchement ou structure — avant que chaque morceau soit plongé séparément.	Qualité de récupération RAG. La taille des morceaux arbitre précision contre rappel ; le chevauchement protège les phrases coupées.
⤢Hybrid search	La similarité vectorielle dense tourne à côté de la correspondance par mots-clés ; les deux listes classées fusionnent en un résultat.	Requêtes exigeant à la fois termes exacts et sens, avec filtres de métadonnées par-dessus.