Partager via

Comprendre les modèles de données

Les solutions modernes gèrent diverses données, telles que les transactions, les événements, les documents, la télémétrie, les ressources binaires et les faits analytiques. Un magasin de données unique satisfait rarement tous les modèles d’accès efficacement. La plupart des systèmes de production adoptent la persistance polyglotte, ce qui signifie que vous sélectionnez plusieurs modèles de stockage. Cet article centralise les définitions canoniques des modèles de magasin de données principaux disponibles sur Azure et fournit des tables comparatives pour accélérer la sélection du modèle avant de choisir des services spécifiques.

Procédez comme suit pour sélectionner vos modèles de données :

  1. Identifiez les modèles d’accès aux charges de travail, tels que les lectures ponctuelles, les agrégations, la recherche en texte intégral, la similarité, l'analyse par fenêtre temporelle et la distribution d'objets.

  2. Associez les schémas aux modèles de stockage dans les sections suivantes.

  3. Créez une liste abrégée des services Azure qui implémentent ces modèles.

  4. Appliquez des critères d’évaluation, tels que la cohérence, la latence, la mise à l’échelle, la gouvernance et le coût.

  5. Combinez des modèles uniquement lorsque les modèles d’accès ou les cycles de vie diffèrent clairement.

Comment utiliser ce guide

Chaque section de modèle comprend une définition concise, des charges de travail classiques, des caractéristiques de données, des exemples de scénarios et des liens vers des services Azure représentatifs. Chaque section inclut également un tableau pour vous aider à choisir le service Azure approprié pour votre cas d’usage. Dans certains cas, vous pouvez utiliser d’autres articles pour faire des choix plus éclairés sur les options de service Azure. Les sections de modèle respectives font référence à ces articles.

Deux tables comparatives résument les caractéristiques de modèle non relationnelles pour vous aider à évaluer rapidement les options sans répéter le contenu entre les sections.

Vue d’ensemble de la classification

Catégorie Objectif principal Exemples de service Azure standard
Relationnel (OLTP) Opérations transactionnelles cohérentes Azure SQL Database, Azure Database pour PostgreSQL ou Azure Database pour MySQL
Non relationnelle, comme le document, la clé-valeur, la famille de colonnes et le graphique Charges de travail flexibles centrées sur le schéma ou les relations API Azure Cosmos DB, Azure Managed Redis, Managed Cassandra ou HBase
Série chronologique Métriques et événements horodatés à débit élevé Azure Data Explorer ou Eventhouse dans Fabric
Objet et fichier Stockage de fichiers binaires ou semi-structurés volumineux Stockage Blob Azure ou Stockage Azure Data Lake
Recherche et indexation Pertinence en texte intégral et multichamp, indexation secondaire Recherche d’IA Azure
Vector Similarité sémantique ou approximative du voisin le plus proche (ANN) Variantes Azure AI Search ou Azure Cosmos DB
Analytique, traitement analytique en ligne (OLAP), traitement massivement parallèle (MPP) Agrégation historique à grande échelle ou intelligence d'affaires (BI) Microsoft Fabric, Azure Data Explorer, Azure Analysis Services ou Azure Databricks

Note

Un seul service peut fournir plusieurs modèles, également appelés multimodel. Choisissez le modèle le mieux adapté au lieu de combiner des modèles d’une manière qui complique les opérations.

Magasins de données relationnelles

Les systèmes de gestion des bases de données relationnelles organisent les données en tables normalisées à l’aide d’un schéma en écriture. Ils appliquent l’intégrité et prennent en charge les transactions ACID: atomicité, cohérence, isolation et durabilité, ainsi que les requêtes SQL enrichies.

Forces: Cohérence transactionnelle à plusieurs lignes, jointures complexes, contraintes relationnelles fortes et outils matures pour la création de rapports, l’administration et la gouvernance.

Considérations: L'échelle horizontale nécessite généralement le sharding ou le partitionnement, et la normalisation peut augmenter le coût de jointure pour les vues dénormalisées lourdes en lecture.

Charges: Gestion des commandes, suivi des stocks, enregistrement du registre financier, facturation et rapports opérationnels.

