Comprendre les modèles de magasin de données

  • Article

Les systèmes d’entreprise modernes gèrent des volumes de données hétérogènes de plus en plus importants. Cette hétérogénéité signifie qu’un magasin de données unique n’est généralement pas la meilleure approche. Au lieu de cela, il est souvent préférable de stocker les différents types de données dans plusieurs magasins de données, chacun étant consacré à une charge de travail ou à un modèle d'utilisation spécifique. Le terme persistance polyglotte est utilisé pour décrire les solutions utilisant une combinaison de technologies de magasin de données. Par conséquent, il est important de comprendre les principaux modèles de stockage ainsi que leurs compromis.

La sélection du magasin de données correspondant à vos besoins est une décision de conception primordiale. Il existe des centaines d’implémentations possibles entre les bases de données SQL et NoSQL. Les magasins de données sont souvent classés selon la façon dont ils structurent les données et les types d’opérations qu’ils prennent en charge. Cet article décrit certains des modèles de stockage les plus courants. Notez qu’une technologie de magasin de données particulière peut prendre en charge plusieurs modèles de stockage. Par exemple, les systèmes de gestion de base de données relationnelle (SGBDR) peuvent également prendre en charge le stockage graphique ou de paires clé/valeur. En fait, il existe une tendance générale pour ce que l'on appelle la prise en charge multimodèle, où un système de base de données unique prend en charge plusieurs modèles. Mais il est toujours utile de comprendre les différents modèles à un niveau élevé.

Tous les magasins de données d’une catégorie donnée ne fournissent pas le même ensemble de fonctionnalités. La plupart des magasins de données fournissent des fonctionnalités côté serveur pour demander et traiter des données. Cette fonctionnalité est parfois intégrée dans le moteur de stockage de données. Dans d’autres cas, les capacités de stockage et de traitement de données sont séparées, et il peut y avoir plusieurs options de traitement et d’analyse. Les magasins de données prennent également en charge différentes interfaces de programmation et de gestion.

En règle générale, vous devriez commencer par envisager le modèle de stockage convenant le mieux à vos besoins. Envisagez ensuite un magasin de données particulier au sein de cette catégorie, en fonction de facteurs tels que les fonctionnalités, le coût et la facilité de gestion.

Notes

Apprenez-en davantage sur l’identification et la révision des exigences de votre service de données pour l’adoption du cloud dans Microsoft Cloud Adoption Framework pour Azure. De même, vous pouvez en apprendre davantage sur la sélection des outils et services de stockage.

Systèmes de gestion de base de données relationnelle

Les bases de données relationnelles organisent les données comme une série de tables à deux dimensions avec des lignes et des colonnes. La plupart des fournisseurs proposent un dialecte du langage SQL pour la récupération et la gestion des données. En règle générale, un SGBDR implémente un mécanisme cohérent au niveau transactionnel et conforme au modèle ACID (atomicité, cohérence, isolation, durabilité) pour mettre les informations à jour.

Un SGBDR prend normalement en charge un modèle de schéma à l’écriture, où la structure de données est définie à l’avance, et toutes les opérations de lecture et d’écriture doivent utiliser ce schéma.

Ce modèle est très utile lorsque de fortes garanties de cohérence sont importantes, où toutes les modifications sont atomiques et où les transactions laissent toujours les données dans un état cohérent. Toutefois, un SGBDR ne peut généralement pas effectuer un scale-out horizontalement sans partitionner les données d’une certaine façon. En outre, les données d’un SGBDR doivent être normalisées, ce qui n’est pas approprié pour tous les jeux de données.

Services Azure

Charge de travail

  • Les enregistrements sont régulièrement créés et mis à jour.
  • Plusieurs opérations doivent être effectuées dans une même transaction.
  • Les relations sont mises en œuvre en utilisant des contraintes de base de données.
  • Des index sont utilisés pour optimiser les performances des requêtes.

Type de données

  • Les données sont très normalisées.
  • Des schémas de base de données sont exigés et appliqués.
  • Relations plusieurs à plusieurs entre les entités de données de la base de données.
  • Des contraintes sont définies dans le schéma et imposées aux données de la base de données.
  • Les données nécessitent un haut niveau d’intégrité. Les index et les relations doivent être gérés avec précision.
  • Les données nécessitent une cohérence forte. Les transactions s’exécutent de façon à assurer une cohérence à 100 % de toutes les données pour l’ensemble des utilisateurs et des processus.
  • Les entrées de données individuelles sont de taille petite à moyenne.

Exemples

  • Gestion des stocks
  • Gestion des commandes
  • Base de données de création de rapports
  • Comptabilité

Magasins de clés/valeurs

