Utiliser le meilleur magasin de données pour vos données

Dans le passé, de nombreuses organisations stockaient toutes leurs données dans de grandes bases de données SQL relationnelles. Les bases de données relationnelles remplissent parfaitement leur rôle pour fournir des garanties atomiques, cohérentes, isolées et durables (ACID) pour les transactions qui impliquent des données relationnelles. Mais ces bases de données présentent des coûts :

  • Les requêtes peuvent nécessiter des jointures coûteuses.
  • Vous devez normaliser les données et les restructurer pour le schéma en écriture.
  • La contention de verrouillage peut affecter les performances.

Alternatives aux bases de données relationnelles

Dans une solution de grande envergure, une seule technologie de stockage de données ne répond probablement pas à tous vos besoins. Les alternatives aux bases de données relationnelles sont les suivantes :

  • Magasins de clés/valeurs
  • Bases de données de documents
  • Bases de données de moteur de recherche
  • Bases de données de séries chronologiques
  • Bases de données de familles de colonnes
  • Bases de données de graphe

Chacune de ces alternatives a ses avantages et ses inconvénients, et sera plus ou moins adaptée en fonction du type de magasin de données. Choisissez la technologie de stockage la mieux adaptée à vos données et son mode d’utilisation.

Par exemple, vous pouvez stocker un catalogue de produits dans une base de données de documents, telle que Azure Cosmos DB, qui prend en charge un schéma flexible. Dans ce cas, chaque description de produit constitue un document autonome. Pour lancer des requêtes sur la totalité du catalogue, vous devrez peut-être indexer le catalogue et stocker l’index dans Recherche cognitive Azure. L’inventaire de produits peut être stocké dans une base de données SQL, car ces données requièrent des garanties ACID.

Recommandations

  • N’utilisez pas une base de données relationnelle pour tous les types de données. Envisagez d’adopter d’autres banques de données le cas échéant. Pour plus d’informations sur les modèles de stockage courants, consultez Comprendre les modèles de magasin de données.

  • N’oubliez pas que les données représentent bien plus que les données d’application persistantes. Elles incluent également les journaux des applications, les événements, les messages et les caches.

  • Adoptez la persistance polyglotte ou des solutions utilisant une combinaison de technologies de banque de données.

  • Considérez le type de données dont vous disposez. Par exemple :

    • Placez des données transactionnelles dans une base de données SQL.
    • Stockez des documents JSON dans une base de données de documents.
    • Utilisez une base de données de série chronologique pour la télémétrie.
    • Placez les journaux d’application dans Recherche cognitive Azure.
    • Choisissez Stockage Blob Azure pour les objets blob.
  • Préférez la disponibilité à la cohérence (forte) . Le théorème CAP implique que les systèmes distribués doivent trouver un compromis entre la disponibilité et la cohérence. Vous ne pouvez jamais éviter complètement les partitions réseau, l’autre partie du théorème CAP. Cependant, il est fréquent que vous obteniez une meilleure disponibilité en adoptant un modèle de cohérence éventuelle.

  • Prenez en compte les compétences de votre équipe de développement. Si la persistance polyglotte offre de nombreux avantages, elle peut également s’avérer très complexe. L’adoption d’une nouvelle technologie de stockage de données requiert un nouvel ensemble de compétences. Pour tirer le meilleur parti de la technologie, l’équipe de développement doit comprendre comment :

    • Optimiser les requêtes.
    • Optimiser les performances.
    • Utiliser les modèles d’utilisation appropriés.

    Tenez compte de ces facteurs lorsque vous choisissez une technologie de stockage.

  • Utilisez des transactions de compensation. Avec la persistance polyglotte, il est possible qu’une transaction unique écrive des données dans plusieurs banques de données. En cas de problème, utilisez des transactions de compensation pour annuler toutes les étapes qui ont déjà été effectuées.

  • Examinez les contextes délimités, un concept de conception pilotée par le domaine. Une limite de contexte est une limite explicite autour d’un modèle de domaine. Une limite de contexte définit les parties du domaine auxquelles s’applique le modèle. Dans l’idéal, une limite de contexte correspond à un sous-domaine du domaine d’entreprise. Les limites de contexte dans votre système représentent un facteur important dans l’adoption de la persistance polyglotte. Par exemple, les produits peuvent apparaître dans le sous-domaine Catalogue de produits et le sous-domaine Inventaire des produits. Toutefois, ces deux sous-domaines ont probablement des exigences différentes pour le stockage, la mise à jour et l’interrogation de produits.

Étapes suivantes