Critères de sélection d’une banque de données
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
- Solutions et services de stockage cloud Azure
- Évaluer votre options de stockage
- Introduction à Azure Storage
Ressources associées
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour