Qu’est-ce qu’une base de données distribuée ? Fonctionnement et choix

Une base de données distribuée stocke et gère des données sur plusieurs nœuds reliés par un réseau, au moyen du partitionnement, de la réplication ou des deux. Le logiciel de base de données coordonne ces nœuds pour que les applications puissent interroger et modifier les données depuis une interface commune.

La distribution change l’emplacement des enregistrements et la façon dont les opérations les atteignent. Elle impose aussi des choix sur les lectures périmées, les nœuds en panne et les transactions qui traversent plusieurs machines. Ce guide explique ces choix à partir de dossiers clients, puis présente les modèles de bases et les situations qui justifient une architecture distribuée.

Qu’est-ce qu’une base de données distribuée ?

Une base distribuée gère des données liées sur plusieurs ordinateurs au sein d’un système logique de base de données ou d’une architecture de bases coordonnée. Ces ordinateurs, souvent appelés nœuds, peuvent se trouver dans un même centre de données ou dans plusieurs régions. La distance géographique est facultative ; c’est la coordination des opérations de base de données qui définit le système.

Un système de gestion de base de données distribuée, ou SGBD distribué, assure notamment la localisation des enregistrements, la planification des requêtes, la coordination des mises à jour et la reprise après panne. Les applications désignent généralement des enregistrements logiques plutôt que des machines précises. L’interface et les garanties varient selon le système : un point d’accès commun ne signifie pas que toutes les opérations offrent la même cohérence ou les mêmes possibilités de transaction.

Un service peut, par exemple, placer les dossiers de différents clients sur des nœuds distincts et conserver plusieurs copies de chaque portion. Une demande concernant le client 1042 doit atteindre les bonnes données sans que l’application inscrive en dur l’adresse d’un serveur. Si leur affectation change, les informations de routage doivent suivre.

Base de données distribuée et stockage distribué

Le stockage distribué répartit des fichiers, des objets ou des blocs entre des équipements. Une base distribuée ajoute un modèle de données et des opérations sur les enregistrements : requêtes, index, lectures et écritures coordonnées, ainsi que des transactions lorsqu’elles sont prises en charge. Une base peut s’appuyer sur du stockage distribué, mais le service de stockage ne fournit pas à lui seul tout le système de base de données.

Un stockage objet peut offrir ses propres garanties de cohérence forte sans devenir une base relationnelle ou documentaire. À l’inverse, une base peut conserver de gros objets sans être un système de fichiers généraliste. Comparez les opérations nécessaires à l’application plutôt que de classer un système uniquement selon l’emplacement de ses octets.

Base distribuée et système distribué

Une base distribuée constitue un type de système distribué. Les services de messagerie, les clusters de calcul et les systèmes de fichiers distribués coordonnent eux aussi des composants en réseau. La conception d’une base se concentre sur les enregistrements, l’exécution des requêtes, les modifications concurrentes et les garanties obtenues lors d’une lecture ou d’un changement de données.

Comment fonctionne une base de données distribuée ?

Prenons une application qui conserve des profils clients et des commandes. La base divise les enregistrements en partitions selon un identifiant client et réplique chaque partition. Une opération suit généralement les étapes suivantes, même si les composants responsables varient :

1. Recevoir la demande. L’application se connecte par un pilote, un point d’accès ou un routeur, avec une requête ou une mise à jour.
2. Localiser les données pertinentes. Les métadonnées de routage indiquent quelles partitions peuvent contenir les enregistrements demandés et quels nœuds les servent actuellement.
3. Exécuter sur les bons nœuds. Une recherche ciblée peut atteindre une seule partition ; une requête plus large peut en mobiliser plusieurs et combiner leurs résultats.
4. Coordonner l’opération. Les lectures respectent les règles de cohérence choisies. Les écritures peuvent nécessiter des confirmations de réplication, des contrôles de concurrence et une décision de validation de transaction.
5. Renvoyer un résultat. La base répond lorsque les conditions de réussite de l’opération sont réunies, ou signale un échec que l’application doit traiter.