Sélectionner un service Azure pour les magasins de données relationnelles

  • SQL Database est une base de données relationnelle managée pour les applications cloud modernes qui utilisent le moteur SQL Server.

  • Azure SQL Managed Instance est un environnement SQL Server presque complet dans le cloud qui est idéal pour les migrations lift-and-shift.

  • SQL Database (Hyperscale) est un niveau SQL hautement évolutif conçu pour les charges de travail massives avec une mise à l’échelle automatique rapide et des sauvegardes rapides.

  • Azure Database pour PostgreSQL est un service PostgreSQL managé qui prend en charge les extensions open source et les options de déploiement flexibles.

  • Azure Database pour MySQL est une base de données MySQL managée pour les applications web et les charges de travail open source.

  • SQL Database dans Fabric est une base de données transactionnelle conviviale, basée sur SQL Database, que vous pouvez utiliser pour créer facilement une base de données opérationnelle dans Fabric.

Utilisez le tableau suivant pour déterminer le service Azure qui répond à vos besoins en cas d’usage.

Service Idéal pour Fonctionnalités clés Exemple de cas d’usage
Base de données SQL Applications cloud-natives Pools élastiques managés, Hyperscale, haute disponibilité intégrée, sécurité avancée Création d’une application SaaS (Software as a Service) moderne à l’aide d’un back-end SQL évolutif
SQL Managed Instance Applications d’entreprise héritées Compatibilité complète de SQL Server, prise en charge lift-and-shift, réseaux virtuels, audit avancé Migration d’une application SQL Server locale à l’aide de modifications de code minimales
SQL Database (Hyperscale) Diffusion mondiale Extensibilité de lecture multirégion, géoréplication, mise à l’échelle automatique rapide Service d’une application distribuée mondialement nécessitant un débit de lecture élevé
Base de données Azure pour PostgreSQL Charges de travail d’analytique open source PostGIS, Hyperscale, Serveur flexible, extensions open source Développement d’une application d’analytique géospatiale à l’aide de PostgreSQL et PostGIS
Base de données Azure pour MySQL Applications web légères Serveur flexible, compatibilité open source, économique Hébergement d’un site de commerce électronique basé sur WordPress
Base de données SQL dans Fabric Charges de travail de traitement des transactions en ligne (OLTP) dans l’écosystème Fabric Basé sur le moteur SQL Database, évolutif et intégré à Fabric Création d’applications IA sur un modèle de données relationnelles opérationnel qui inclut des fonctionnalités de recherche vectorielle native

Magasins de données non relationnelles

Les bases de données non relationnelles, également appelées bases de données NoSQL, optimisent les schémas flexibles, la mise à l’échelle horizontale et les modèles d’accès ou d’agrégation spécifiques. Ils détendent généralement certains aspects du comportement relationnel, tels que la rigidité du schéma et l’étendue des transactions, pour la scalabilité ou l’agilité.

Stockages de données documentaires

Utilisez des magasins de données de document pour stocker des documents semi-structurés, souvent au format JSON, où chaque document inclut des champs nommés et des données. Les données peuvent être des valeurs simples ou des éléments complexes, tels que des listes et des collections enfants. La flexibilité du schéma par document permet une évolution progressive.

Forces: Mappage d’objets d’application naturel, agrégats dénormalisés, indexation multi-champs

Considérations: Croissance de la taille du document, étendue transactionnelle sélective, nécessité d’une conception de forme de données minutieuse pour les requêtes à grande échelle

Charges: Catalogues de produits, gestion de contenu, magasins de profils

Sélectionner un service Azure pour les magasins de données de documents

  • Azure Cosmos DB pour NoSQL est une base de données NoSQL sans schéma et multirégion qui a des lectures et des écritures à faible latence.

  • Azure DocumentDB est une base de données distribuée mondialement qui a la compatibilité du protocole filaire MongoDB et la mise à l’échelle automatique.

  • Azure Cosmos DB dans Fabric est une base de données NoSQL sans schéma qui a des lectures et des écritures à faible latence, une gestion simplifiée et une analytique Fabric intégrée.

Utilisez le tableau suivant pour déterminer le service Azure qui répond à vos besoins en cas d’usage.