Un magasin de clés/valeurs associe chaque valeur de données à une clé unique. La plupart des magasins de clés/valeurs prennent uniquement en charge les opérations simples de requête, d’insertion et de suppression. Pour modifier une valeur (partiellement ou entièrement), une application doit remplacer les données existantes pour la valeur entière. Dans la plupart des implémentations, la lecture ou écriture d’une valeur unique est une opération atomique.

Une application peut stocker des données arbitraires comme jeu de données. Toutes les informations de schéma doivent être fournies par l’application. Le magasin de clés/valeurs récupère ou stocke simplement la valeur par clé.

Diagram of a key-value store

Les magasins de clés/valeurs sont fortement optimisés pour les applications effectuant des recherches simples, mais ils sont moins adaptés si vous devez interroger des données dans plusieurs magasins de clés/valeurs. Les magasins de clés/valeurs ne sont pas non plus optimisés pour la requête par valeur.

Un magasin de clés/valeurs unique peut être extrêmement évolutif, étant donné qu’il peut facilement distribuer des données entre plusieurs nœuds sur des machines distinctes.

Services Azure

Charge de travail

  • Les données sont accessibles à l’aide d’une clé unique, comme un dictionnaire.
  • Utilisation de jointures, de verrous ou d’unions non obligatoire.
  • Aucun mécanisme d’agrégation n’est utilisé.
  • Les index secondaires ne sont généralement pas utilisés.

Type de données

  • Chaque clé est associée à une valeur unique.
  • Absence d’application de schéma.
  • Absence de relations entre les entités.

Exemples

  • Mise en cache des données
  • Gestion des sessions
  • Gestion des préférences et des profils utilisateur
  • Recommandation de produits et affichage d’annonces

Bases de données de documents

Un magasin de bases de données de documents est une collection de documents dans laquelle chaque document se compose de champs nommés et de données. Les données peuvent être des valeurs simples ou des éléments complexes, tels que des listes et des collections enfants. Les documents sont récupérés avec des clés uniques.

Généralement, un document contient les données d’une entité unique, par exemple, un client ou un ordre. Un document peut contenir des informations réparties sur plusieurs tables relationnelles dans un SGBDR. Les documents ne doivent pas nécessairement avoir la même structure. Les applications peuvent stocker des données différentes dans des documents selon les changements d’exigence pour l’entreprise.

Diagram of a document store

Service Azure

Charge de travail

  • Les opérations d’insertion et de mise à jour sont courantes.
  • Pas d’anomalie d’impédance objet-relationnel. Les documents peuvent mieux correspondre aux structures d’objet utilisées dans le code d’application.
  • Les documents individuels sont récupérés et écrits en un seul bloc.
  • Les données exigent la présence d’un index sur plusieurs champs.

Type de données

  • Les données peuvent être gérées de façon dénormalisée.
  • Les données des documents individuels sont relativement peu volumineuses.
  • Chaque type de document peut utiliser son propre schéma.
  • Les documents peuvent inclure des champs facultatifs.
  • Les données des documents sont semi-structurées, ce qui signifie que les types de données de chaque champ ne sont pas strictement définis.

Exemples

  • Catalogue produits
  • Gestion de contenu
  • Gestion des stocks

Bases de données de graphiques

Une base de données de graphiques stocke deux types d’informations, les nœuds et les bords. Les bords définissent les relations entre les nœuds. Les nœuds et les bords peuvent avoir des propriétés fournissant des informations sur ce nœud ou ce bord, semblables aux colonnes dans une table. Les bords peuvent également avoir un sens indiquant la nature de la relation.

Les bases de données de graphe peuvent exécuter efficacement des requêtes sur le réseau de nœuds et de bords, mais aussi analyser les relations entre les entités. Le diagramme suivant montre la structure de la base de données du personnel d’une entreprise sous forme de graphique. Les entités sont les employés et les services, les bords indiquent les relations hiérarchiques et les services de chaque employé.

Diagram of a document database

Cette structure simplifie l’exécution de requêtes telles que « Trouver tous les employés qui rendent compte directement ou indirectement à Sarah » ou « Qui travaille dans le même service que John ? ». Pour les graphiques de grande taille avec un grand nombre d’entités et de relations, vous pouvez effectuer des analyses très complexes en un temps record. Plusieurs bases de données de graphiques fournissent un langage de requête que vous pouvez utiliser pour parcourir efficacement un réseau de relations.

Services Azure

Charge de travail

  • Des relations complexes entre les éléments de données, impliquant de nombreux sauts entre les éléments de données associés.
  • Les relations entre les éléments de données sont dynamiques et changent dans le temps.
  • Les relations entre les objets sont des entités de première classe, sans qu’il soit nécessaire de traverser des clés étrangères et des jointures.

