Choisir une base de données : relationnelle, documents, clé-valeur, colonnes, graphe et séries temporelles

Pourquoi ce choix mérite de l’attention

Une base de données est l’un des composants les plus difficiles à remplacer. Les applications sont réécrites autour de leurs données, et non l’inverse ; migrer des téraoctets de données vivantes pendant que l’activité continue peut prendre un an. Le choix du stockage est donc une porte à sens unique qui mérite une décision explicite, alors que beaucoup d’équipes le font par habitude ou par effet de mode.

Le chapitre 0 a présenté les bases de données relationnelles et les quatre familles NoSQL. Cette section va plus loin : ce que chaque famille fait vraiment bien, les catégories plus récentes (séries temporelles, recherche, vectorielle et SQL distribué), comment choisir sur la base de preuves plutôt que d’enthousiasme, et ce que coûte l’exploitation de plusieurs types à la fois. La réponse est rarement une seule base de données pour tout, et presque jamais une base différente pour chaque service.

Le relationnel : toujours le choix par défaut, pour de bonnes raisons

Une base de données relationnelle stocke les données dans des tables dotées de types, de clés et de contraintes déclarés, et répond à des requêtes SQL déclaratives, une idée issue de l’article d’Edgar Codd de 1970. Cinquante ans plus tard, elle reste le choix par défaut raisonnable pour les données métier, pour quatre raisons. D’abord, les transactions et les contraintes : la base de données garantit elle-même qu’un paiement et ses écritures au grand livre sont validés ensemble et qu’aucune commande ne pointe vers un client inexistant, si bien que ces règles n’ont pas à être réimplémentées, imparfaitement, dans chaque service. Ensuite, la flexibilité des requêtes : vous n’avez pas besoin de connaître toutes les questions futures quand vous concevez le schéma ; un nouveau rapport est une nouvelle requête, pas une nouvelle table. Troisièmement, la maturité : des décennies d’outils de sauvegarde, de réplication, de supervision, de migration et de diagnostic des performances, et des ingénieurs qui la connaissent déjà. Quatrièmement, l’étendue : les systèmes relationnels modernes stockent et indexent du JSON (le type jsonb de PostgreSQL), prennent en charge la recherche en texte intégral, les données géospatiales (PostGIS), le partitionnement temporel et la similarité vectorielle (l’extension pgvector), si bien qu’une seule base bien exploitée peut couvrir de nombreux besoins à une échelle modérée.

Les vraies limites sont précises. Les écritures sur un primaire unique sont bornées par une seule machine ; les très grandes tables exigent un partitionnement soigneux ; les modifications de schéma sur des tables énormes demandent de la technique (évolution des schémas) ; et certains schémas d’accès, comme les parcours de graphe profonds ou la recherche textuelle classée par pertinence, sont bien mieux servis par des moteurs spécialisés. Un seul serveur moderne doté de disques SSD rapides peut traiter des milliers de transactions par seconde et des téraoctets de données, ce qui couvre les besoins de la plupart des organisations.

Les familles non relationnelles

Une base de données orientée documents stocke chaque enregistrement sous forme de document autonome, généralement en JSON ou dans une forme binaire de celui-ci. Elle convient aux agrégats au sens de la conception pilotée par le domaine : des choses lues et écrites d’un bloc, comme la carte d’un restaurant avec ses rubriques, ses plats et ses groupes d’options. Lire un document, c’est une seule recherche, sans jointure. Le compromis apparaît quand les mêmes données doivent être interrogées sous une autre forme (tous les plats contenant des arachides, sur toutes les cartes) ou modifiées dans de nombreux documents à la fois ; les jointures et les transactions multidocuments existent dans les produits modernes, mais elles sont plus coûteuses et moins naturelles qu’en SQL.

Une base clé-valeur est un dictionnaire distribué : on range une valeur sous une clé, on la récupère. Comme la base ne regarde jamais à l’intérieur des valeurs, elle peut être extrêmement rapide et facile à partitionner. Redis et son fork open source Valkey conservent les données en mémoire avec une persistance optionnelle, et ajoutent des structures de données (ensembles triés, flux, index géospatiaux) et l’expiration ; Amazon DynamoDB est une base clé-valeur et documents managée et partitionnée. Elles conviennent aux sessions, aux paniers, aux compteurs de limitation de débit, aux feature flags, aux caches et à la dernière position de chaque livreur.