Service Idéal pour Fonctionnalités clés Exemple de cas d’usage
Azure Cosmos DB pour NoSQL Modèles de documents JSON personnalisés qui prennent en charge l’interrogation de type SQL Langage de requête avancé, écritures multi-régions, temps de durée de vie (TTL), flux de modification Création d'une plateforme SaaS multi-locataire qui prend en charge des schémas flexibles
Azure DocumentDB Applications qui utilisent des pilotes MongoDB ou des API centrées sur JSON Distribution mondiale, mise à l’échelle automatique, protocole filaire natif MongoDB Migration d’une application Node.js de MongoDB vers Azure
Azure Cosmos DB dans Fabric Analytique en temps réel sur les données NoSQL Extraction, transformation et chargement automatiques (ETL) vers OneLake via l’intégration de Fabric Applications transactionnelles qui incluent des tableaux de bord analytiques en temps réel

Magasins de données de famille de colonnes

Une base de données de famille de colonnes, également appelée base de données à large colonne, stocke des données éparses dans des lignes et organise des colonnes dynamiques en familles de colonnes pour prendre en charge la co-accès. L’orientation des colonnes améliore les analyses sur les jeux de colonnes sélectionnés.

Forces: Débit d’écriture élevé, récupération efficace de jeux de données larges ou éparses, schéma dynamique au sein des familles

Considérations: Conception de la clé de ligne en amont et de la famille de colonnes, prise en charge variable des index secondaires, flexibilité des requêtes inférieure au modèle relationnel.

Charges de travail : Télémétrie de l'Internet des objets (IoT), personnalisation, préagrégation d'analytique, données volumineuses de type série temporelle lorsque vous n'utilisez pas une base de données dédiée aux séries temporelles

Sélectionner un service Azure pour les magasins de données à famille de colonnes

Utilisez le tableau suivant pour déterminer le service Azure qui répond à vos besoins en cas d’usage.

Service Idéal pour Fonctionnalités clés Exemple de cas d’usage
Azure Managed Instance pour Apache Cassandra Charges de travail Cassandra nouvelles et migrées Apache Cassandra géré, natif Ingestion de télémétrie des appareils IoT compatible avec Cassandra
Apache HBase sur HDInsight Écosystème Hadoop, analytique par lots Intégration du système de fichiers distribués Hadoop (HDFS), traitement par lots à grande échelle Traitement par lots des données de capteur dans une usine de fabrication
Azure Data Explorer (Kusto) Télémétrie à réception élevée, analytique de série chronologique KQL, requêtes ad hoc rapides, fonctions de fenêtre de temps Analytique en temps réel pour les journaux d’activité et les métriques des applications

Magasins de données clé-valeur

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

Forces: Simplicité, faible latence, scalabilité linéaire

Considérations: Expressivité limitée des requêtes, remaniement nécessaire pour les recherches basées sur la valeur, coût de remplacement de valeur élevée

Charges: Mise en cache, sessions, indicateurs de fonctionnalité, profils utilisateur, recherches de recommandations

Sélectionner un service Azure pour les stockages de données clé-valeur

  • Azure Managed Redis est un magasin de données en mémoire géré basé sur la dernière version de Redis Enterprise qui offre une faible latence et un débit élevé.

  • Azure Cosmos DB pour Table est un magasin clé-valeur optimisé pour un accès rapide aux données NoSQL structurées.

  • Azure Cosmos DB pour NoSQL est un magasin de données de documents optimisé pour un accès rapide aux données NoSQL structurées et fournit une scalabilité horizontale.

Utilisez le tableau suivant pour déterminer le service Azure qui répond à vos besoins en cas d’usage.

Service Idéal pour Fonctionnalités clés Exemple de cas d’usage
Redis managé Azure Mise en cache à haut débit, état de session, publication-abonnement Magasin en mémoire, latence sous-milliseconde, protocole Redis Mise en cache des pages de produits pour un site de commerce électronique
Azure Cosmos DB pour Table Migration des charges de travail de stockage table Azure existantes Compatibilité de l’API Stockage Table Stockage des préférences et des paramètres utilisateur dans une application mobile
Azure Cosmos DB pour NoSQL Mise en cache à grande vitesse avec une grande mise à l’échelle et une haute disponibilité Mise à l’échelle automatique sans schéma préalable, multi-régional Mise en cache, état de session, couche de service

