Partager via

Critères de sélection d’une banque de données

  • Article

Cet article décrit les critères de comparaison à employer pour évaluer un magasin de données. L’objectif ici est de vous aider à identifier les types de stockage de données qui vous permettront de répondre aux besoins de votre solution.

Considérations d’ordre général

Gardez à l’esprit les considérations suivantes lorsque vous faites votre choix.

Spécifications fonctionnelles

  • Format de données : Quel type de données avez-vous l’intention de stocker ? Les données transactionnelles, les objets JSON, les données de télémétrie, les index de recherche et les fichiers plats comptent parmi les types courants.
  • Taille des données : Quelle est la taille des entités que vous avez besoin de stocker ? Ces entités devront-elles être conservées sous la forme d’un document unique ou pourront-elles être scindées en plusieurs documents, tables et collections ?
  • Échelle et structure : De quelle capacité de stockage avez-vous besoin au total ? Prévoyez-vous de partitionner vos données ?
  • Relations des données : Vos données devront-elles prendre en charge des relations un-à-plusieurs ou plusieurs à plusieurs ? Les relations proprement dites constituent-elles une part importante des données ? Prévoyez-vous de joindre ou de combiner les données d’un même jeu de données ou de plusieurs jeux de données externes ?
  • Modèle de cohérence : Quelle importance accordez-vous à ce que les mises à jour effectuées dans un nœud apparaissent dans les autres nœuds, avant que d’autres modifications puissent avoir lieu ? Pouvez-vous accepter la cohérence éventuelle ? Avez-vous besoin de garanties ACID pour les transactions ?
  • Flexibilité en matière de schéma : Quel type de schéma appliquerez-vous à vos données ? Allez-vous utiliser un schéma fixe, une approche de schéma à l’écriture ou une approche de schéma à la lecture ?
  • Concurrence : Quel type de mécanisme de concurrence souhaitez-vous utiliser au moment de mettre à jour et de synchroniser les données ? L’application sera-t-elle appelée à procéder à de nombreuses mises à jour qui pourraient potentiellement entrer en conflit ? Dans ce cas, vous aurez peut-être besoin du verrouillage des enregistrements et du contrôle de concurrence pessimiste. Sinon, pouvez vous prendre en charge les contrôles d’accès concurrentiel optimiste ? Dans ce cas, un simple contrôle de concurrence basé sur l’horodatage suffira-t-il ou aurez-vous besoin de la fonctionnalité supplémentaire de contrôle de concurrence multiversion ?
  • Déplacement des données : Votre solution devra-t-elle effectuer des tâches ETL pour déplacer les données vers d’autres magasins ou entrepôts de données ?
  • Cycle de vie des données : Les données sont-elles écrites une fois et lues autant de fois que souhaité ? Peuvent-elles être déplacées dans un espace de stockage froid ?
  • Autres fonctionnalités prises en charge : Avez-vous besoin d’autres fonctionnalités spécifiques, telles que la validation de schéma, l’agrégation, l’indexation, la recherche en texte intégral, MapReduce ou d’autres capacités de requête ?

Exigences non fonctionnelles

  • Niveau de performance et scalabilité : Quels sont vos besoins en matière de performance des données ? Avez-vous des exigences spécifiques concernant la vitesse d’ingestion des données et la vitesse de traitement des données ? Quels sont les temps de réponse acceptables pour l’interrogation et l’agrégation des données une fois celles-ci ingérées ? De quelle taille aurez-vous besoin pour augmenter les capacités de la banque de données ? Votre charge de travail est-elle plutôt axée sur la lecture ou sur l’écriture ?
  • Fiabilité : Quel contrat de niveau de service global devez-vous prendre en charge ? Quel niveau de tolérance aux pannes devez-vous offrir aux consommateurs de données ? De quelles fonctionnalités de sauvegarde et de restauration avez-vous besoin ?
  • Réplication : Vos données devront-elles être réparties entre plusieurs réplicas ou régions ? De quel type de fonctionnalités de réplication de données avez-vous besoin ?
  • Limites : Les limites d’un magasin de données en particulier répondent-elles à vos besoins en matière d’échelle, de nombre de connexions et de débit ?

Gestion et coût

  • Service géré : Si possible, utilisez un service de données géré, sauf si vous avez besoin de fonctionnalités spécifiques que seul un magasin de données hébergé par IaaS (infrastructure as a service) peut offrir.
  • Disponibilité des régions : Pour les services gérés, le service est-il disponible dans toutes les régions Azure ? Votre solution doit-elle être hébergée dans certaines régions Azure ?
  • Portabilité : Vos données devront-elles migrer vers un environnement local, vers des centres de données externes ou vers d'autres environnements d'hébergement cloud ?
  • Licence : Avez-vous une préférence quant au type de licence : propriétaire ou OSS ? Existe-t-il d’autres restrictions externes quant au type de licence que vous pouvez utiliser ?
  • Coût global : Quel est le coût global d’utilisation du service dans votre solution ? Combien d’instances devront s’exécuter pour répondre à vos besoins en matière de durée de fonctionnement et de débit ? Prenez en compte les coûts d’exploitation dans ce calcul. L’un des raisons de préférer les services managés est leur coût d’exploitation réduit.
  • Rentabilité : Pouvez-vous partitionner vos données de façon à profiter d’un stockage plus économique ? Par exemple, pouvez-vous transférer les objets volumineux d’une base de données relationnelle coûteuse vers une banque d’objets ?

Sécurité

  • Sécurité : De quel type de chiffrement avez-vous besoin ? Avez-vous besoin d’un chiffrement au repos ? Quel mécanisme d’authentification voulez-vous utiliser pour vous connecter à vos données ?
  • Audit : Quel type de journal d’audit avez-vous besoin de générer ?
  • Exigences réseau : Devez-vous limiter ou gérer l’accès à vos données à partir d’autres ressources réseau ? Les données ne doivent-elle être accessibles qu’à l’intérieur de l’environnement Azure ? Les données doivent-elle être accessibles à partir d’adresses IP ou de sous-réseaux spécifiques ? Doivent-elles être accessibles à partir d’applications ou de services hébergés localement ou dans d’autres centres de données externes ?

DevOps

  • Compétences : Votre équipe est-elle encline à utiliser certains langages de programmation, systèmes d’exploitation et autres technologies plutôt que d’autres ? Votre équipe aurait des difficultés à en utiliser d’autres ?
  • Clients : Existe-t-il un bon support client pour vos langages de développement ?

Étapes suivantes