Il n’existe pas nécessairement un coordinateur central unique pour toute la base. Le routage peut faire intervenir plusieurs services sans état, des pilotes clients ou des nœuds qui coordonnent certaines demandes. Les services de métadonnées et de coordination ont eux aussi besoin de mécanismes de reprise : répartir les enregistrements ne supprime pas toutes les dépendances communes.

Une recherche sur le client 1042 peut coûter peu lorsque la clé de partition permet de localiser ses enregistrements. Un rapport couvrant tous les clients peut contacter de nombreuses partitions et déplacer des résultats intermédiaires sur le réseau. Dans MongoDB, par exemple, mongos dirige les requêtes vers les fragments concernés et combine les résultats ; la requête et la répartition des données déterminent s’il peut cibler un sous-ensemble ou doit diffuser plus largement.

L’application doit aussi interpréter les échecs avec précision. Un délai dépassé ne prouve pas qu’une écriture a échoué avant sa validation. La réponse peut s’être perdue après l’acceptation de l’écriture. Utilisez les mécanismes de nouvelle tentative documentés par la base et, si nécessaire, des identifiants d’opération pour éviter de répéter une action métier.

Partitionnement et sharding : diviser les données

Le partitionnement divise un jeu de données en portions. Il peut exister à l’intérieur d’un seul serveur. Le sharding désigne généralement un partitionnement horizontal entre nœuds : différents groupes d’enregistrements résident sur des machines distinctes. La réplication peut ensuite protéger chaque fragment séparément.

La clé de partition influence le placement des données, le routage des requêtes et la répartition de la charge. Les approches courantes comprennent :

• Le partitionnement par hachage : le résultat d’une fonction de hachage appliquée à la clé détermine le placement. Cela peut répartir de nombreuses clés distinctes, mais une seule clé très sollicitée peut toujours créer un point chaud.
• Le partitionnement par plages : les valeurs de clé voisines restent ensemble. Cette méthode peut faciliter les requêtes par intervalle, tandis qu’une suite de valeurs croissantes peut concentrer les nouvelles écritures à une extrémité si la conception ne traite pas ce cas.
• Le placement par organisation cliente ou zone géographique : les enregistrements sont regroupés selon une organisation ou un lieu. Les opérations liées peuvent ainsi rester proches, mais un gros client ou une demande régionale déséquilibrée peut dominer une partition.

Supposons que la plupart des opérations lisent le profil d’un client et ses commandes récentes. Regrouper ces enregistrements par client peut réduire le travail entre partitions. Si la requête la plus coûteuse classe au contraire toutes les commandes par date de livraison, cette disposition peut nécessiter une lecture étendue ou un autre index. Choisissez une clé selon les accès réels : un nombre égal d’enregistrements ne produit pas forcément une charge égale.

La croissance exige aussi de prévoir les déplacements. Diviser des partitions, ajouter des nœuds et rééquilibrer les données consomme de la bande passante de stockage, de la capacité réseau et du temps de calcul. La base doit maintenir un routage correct pendant les changements d’affectation. Mesurez son comportement durant ces transitions, surtout si un cluster déjà chargé dispose de peu de marge.

Réplication : conserver des copies des données

La réplication maintient des copies sur plusieurs nœuds. Le partitionnement détermine où va chaque portion du jeu de données ; la réplication définit les copies de cette portion et leur emplacement. Une base peut distribuer un jeu complet par réplication sans le fragmenter, ou combiner les deux techniques.

Les copies peuvent faciliter la reprise, augmenter la capacité de lecture ou rapprocher certains accès des utilisateurs. Le résultat dépend de la politique de réplication. Il faut notamment savoir quels nœuds acceptent les écritures, combien de confirmations sont nécessaires, quels réplicas servent les lectures et comment les mises à jour atteignent les copies qui étaient indisponibles.

Certains systèmes utilisent un leader pour chaque partition répliquée. D’autres acceptent des demandes par plusieurs nœuds, avec des règles de coordination et de résolution des conflits. Ces protocoles ont des comportements de panne précis ; le nombre de copies ne suffit pas à établir leurs garanties.

La documentation de réplication de Spanner distingue, par exemple, les réplicas en lecture-écriture, en lecture seule et les témoins. Un témoin peut voter sans conserver une copie complète lisible. Compter les « réplicas » ne suffit donc pas à connaître la capacité de lecture ou de reprise.

Le placement compte autant que le nombre. Plusieurs réplicas sur un hôte partagent le risque de panne de cet hôte ; une répartition entre zones exige encore une organisation des quorums qui supporte la perte de zone prévue. La séparation géographique peut aider face à certaines pannes tout en allongeant les échanges nécessaires aux écritures coordonnées.

La réplication ne remplace pas une sauvegarde. Une suppression accidentelle ou une mise à jour dommageable peut se propager aux autres réplicas. Conservez des sauvegardes restaurables, définissez un point de reprise acceptable et testez la restauration indépendamment du basculement habituel entre réplicas.

Cohérence : que peut observer une lecture ?

Un modèle de cohérence décrit les relations entre opérations et les valeurs qu’une lecture peut renvoyer. Choisissez-le selon les conditions nécessaires au bon fonctionnement de l’application. Une photo de profil actualisée avec retard et une décision sur le paiement d’une commande ne tolèrent pas forcément le même comportement.

Linéarisabilité et ordre en temps réel

Pour un enregistrement, les opérations linéarisables se comportent comme si elles s’exécutaient sur une copie unique, dans un ordre compatible avec le temps réel. Si une modification se termine avant le début d’une lecture, cette lecture ne peut pas renvoyer une valeur antérieure à la modification ; une mise à jour ultérieure ou concurrente peut toutefois déterminer la valeur renvoyée.

Cette garantie peut demander des échanges ou empêcher un nœud de servir une opération lorsqu’il ne peut pas établir un résultat sûr. L’expression « cohérence forte » est parfois employée plus largement. Vérifiez la garantie documentée et son périmètre : un enregistrement, une transaction ou un mode de lecture particulier.

Cohérence éventuelle et garanties de session

Avec la cohérence éventuelle, les réplicas peuvent présenter temporairement des versions différentes. Si les mises à jour cessent et que les conditions de livraison et de réparation du système sont réunies, ils convergent. Ce terme ne promet à lui seul ni délai maximal, ni conservation de chaque modification en conflit, ni visibilité immédiate de sa propre écriture pour un utilisateur.

L’application peut parfois choisir des garanties de session plus fortes, comme la relecture de ses propres modifications, sans imposer le même ordre à tous les utilisateurs. Une lecture sur instantané fournit une vue à un moment donné ; elle ne promet pas automatiquement d’afficher la dernière mise à jour terminée.

La documentation d’architecture de Cassandra décrit des niveaux de cohérence configurables en lecture et en écriture. Exiger des quorums de lecture et d’écriture qui se recoupent peut être utile, mais ce recoupement ne suffit pas à établir toutes les garanties d’ordre ou de transaction. Les écritures concurrentes, le traitement des conflits et le protocole restent déterminants.

Ce que CAP dit des partitions réseau

Le résultat CAP établit que, durant une partition réseau, un système ne peut garantir à la fois des lectures et écritures linéarisables et la réussite de chaque demande adressée à un nœud non défaillant. Une réponse d’erreur ne satisfait pas cette définition de la disponibilité. Un nœud isolé peut devoir suspendre une opération pour préserver sa garantie de cohérence. CAP décrit cette situation de panne ; il ne permet pas de choisir librement « deux propriétés sur trois ».

Transactions sur des données distribuées

Une transaction regroupe des opérations selon des règles de validation et d’isolation définies. Les bases distribuées peuvent prendre en charge des transactions ACID : atomicité, cohérence, isolation et durabilité. La cohérence d’ACID concerne la préservation des règles et invariants de la base ; le mot possède ici un sens différent de la cohérence entre réplicas.

L’atomicité signifie que la transaction est validée comme un tout ou ne l’est pas. L’isolation régit les interactions entre transactions concurrentes. La durabilité décrit les événements auxquels un résultat validé résiste selon les garanties du système. Le mot « transaction » ne promet pas le niveau d’isolation le plus fort, et les règles métier exigent toujours des contraintes ou une logique transactionnelle correctes.

Une transaction limitée à une partition évite généralement la coordination entre partitions distinctes. Elle peut toutefois coordonner les réplicas de cette partition. Une transaction qui en traverse plusieurs doit permettre à ses participants d’aboutir à une décision compatible de validation ou d’annulation, ce qui ajoute des échanges et du travail de reprise.

Le consensus de réplication et la validation d’une transaction répondent à des problèmes liés mais distincts. Un groupe répliqué doit s’accorder sur son état ; une transaction atomique entre groupes doit établir une décision commune entre participants. Le parcours des lectures et écritures de Spanner illustre les deux : la réplication intervient dans chaque partition, appelée « split », et les écritures entre splits ajoutent une validation en deux phases.

Pour l’application, il faut déterminer quels enregistrements doivent changer ensemble. Regrouper les opérations liées dans une partition peut réduire la coordination, mais y concentrer toute l’activité peut créer un goulot d’étranglement. Mesurez la transaction courante et la plus difficile, y compris les conflits d’accès et les nouvelles tentatives.

Types de bases distribuées, avec des exemples

Relationnel et NoSQL décrivent des modèles de données

Relationnel et distribué décrivent deux dimensions différentes. Une base relationnelle distribuée peut offrir des tables, SQL, des relations, des contraintes et des transactions tout en gérant les données sur plusieurs nœuds. Les fonctions et opérations prises en charge dépendent du produit.

NoSQL recouvre plusieurs modèles, notamment les documents, les enregistrements clé-valeur et les colonnes larges. Ce terme ne signifie pas que toutes les bases ont une cohérence éventuelle ou sont dépourvues de transactions. De même, une interface SQL ne détermine pas la fraîcheur de chaque lecture et ne garantit pas qu’une charge conçue pour un seul serveur passera à l’échelle sans adaptation.

Trois exemples documentés illustrent des choix différents :

• Apache Cassandra : une base distribuée, partitionnée et répliquée, avec un modèle à colonnes larges et CQL. Sa présentation de l’architecture place les clés de partition au centre de l’organisation et de l’accès aux données.
• MongoDB dans un déploiement partitionné : répartit les documents entre fragments. Son architecture de sharding utilise des ensembles de réplicas pour les fragments, des routeurs pour les demandes et des serveurs de configuration pour les métadonnées du cluster.
• Google Spanner : propose des données relationnelles distribuées et des transactions ACID. Sa documentation des transactions distingue l’isolation sérialisable et la lecture répétable ; le mode choisi compte dans l’évaluation des garanties.

Ces exemples présentent des architectures, sans classer les fournisseurs. Évaluez un système selon les requêtes, les limites des transactions, la tolérance aux pannes, les possibilités de déploiement et le travail d’exploitation nécessaires à votre application.

Bases homogènes, hétérogènes et fédérées

La terminologie classique des SGBD distingue les systèmes homogènes, dont les participants utilisent la même technologie ou le même modèle de base, des environnements hétérogènes qui coordonnent des technologies ou modèles différents. Employer un même SGBD n’exige pas que chaque partition contienne les mêmes enregistrements ou que chaque application utilise un schéma identique.

La fédération met l’accent sur un accès combiné à des bases qui conservent une certaine autonomie. Elle peut réunir plusieurs sources sans les remplacer par un seul jeu de données administré centralement. Des microservices possédant des bases séparées ne forment pas automatiquement une base fédérée : une couche commune de requête ou de coordination doit réellement fournir cet accès combiné.

Notre guide des systèmes d’information distribués explique le problème d’intégration plus large, notamment la responsabilité des sources, les vues communes et les écarts de fraîcheur entre applications.

Architectures de bases distribuées : placement et coordination

Partitionné et répliqué décrivent le placement des données. Avec ou sans leader décrit certains aspects de la coordination. Une architecture « shared-nothing » signifie généralement que les nœuds possèdent leurs propres ressources de mémoire et de stockage ; une architecture à stockage partagé permet aux nœuds de calcul de la base d’accéder à une couche de stockage commune. Ces termes répondent à des questions différentes et peuvent coexister.

Une interface client-serveur est compatible avec une base distribuée. L’application peut voir une seule adresse de service alors que de nombreuses machines fonctionnent derrière. Pour comprendre l’architecture, suivez une lecture, une écriture et une opération de reprise concrètes plutôt que de vous fier à une étiquette.

Avantages et limites des bases distribuées