Stores de données graphiques

Une base de données de graphe stocke des informations en tant que nœuds et arêtes. Les arêtes définissent des relations, et les nœuds et les arêtes peuvent avoir des propriétés similaires aux colonnes de table. Vous pouvez analyser les connexions entre les entités, telles que les employés et les services.

Atouts: Modèles d’interrogation orientés sur les relations, traversées de profondeur variable efficaces

Considérations: La surcharge si les relations sont superficielles, nécessite une modélisation minutieuse pour les performances, pas idéale pour les analyses massives

Charges de travail : Réseaux sociaux, réseaux de fraude, graphes de connaissances, dépendances de la chaîne d'approvisionnement

Sélectionner un service Azure pour les magasins de données graph

Utilisez des extensions de graphique SQL Server pour stocker des données de graphe. L’extension de graphe étend les fonctionnalités de SQL Server, SQL Database et SQL Managed Instance pour permettre la modélisation et l’interrogation de relations complexes à l’aide de structures de graphe directement dans une base de données relationnelle.

Magasins de données de série chronologique

Les bases de données temporelles gèrent un ensemble de valeurs organisées par temps. Ils prennent en charge des fonctionnalités telles que les requêtes et les agrégations basées sur le temps. Ils sont optimisés pour ingérer et analyser de grands volumes de données en quasi-temps réel. Ils sont généralement des bases de données d’ajout uniquement.

Points forts : Compression, ingestion à volume élevé, requêtes de fenêtres temporelles et agrégations, gestion de l’ingestion hors ordre

Considérations: Gestion de la cardinalité des étiquettes, coût de rétention, stratégie d’échantillonnage inférieur, langages de requête spécialisés

Charges: Métriques de capteur IoT, télémétrie des applications, surveillance, données industrielles et données de marché financier

Sélectionner un service Azure pour les bases de données de série chronologique

  • Azure Data Explorer est une plateforme de stockage Big Data managée. Utilisez-la pour interroger et visualiser des volumes élevés de données en quasi-temps réel. Choisissez ce service si vous avez besoin d’une solution PaaS (Platform as a Service) autonome avec un contrôle granulaire sur la configuration du cluster, la mise en réseau et la mise à l’échelle.

  • Eventhouse dans Microsoft Fabric fait partie de l’expérience Real-Time Intelligence dans Fabric. Il utilise des bases de données KQL pour gérer les données de streaming. Choisissez ce service si vous souhaitez une expérience SaaS (Software as a Service) intégrée à l’écosystème Fabric, notamment OneLake et d’autres charges de travail Fabric.

  • Certaines bases de données transactionnelles fournissent des fonctionnalités de série chronologique limitées dans le cadre de leur ensemble de fonctionnalités plus large ou par le biais d’extensions. Par exemple, le serveur flexible Azure Database pour PostgreSQL prend en charge TimescaleDB. Sélectionnez cette option si vous devez interroger des données de série chronologique en même temps que les données transactionnelles existantes dans la base de données.

Lorsque vous choisissez un magasin de données de série chronologique, évaluez le service en fonction des besoins de votre charge de travail pour :

  • Performances d’ingestion
  • Requêtes ad hoc
  • Index supplémentaires au-delà des champs date/heure
  • Analyse et alertes de séries temporelles

Magasins de données d'objets

Stockez des objets binaires ou semi-structurés volumineux et incluez des métadonnées qui changent rarement ou restent immuables.

Forces: Mise à l’échelle pratiquement illimitée, coût hiérarchisé, durabilité, fonctionnalité de lecture parallèle

Considérations: Opérations d’objet entier, requête de métadonnées limitée, comportements de référencement éventuels

Charges de travail: Ressources multimédias, sauvegardes, zones brutes de data lake, archives de journaux