Une base orientée colonnes larges (wide-column store) (Bigtable, Apache Cassandra, ScyllaDB, HBase) regroupe les lignes par clé de partition et les stocke triées par une clé de clustering au sein de chaque partition. Elle est conçue pour des volumes d’écriture massifs répartis sur de nombreux nœuds et centres de données. La discipline qu’elle exige est la modélisation orientée requêtes : vous concevez une table par requête, en dupliquant librement les données, car les requêtes qui ne partent pas de la clé de partition sont coûteuses, voire impossibles. Cassandra descend en partie de l’article Dynamo d’Amazon de 2007, dont les idées de réplication apparaissent dans deux sections plus loin.

Une base de données orientée graphe stocke des nœuds et des relations comme des enregistrements à part entière, et répond à des requêtes de parcours comme les clients à trois sauts au plus de ce réseau de fraude sans les jointures en cascade qui rendent ces requêtes lentes en SQL. Cypher, de Neo4j, est le langage de requête le plus connu, et l’ISO a publié en 2024 un langage de requête de graphe normalisé, GQL (ISO/IEC 39075). Les graphes excellent pour la détection de fraude, les recommandations et l’analyse de réseaux, et font généralement un mauvais stockage principal pour les données métier transactionnelles.

Séries temporelles, recherche et bases vectorielles

Une base de données de séries temporelles est optimisée pour des mesures horodatées qui arrivent dans l’ordre et sont rarement modifiées : métriques, relevés de capteurs, prix, historique de positions. Elle compresse fortement, partitionne par période, sous-échantillonne les données anciennes (garder chaque point pendant une semaine, des moyennes par minute pendant un an) et supprime à peu de frais les données expirées en éliminant des partitions temporelles entières. Parmi les exemples figurent InfluxDB, Prometheus (pour la supervision) et TimescaleDB, qui est une extension de PostgreSQL et montre qu’une base relationnelle peut souvent s’étendre pour convenir.

Un moteur de recherche comme Elasticsearch, OpenSearch ou Apache Solr (tous construits sur la bibliothèque Apache Lucene) maintient un index inversé des mots vers les documents qui les contiennent, avec une analyse du texte (racinisation, synonymes, tolérance aux fautes de frappe) et un classement par pertinence. Il répond à ramen vegan près de chez moi en quelques millisecondes. Il ne devrait presque jamais être un système de référence : les index sont rafraîchis en quasi temps réel plutôt que de façon transactionnelle, et la conception habituelle alimente le moteur de recherche à partir de la base de données propriétaire et reconstruit l’index à partir d’elle en cas de besoin.

Une base de données vectorielle stocke des embeddings, des listes de nombres qui représentent le sens de textes, d’images ou de produits, et trouve les éléments les plus proches d’un vecteur de requête. Une recherche exacte compare la requête à chaque vecteur ; ces bases utilisent donc des index de recherche approximative des plus proches voisins, comme les graphes HNSW, qui sacrifient un peu de rappel au profit de la vitesse. Elles alimentent la recherche sémantique, les recommandations et la récupération d’informations pour les grands modèles de langage, traitée dans la génération augmentée par récupération. Des produits dédiés existent (Milvus, Qdrant, Pinecone, Weaviate), mais pour des millions plutôt que des milliards de vecteurs, une extension d’une base existante comme pgvector suffit souvent.

SQL distribué

Les bases de données SQL distribuées, parfois appelées NewSQL (un terme forgé par l’analyste Matthew Aslett en 2011), conservent le modèle relationnel, SQL et les transactions ACID, mais partitionnent et répliquent automatiquement les données sur de nombreux nœuds, souvent dans plusieurs régions. Google Spanner, décrit dans un article de l’OSDI de 2012, utilise des horloges étroitement synchronisées (son API TrueTime, adossée au GPS et à des horloges atomiques) pour offrir des transactions cohérentes à l’échelle mondiale. CockroachDB, YugabyteDB et TiDB proposent des modèles similaires sur du matériel ordinaire ; CockroachDB utilise par défaut l’isolation sérialisable.

Le prix à payer tient à la physique et à l’exploitation. Une transaction qui doit être approuvée par des répliques dans plusieurs régions attend un aller-retour de consensus : les écritures d’une seule ligne prennent donc de quelques millisecondes à des dizaines ou des centaines de millisecondes, au lieu de bien moins d’une milliseconde. La planification des requêtes entre partitions est plus subtile, les coûts sont plus élevés, et moins d’ingénieurs connaissent les modes de défaillance. Le SQL distribué est le bon outil quand vous avez réellement besoin de transactions relationnelles au-delà de la capacité d’un seul serveur ou entre régions (un grand livre mondial de paiements, une banque multirégion), et un outil coûteux quand un seul primaire PostgreSQL avec des répliques suffirait.