La mise à l’échelle horizontale ajoute des nœuds pour augmenter la capacité de stockage ou de traitement. Le placement des données peut rapprocher certaines opérations des utilisateurs. La tolérance aux pannes permet de maintenir le service pendant des défaillances de composants définies. Ces avantages possibles exigent un partitionnement, une réplication et une coordination adaptés, ainsi qu’une capacité de réserve ; ajouter des machines ne suffit pas.

Les compromis sont concrets. Les requêtes entre partitions déplacent des données. La réplication synchrone ajoute des échanges aux écritures. Le rééquilibrage concurrence le trafic normal. Davantage de composants créent davantage de pannes partielles et de frontières d’accès à gérer. Un cluster plus grand peut rester limité par une clé très sollicitée, un service commun ou une charge qui exige de fréquentes coordinations globales.

La sécurité demande aussi une conception explicite. Authentifiez les clients et les nœuds, limitez les permissions de service, protégez les connexions et les données stockées, et déterminez où peuvent aller les enregistrements, les sauvegardes et les journaux de diagnostic. La répartition géographique ne garantit à elle seule ni la sécurité ni la conformité.

Choisir une base distribuée ou centralisée

Partez d’un besoin mesuré : données ou trafic dépassant la capacité pratique d’un serveur, tolérance aux pannes convenue ou contrainte de placement précise. Vérifiez les index, les plans de requête, la gestion des connexions et les limites de ressources avant d’attribuer chaque ralentissement à un besoin de sharding.

Une base bien gérée sur un serveur peut être plus simple à exploiter si sa capacité et sa reprise répondent au besoin. Ajouter un serveur principal et des réplicas peut traiter certains besoins de lecture ou de reprise sans partitionnement entre serveurs ; c’est déjà une forme de distribution, avec ses choix de cohérence et de basculement.

Avant de choisir une architecture, documentez :

• La charge : requêtes fréquentes, volume d’écriture, croissance, clés très sollicitées et transactions entre clients ou régions.
• Les garanties : ancienneté acceptable des lectures, isolation nécessaire, durabilité des écritures confirmées et comportement lors d’une séparation du réseau.
• Les objectifs de reprise : pertes d’hôte, de zone ou de région à tolérer, délai de rétablissement du service et perte de données acceptable.
• Le coût d’exploitation : réplicas, stockage, transferts réseau, sauvegardes, supervision et personnes chargées de maintenir ou de surveiller le service.

Testez une charge réaliste pendant la panne d’un nœud, le rattrapage d’un réplica et un rééquilibrage. Mesurez les percentiles de latence élevés, comme p95 et p99, ainsi que le débit, les erreurs, le retard de réplication et le temps de reprise. Restaurez séparément une sauvegarde et vérifiez les enregistrements récupérés. Notre guide de gestion des systèmes distribués présente les pratiques d’exploitation plus larges.

Choisissez la distribution lorsque ses avantages de placement, de capacité ou de reprise résolvent un problème précis. Une architecture utile possède des garanties et un comportement de panne que l’équipe sait expliquer et tester.

Questions fréquentes

Toutes les bases distribuées utilisent-elles le sharding ?

Non. Une base peut répliquer l’intégralité de ses données sur plusieurs nœuds sans les diviser en fragments. De nombreux systèmes combinent partitionnement et réplication, chaque partition étant conservée par plusieurs réplicas.

Une base distribuée peut-elle prendre en charge ACID ?

Oui. Vérifiez quelles opérations peuvent partager une transaction, son niveau d’isolation et son comportement entre partitions. La prise en charge d’ACID ne supprime pas les coûts de coordination ni la nécessité de gérer correctement les nouvelles tentatives.

Distribué signifie-t-il multirégional ?

Non. Une base peut fonctionner sur plusieurs machines en réseau au même endroit. Un déploiement multirégional est un choix de placement qui ajoute des considérations de latence, de panne et de gouvernance des données.

Une base distribuée garantit-elle une disponibilité permanente ?

Non. La disponibilité dépend des pannes tolérées, des participants encore joignables, de la capacité disponible et des mécanismes de reprise. Un changement de leader, la perte d’un quorum, un défaut logiciel ou une dépendance surchargée peut toujours interrompre des opérations.