Type de données

  • Nœuds et relations.
  • Les nœuds s’apparentent à des lignes de table ou à des documents JSON.
  • Les relations sont tout aussi importantes que les nœuds et sont directement exposées dans le langage de requête.
  • Les objets composites, tels qu’une personne ayant plusieurs numéros de téléphone, ont tendance à être divisés en nœuds distincts plus petits, en association avec des relations qui peuvent être traversées.

Exemples

  • Organigrammes
  • Graphiques de réseau sociaux
  • Détection des fraudes
  • Moteurs de recommandation

Analyse de données

Les magasins d’analyse de données proposent des solutions massivement parallèles pour les opérations de réception, de stockage et d’analyse des données. Les données sont réparties sur plusieurs serveurs pour agrandir la scalabilité. Les formats de fichiers de données volumineux, tels que les fichiers de délimiteur (CSV), les fichiersParquetet ORC sont largement utilisés dans l’analytique données. Les données d’historique sont généralement stockées dans des magasins de données, tels que le stockage blob ou Azure Data Lake Storage Gen2, accessibles via Azure Synapse, Databricks ou HDInsight faisant office de tables externes. L’article Utiliser des tables externes avec Synapse SQL décrit un scénario classique avec l’utilisation des données stockées en tant que fichiers Parquet pour des raisons de performances.

Services Azure

Charge de travail

  • Analyse de données
  • Décisionnel d’entreprise

Type de données

  • Données d’historique de plusieurs sources.
  • Généralement dénormalisé dans un schéma « en étoile » ou « en flocon », constitué de tables de faits et de dimensions.
  • Généralement chargé de façon régulière avec de nouvelles données.
  • Les tables de dimension comprennent souvent plusieurs versions historiques d’une entité, appelée dimension à variation lente.

Exemples

  • Entrepôt de données d’entreprise

Bases de données de familles de colonnes

Une base de données de familles de colonnes organise les données en lignes et en colonnes. Dans sa forme la plus simple, une base de données de familles de colonnes peut sembler, au moins sur le plan conceptuel, très similaire à une base de données relationnelle. La puissance d’une base de données de familles de colonnes se trouve dans son approche dénormalisé pour la structuration des données éparses.

Vous pouvez considérer une base de données de familles de colonnes comme contenant des données tabulaires avec des lignes et des colonnes, mais les colonnes sont divisées en groupes nommés familles de colonne. Chaque famille de colonnes conserve un ensemble de colonnes logiquement liées entre elles et généralement récupérées ou manipulées en tant qu’unité. Les autres données accessibles séparément peuvent être stockées dans des familles de colonnes distinctes. Dans une famille de colonnes, de nouvelles colonnes peuvent être ajoutées dynamiquement, et des lignes peuvent être incomplètes (autrement dit, une ligne n’a pas besoin d’avoir une valeur pour chaque colonne).

Le diagramme suivant montre un exemple avec deux familles de colonnes, Identity et Contact Info. Les données d’une même entité ont la même clé de ligne dans chaque famille de colonnes. Cette structure, où les lignes pour un objet donné dans une famille de colonnes peuvent être modifiées dynamiquement, constitue un avantage important de l’approche par famille de colonnes, rendant cette forme de magasin de données hautement adaptée pour le stockage des données structurées et volatiles.

Diagram of a column-family database

Contrairement à un magasin de clés/valeurs ou une base de données de documents, la plupart des bases de données de familles de colonnes stockent les données dans l’ordre des clés, plutôt qu’en calculant un hachage. De nombreuses implémentations permettent de créer des index sur des colonnes spécifiques dans une famille de colonnes. Les index vous permettent de récupérer des données à partir de la valeur des colonnes, au lieu d’utiliser la clé de ligne.

Les opérations de lecture et d’écriture pour une ligne sont généralement atomiques avec une famille de colonnes unique, même si certaines implémentations permettent l’atomicité sur la ligne entière, couvrant alors plusieurs familles de colonne.

Services Azure

Charge de travail

  • La plupart des bases de données de familles de colonnes effectuent les opérations d’écriture de manière extrêmement rapide.
  • Les opérations de mise à jour et de suppression sont rares.
  • Conçu pour offrir un débit élevé et un accès à faible latence.
  • Permet aux requêtes d’accéder facilement à un ensemble particulier de champs au sein d’un enregistrement bien plus volumineux.
  • Scalabilité importante.

Type de données

  • Les données sont stockées dans des tables comprenant une colonne clé et une ou plusieurs familles de colonnes.
  • Certaines colonnes peuvent varier par lignes individuelles.
  • Les cellules individuelles sont accessibles via des commandes get et put.
  • Plusieurs lignes sont retournées en utilisant une commande scan.

Exemples

  • Recommandations
  • Personnalisation
  • données de capteur
  • Télémétrie
  • Messagerie
  • Analytique des réseaux sociaux
  • Analytique web
  • Surveillance de l’activité
  • Météo et autres données de séries chronologiques

Bases de données de moteur de recherche