Choisir : les critères qui comptent

Choisissez par jeu de données, pas par système. Pour chaque jeu de données important, rassemblez des preuves sur six critères et consignez la décision dans un ADR.

Forme des données. Sont-elles naturellement tabulaires avec de nombreuses relations, un agrégat autonome, un réseau, une série temporelle, du texte libre ou des vecteurs ? Schémas d’accès. Quelles requêtes s’exécutent, à quelle fréquence, avec quels objectifs de latence, et combien sont ad hoc ? Lectures ou écritures majoritaires ? Toujours par clé, ou selon de nombreux attributs ? Besoins de cohérence. Les données exigent-elles des transactions sur plusieurs éléments et des contraintes (soldes, stocks, réservations), ou quelques secondes de retard sont-elles sans conséquence (mentions « j’aime », recommandations) ? Voir les modèles de cohérence. Échelle. Volume de données actuel et prévu, écritures par seconde et croissance, mesurés et non devinés ; une base qui s’étend jusqu’aux pétaoctets n’apporte rien pour 50 gigaoctets. Exploitation. Qui va l’exploiter : sauvegardes, mises à niveau, failover, supervision, correctifs de sécurité ? Existe-t-il un service managé dans votre cloud, et combien coûte-t-il à vos volumes ? Compétences de l’équipe. Que connaît déjà l’équipe assez bien pour déboguer à 3 heures du matin ? Une technologie mal connue comporte des modes de défaillance inconnus.

Deux habitudes améliorent le choix. Notez les cinq ou dix requêtes les plus importantes avec leurs latences cibles avant de choisir, et testez le candidat avec des volumes de données réalistes ; bien des déceptions viennent d’une base évaluée sur un ordinateur portable avec mille lignes. Et séparez le système de référence des stockages dérivés : le système de référence exige les garanties les plus fortes et la technologie la plus prudente, tandis que les stockages dérivés (index de recherche, caches, modèles de lecture) peuvent être spécialisés précisément parce qu’ils peuvent être reconstruits.

La persistance polyglotte et son coût

La persistance polyglotte consiste à utiliser des technologies de stockage différentes pour des données différentes au sein d’un même système, choisies selon l’usage qui est fait des données. Martin Fowler a popularisé le terme en 2011, en attribuant à Scott Leberknight sa première utilisation. Elle découle naturellement de la base de données par service : chaque propriétaire peut choisir le bon outil.

Le coût est facile à sous-estimer. Chaque type de base de données supplémentaire exige sa propre expertise, ses procédures de sauvegarde et de restauration, sa supervision, sa planification de la capacité, son durcissement de sécurité, son cycle de mises à niveau et ses connaissances d’astreinte. Les données circulent désormais entre les stockages : il faut donc des pipelines (CDC, événements) et raisonner sur le retard et les défaillances de chacun. La cohérence entre stockages est au mieux une cohérence à terme. Pour une petite équipe, cinq bases de données peuvent demander plus d’efforts que le produit. Une règle raisonnable consiste à justifier chaque nouveau stockage par une exigence que les stockages existants ne peuvent manifestement pas satisfaire, et à préférer des services managés pour les stockages spécialisés.

Erreurs courantes

Les choix dictés par le CV : choisir un stockage parce qu’il est nouveau ou parce qu’une grande entreprise l’utilise, sans l’exigence qui le justifiait chez elle. Choisir pour une échelle imaginaire : concevoir pour un milliard d’utilisateurs un produit qui en a mille, et payer la taxe de complexité dès le premier jour. Utiliser un stockage dérivé comme système de référence : un index de recherche ou un cache qui devient la seule copie des données, avec une durabilité plus faible que personne ne l’imaginait. Ignorer le côté requêtes : choisir une base clé-valeur ou orientée colonnes larges, puis découvrir que le métier a besoin de rapports ad hoc et de filtres qu’elle ne peut pas fournir. Sous-estimer l’exploitation : oublier que quelqu’un devra la restaurer à partir d’une sauvegarde, la mettre à niveau sans interruption de service et la diagnostiquer sous charge. Enfin, traiter le choix comme une vérité définitive : consignez les hypothèses (volumes, requêtes, compétences de l’équipe) pour que la décision puisse être réexaminée quand elles changent.