Sélectionner un service Azure pour les magasins de données d’objets

  • Data Lake Storage est un magasin d’objets optimisé pour le Big Data qui combine l’espace de noms hiérarchique et la compatibilité HDFS pour l’analytique avancée et le traitement des données à grande échelle.

  • Le Stockage Blob est un magasin d’objets évolutif pour les données non structurées telles que les images, les documents et les sauvegardes qui incluent l’accès hiérarchisé pour l’optimisation des coûts.

Utilisez le tableau suivant pour déterminer le service Azure qui répond à vos besoins en cas d’usage.

Service Idéal pour Fonctionnalités clés Exemple de cas d’usage
Data Lake Storage Analytique big data et données hiérarchiques HDFS, espace de noms hiérarchique, optimisé pour l’analytique Stockage et interrogation de pétaoctets de données structurées et non structurées à l’aide d’Azure Data Factory ou d’Azure Databricks
Stockage Blob Stockage d’objets à usage général Espace de noms plat, API REST simple et stockage hiérarchisé incluant chaud, froid et archive Hébergement d’images, de documents, de sauvegardes et de contenu de site web statique

Rechercher et indexer des magasins de données

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

Forces: Requêtes en texte intégral, scoring, analyse linguistique, correspondance approximative

Considérations: Cohérence éventuelle des index, ingestion distincte ou pipeline d’indexation, coût des mises à jour d’index volumineuses

Tâches : Recherche de site ou de produit, recherche de logs, filtrage des métadonnées, découverte à multiples attributs

Sélectionner un service Azure pour rechercher des magasins de données

Pour plus d’informations, consultez Choisir un magasin de données de recherche dans Azure.

Magasins de données de recherche vectorielle

Les magasins de données de recherche vectorielle stockent et récupèrent des représentations vectorielles haute dimension des données, souvent générées par des modèles Machine Learning.

Forces: Recherche sémantique, algorithmes ANN

Considérations: Complexité de l’indexation, surcharge de stockage, latence et précision, défis d’intégration

Charges: Recherche de documents sémantiques, moteurs de recommandation, récupération d’image et vidéo, fraude et détection d’anomalies

Sélectionner un service Azure pour les magasins de données de recherche vectorielle

Pour plus d’informations, consultez Choisir un service Azure pour la recherche vectorielle.

Magasins de données d’analyse

Les magasins de données analytiques stockent les données massives et les conservent tout au long d’un cycle de vie de pipeline d’analyse.

Forces: Calcul et stockage évolutifs, prise en charge de SQL et Spark, intégration à des outils décisionnels, série chronologique et analyse de télémétrie

Considérations: Coût et complexité de l’orchestration, latence des requêtes pour les charges de travail ad hoc, gouvernance sur plusieurs domaines de données

Charges de travail: Rapports d'entreprise, analytique de données massives, agrégation de télémétrie, tableaux de bord opérationnels, pipelines de science des données

Sélectionner un service Azure pour les magasins de données d’analytique

Pour plus d’informations, consultez Choisir un magasin de données analytique dans Azure.

Caractéristiques comparatives (modèles non relationnelles principaux)

Aspect Document Famille de colonnes Clé-valeur Graph
Normalization Dénormalisé Dénormalisé Dénormalisé Relations normalisées
Approche de schéma Schéma à la lecture Familles de colonnes définies, schéma de colonnes à la lecture Schéma à la lecture Schéma à la lecture
Cohérence (classique) Paramétrable pour chaque élément Pour chaque ligne ou famille Pour chaque clé Pour chaque sémantique de bord ou de traversée
L'étendue de l'atomicité Document Ligne ou famille, selon l’implémentation de la table Clé unique Graph transaction (varie)
Verrouillage et concurrence Optimiste (ETag) Pessimiste ou optimiste, selon l’implémentation Optimiste (clé) Optimiste (schéma)
Modèle d’accès Agrégat (entité) Agrégats larges et épars Recherche ponctuelle par clé Parcours de relation
Indexation Principal et secondaire Primaire et secondaire limité Primaire (clé) Principal et parfois secondaire
Forme de données Hiérarchique flexible Format tabulaire large épars Valeur opaque Nœuds et arêtes
Adaptation dispersée/étendue Oui/Oui Oui/Oui Oui/non Non/Non
Taille de donnée typique Petit à moyen Moyenne-grande Petit Petit
Dimension de mise à l’échelle Nombre de partitions Largeur de la famille de partitions et de colonnes Espace clé Nombre de nœuds ou de bords