Une base de données de moteur de recherche permet aux applications de rechercher des informations contenues dans des magasins de données externes. Une base de données de moteur de recherche peut indexer d’importants volumes de données et fournir un accès à ces index quasiment en temps réel.

Les index peuvent être multidimensionnels et peuvent prendre en charge les recherches en texte libre sur de grands volumes de données de texte. L’indexation peut être effectuée à l’aide d’un modèle d’extraction, déclenché par la base de données de moteur de recherche, ou à l’aide d’un modèle d’émission, initié par le code de l’application externe.

La recherche peut être exacte ou approximative. Une recherche approximative trouve les documents correspondant à un ensemble de conditions et calcule leur niveau de correspondance. Certains moteurs de recherche prennent également en charge l’analyse linguistique pouvant renvoyer les correspondances basées sur les synonymes, des expansions de genre (par exemple, mise en correspondance de dogs avec pets) et la recherche du radical (correspondance de mots avec la même racine).

Service Azure

Charge de travail

  • Index de données de plusieurs sources et services.
  • Les requêtes sont de type ad hoc et peuvent être complexes.
  • La recherche en texte intégral est obligatoire.
  • Nécessite une requête en libre service ad hoc.

Type de données

  • Texte semi-structuré ou non structuré
  • Texte avec référence à des données structurées

Exemples

  • Catalogue produits
  • Recherche sur site
  • Journalisation

Bases de données de séries chronologiques

Les données de la série chronologique constituent un ensemble de valeurs organisés chronologiquement. Les bases de données de séries chronologiques collectent généralement d’importantes quantités de données en temps réel à partir d’un grand nombre de sources. Les mises à jour sont rares, et les suppressions sont souvent réalisées par des opérations en bloc. Bien que les enregistrements écrits dans une base de données de séries chronologiques soient généralement petits, il existe souvent un grand nombre d’enregistrements, et la taille totale des données peut croître rapidement.

Service Azure

Charge de travail

  • Les enregistrements sont généralement ajoutés de manière séquentielle dans un ordre chronologique.
  • Les opérations sont dans une très large proportion (95-99 %) des écritures.
  • Les mises à jour sont rares.
  • Les suppressions se produisent en masse et concernent des blocs ou des enregistrements contigus.
  • Les données sont lues de manière séquentielle, en ordre de temps ascendant ou descendant, souvent en parallèle.

Type de données

  • Un timestamp est utilisé comme clé primaire et mécanisme de tri.
  • Les balises peuvent définir des informations supplémentaires sur le type, l’origine et d’autres informations sur l’entrée.

Exemples

  • Surveillance et données de télémétrie des événements.
  • Données de capteur ou autres données IoT.

Stockage d’objets

Le stockage d’objets est optimisé pour le stockage et la récupération d’objets binaires volumineux (images, fichiers, flux vidéo et audio, objets de données d’application et documents de grande taille, images de disque de machine virtuelle). Les fichiers de données volumineux sont également couramment utilisés dans ce modèle, par exemple, les fichiers de délimiteur (CSV), les fichiers Parquetet ORC. Les magasins d’objets peuvent gérer de très grandes quantités de données non structurées.

Service Azure

Charge de travail

  • Identifié par la clé.
  • Le contenu est généralement une ressource, par exemple un délimiteur, une image ou un fichier vidéo.
  • Le contenu doit être durable et extérieur à une couche Application.

Type de données

  • Données volumineuses.
  • Valeur opaque.

Exemples

  • Images, vidéos, documents Office, PDF
  • HTML statique, JSON, CSS
  • Fichiers journaux et d’audit
  • Sauvegardes de base de données

Fichiers partagés

Parfois, l’utilisation de fichiers plats simples est le moyen le plus efficace pour stocker et récupérer des informations. Les partages de fichiers permettent d’accéder aux fichiers via un réseau. Compte tenu de la sécurité et des mécanismes de contrôle d’accès simultanés, un tel partage de données peut permettre aux services distribués de fournir un accès de données hautement évolutif pour effectuer des opérations de base et de bas niveau telles que des requêtes simples de lecture et d’écriture.

Service Azure

Charge de travail

  • Migration à partir d’applications existantes qui interagissent avec le système de fichiers.
  • Nécessite une interface SMB.

Type de données

  • Fichiers figurant dans un ensemble hiérarchique de dossiers.
  • Accessible avec des bibliothèques d’E/S standard.

Exemples

  • Fichiers hérités
  • Contenu partagé accessible à un certain nombre de machines virtuelles ou d’instances d’application

Avec l’appui de cette compréhension des différents modèles de stockage des données, la prochaine étape consiste à évaluer votre charge de travail et votre application, puis à décider quel magasin de données est adapté à vos besoins. Utilisez l’arbre de décision de stockage des données pour faciliter ce processus.

Étapes suivantes