Caractéristiques comparatives (modèles non relationnelles spécialisés)

Aspect Série chronologique Objet (objet blob) Recherche/indexation
Normalization Normalisée Dénormalisé Dénormalisé
Schema Schéma en lecture (balises) Valeur opaque et métadonnées Schéma en écriture (mappage d’index)
L'étendue de l'atomicité N/A (ajout) Objet Pour chaque opération de document ou d’index
Modèle d’accès Analyses de tranche de temps, agrégation de fenêtres Opérations d’objet entier Requêtes et filtres de texte
Indexation Heure et secondaire facultative Clé (chemin) uniquement Facettes inversées et facultatives
Forme de données Tabulaire (horodatage, balises, valeur) Binaire ou blob avec des métadonnées Texte tokenisé et champs structurés
Écrire un profil Ajout à haut débit Mises à jour en bloc ou peu fréquentes L'index par lot ou en continu
Lire le profil Plages agrégées Téléchargements entiers ou partiels Ensembles de résultats classés
Moteur de croissance Taux d’événements multiplié par la rétention Nombre d’objets et taille Volume de document indexé
Tolérance de cohérence Éventuellement pour les données tardives Lecture après écriture pour chaque objet Éventuellement pour les nouveaux documents

Choisir parmi les modèles (heuristiques)

Besoin Préférer
Transactions multi-entités strictes Relationnel
Forme d’agrégation évolutive, API centrées sur JSON Document
Recherches ou mise en cache de clés à faible latence extrêmes Clé-valeur
Télémétrie étendue, diffuse et intensive en écriture Famille de colonnes ou séries chronologiques
Traversée de relation profonde Graph
Analyses analytiques historiques massives Analytique ou OLAP
Grandes données binaires non structurées ou zones de lac de données Objet
Pertinence et filtrage du texte entier Recherche et indexation
Métriques d’horodatage à réception élevée avec des requêtes de fenêtre Série chronologique
Similarité rapide (sémantique ou vecteur) Recherche vectorielle

Combiner des modèles et éviter les pièges

Utilisez plusieurs modèles lorsque les scénarios suivants s’appliquent :

  • Les modèles d’accès diffèrent, tels que la recherche de points et l’analyse analytique large par rapport à la pertinence du texte intégral.
  • Le cycle de vie et la rétention diffèrent, comme des données brutes immuables par rapport à des données structurées organisées.
  • La latence et les exigences de débit sont en conflit.

Évitez la fragmentation prématurée :

  • Utilisez un service lorsqu’il répond toujours aux objectifs de performances, de mise à l’échelle et de gouvernance.
  • Centralisez la logique de classification partagée et évitez les pipelines de transformation en double entre les magasins, sauf si nécessaire.

Recherchez les antimodèles courants suivants :

  • Plusieurs microservices partagent une base de données, ce qui crée un couplage.
  • Les équipes ajoutent un autre modèle sans maturité opérationnelle, comme la supervision ou les sauvegardes.
  • Un index de recherche devient le magasin de données principal, ce qui entraîne une mauvaise utilisation.

Quand réévaluer votre choix de modèle

Signal Action possible
Augmentation du nombre de jointures ad hoc dans une base de données de documents Introduire un modèle de lecture relationnelle
Utilisation élevée du processeur sur l’index de recherche en raison d’agrégations analytiques Transférer la charge sur le moteur d'analyse
Les documents de grande taille dénormalisés génèrent une contention de mise à jour partielle Restructurer les agrégats ou fractionner
Requêtes par fenêtre temporelle lentes sur la base de données orientée colonne Adopter une base de données de série chronologique spécialisée
La latence de recherche de point augmente avec une profondeur de traversée de graphe Ajouter des vues matérialisées dérivées

Étapes suivantes

Utilisez les articles suivants pour choisir un magasin de données spécialisé :

Découvrez les architectures de référence qui utilisent les services Azure dans cet article :

  • Last updated on