Bases de données relationnelles ou NoSQL : comment choisir la base la mieux adaptée à votre système

Toutes les bases de données stockent des données. Mais c'est là que s'arrêtent les similitudes. Les bases de données relationnelles et les bases de données NoSQL reposent sur des philosophies fondamentalement différentes quant à la manière dont les données doivent être structurées, stockées et interrogées — et ces différences se répercutent à tous les niveaux des systèmes construits à partir de celles-ci.

Il ne s’agit pas ici d’opposer l’ancien au nouveau, ni le simple au sophistiqué. Ces deux catégories comprennent des systèmes aboutis, éprouvés sur le terrain et utilisés à une échelle extraordinaire. La question porte sur l’adéquation à l’usage : quel modèle correspond le mieux à la structure de vos données, aux modèles d’accès de votre application et aux garanties de cohérence exigées par vos utilisateurs ?

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

Une base de données relationnelle organise les données en tables — des lignes et des colonnes entre lesquelles existent des relations explicitement définies. Le terme « relationnelle » dans son nom ne fait pas référence au fait que les tables sont liées les unes aux autres (bien qu’elles le soient), mais au concept mathématique de relation : un ensemble de tuples partageant les mêmes attributs. Ce fondement théorique, développé par Edgar Codd chez IBM en 1970, s’est révélé remarquablement pérenne.

Les caractéristiques essentielles d’une base de données relationnelle sont les suivantes :

Un schéma fixe. Avant d’insérer des données, vous définissez la structure : quelles tables existent, quelles colonnes comporte chaque table, quel type de données chaque colonne accepte, et quelles contraintes s’appliquent (NOT NULL, UNIQUE, CHECK, etc.). Le schéma est le contrat entre votre application et votre base de données.

La normalisation. Les données sont organisées de manière à éliminer toute redondance. Le nom d’un client n’apparaît qu’une seule fois, dans la table des clients. Chaque commande fait référence à ce client par son identifiant. Si le nom change, il ne change qu’à un seul endroit. Il ne s’agit pas seulement d’une question d’ordre : c’est une garantie de cohérence.

Transactions ACID. Atomicité, cohérence, isolation et durabilité. Une transaction est soit entièrement validée, soit pas du tout. Si vous transférez de l’argent d’un compte à un autre, le débit et le crédit s’effectuent simultanément ou ne s’effectuent pas du tout. La base de données impose cette règle au niveau du moteur.

SQL. Le langage SQL (Structured Query Language) est l’interface universelle des bases de données relationnelles. Il est déclaratif — vous décrivez ce que vous voulez, et non comment l’obtenir — et il est extrêmement expressif. Jointures, agrégations, fonctions de fenêtre, sous-requêtes, CTE : toute la richesse du SQL vous offre les outils nécessaires pour poser des questions complexes sur vos données sans avoir à écrire de code d’application pour effectuer ce travail.

Les principales bases de données relationnelles — PostgreSQL, MySQL, SQL Server, Oracle — partagent ces propriétés tout en se distinguant par leurs ensembles de fonctionnalités spécifiques, leurs caractéristiques de performance et leurs modèles de licence. PostgreSQL, en particulier, est devenu le choix par défaut pour les nouveaux projets, alliant une conformité stricte aux normes à un ensemble de fonctionnalités exceptionnel.

Qu’est-ce qu’une base de données NoSQL, au juste ?

« NoSQL » est un terme fourre-tout qui recouvre plusieurs catégories distinctes de bases de données, unies principalement par ce qu’elles ne sont pas : elles ne sont pas relationnelles et n’utilisent pas SQL comme interface principale (bien que certaines prennent en charge des langages de requête de type SQL). Il vaut mieux comprendre ce terme comme signifiant « pas seulement SQL » — une reconnaissance du fait que le modèle relationnel n’est pas la seule approche valable.

Les principales catégories de bases de données NoSQL sont les suivantes :

Les bases de données documentaires stockent les données sous forme de documents — généralement au format JSON ou BSON —, chaque document pouvant présenter une structure différente. MongoDB est la plus répandue ; parmi les autres, on peut citer CouchDB et Firestore. Il n’y a ni tables ni schéma fixe ; une « collection » de documents peut contenir des enregistrements comportant des champs totalement différents.

Les bases de données clé-valeur constituent le modèle le plus simple : chaque enregistrement est une valeur accessible via une clé unique. Redis en est l’exemple phare, largement utilisé pour la mise en cache, le stockage de sessions et les classements en temps réel. DynamoDB fonctionne également principalement comme une base de données clé-valeur, avec des fonctionnalités de gestion de documents superposées.

Les bases de données par familles de colonnes organisent les données par colonne plutôt que par ligne, ce qui permet des lectures extrêmement efficaces de colonnes spécifiques parmi des millions de lignes. Apache Cassandra et HBase en sont les principaux exemples. Ce modèle est conçu pour les charges de travail à forte intensité d’écriture et à haut volume, où les schémas de requêtes sont connus à l’avance.

Les bases de données orientées graphe modélisent les données sous forme de nœuds et d’arêtes — des entités et les relations entre elles. Neo4j en est l’exemple phare. Lorsque les relations entre les entités constituent l’objet principal de vos requêtes — réseaux sociaux, moteurs de recommandation, détection de fraudes —, les bases de données orientées graphe peuvent exprimer ces requêtes naturellement, là où un langage SQL profondément récursif serait nécessaire.

Les bases de données de séries chronologiques sont optimisées pour les données indexées par l’heure : InfluxDB, TimescaleDB, Prometheus. Relevés de capteurs, cotations financières, métriques d’applications — des données pour lesquelles l’horodatage est toujours la clé primaire et où les requêtes par plage temporelle constituent le modèle d’accès dominant.

La différence structurelle qui détermine tout le reste

La différence la plus fondamentale entre les bases de données relationnelles et NoSQL ne réside pas dans la syntaxe ni dans l’échelle, mais dans la relation entre la structure des données et la flexibilité des requêtes.

Les bases de données relationnelles vous offrent une flexibilité maximale en matière de requêtes en échange d’une discipline de schéma imposée dès le départ. Les données étant normalisées et typées, vous pouvez leur poser pratiquement n’importe quelle question au moment de la requête. Vous pouvez joindre des tables d’une manière que vous n’aviez pas anticipée lors de la conception du schéma. Vous pouvez effectuer des agrégations sur des dimensions que vous avez ajoutées plusieurs mois après la conception initiale. Le schéma impose des contraintes aux données, mais le langage de requête vous offre une grande liberté.

Les bases de données NoSQL font le compromis inverse. Elles vous offrent une flexibilité dans la manière de structurer et d’écrire les données, en échange de modèles de requêtes plus contraignants. Une base de données documentaire vous permet de stocker des données de n’importe quelle forme sans migration. Mais pour interroger efficacement l’ensemble des documents, il faut connaître à l’avance vos modèles d’accès et concevoir votre structure de données en fonction de ceux-ci.

C’est là le dilemme fondamental : flexibilité du schéma contre flexibilité des requêtes. Vous pouvez avoir les deux, mais seulement dans une certaine mesure. Le modèle de base de données que vous choisissez reflète le compromis le plus acceptable pour votre cas d’utilisation.

Le théorème CAP et son importance

Les systèmes distribués ne peuvent pas garantir simultanément la cohérence, la disponibilité et la tolérance aux partitions — ils peuvent au maximum en assurer deux sur les trois. C’est le théorème CAP, qui constitue le fondement théorique permettant de comprendre pourquoi les bases de données relationnelles et NoSQL se comportent différemment en cas de défaillance.

Les bases de données relationnelles privilégient traditionnellement la cohérence et la tolérance aux partitions. Chaque lecture reflète l’écriture la plus récente. Si une partition du réseau se produit et que la base de données ne peut garantir la cohérence, elle refusera de fournir des données obsolètes — elle deviendra indisponible plutôt qu’incorrecte.

De nombreuses bases de données NoSQL — en particulier celles conçues pour la distribution horizontale, comme Cassandra et DynamoDB — privilégient la disponibilité et la tolérance aux partitions. Elles fournissent des données même en cas de partition du réseau, en acceptant que certaines lectures puissent renvoyer des valeurs obsolètes. C’est ce qu’on appelle la « cohérence éventuelle » : tous les nœuds finiront par converger vers la même valeur, mais il existe une période pendant laquelle ils peuvent ne pas être d’accord.

Implication pratique : si votre application ne peut en aucun cas tolérer la lecture de données obsolètes — un solde bancaire, un état des stocks, un dossier médical —, vous avez besoin d’une cohérence forte. Si votre application peut tolérer une brève incohérence en échange d’une disponibilité permanente — un fil d’actualité sur les réseaux sociaux, un catalogue de produits, un profil utilisateur —, la cohérence éventuelle est acceptable et vous offre une grande liberté architecturale.

Exemples concrets : quand le bon choix a fait la différence

GitHub : PostgreSQL au cœur d’une plateforme mondiale

GitHub exploite l’une des plus grandes plateformes de collaboration logicielle au monde sur PostgreSQL : des millions de dépôts, des milliards d’événements, des requêtes relationnelles complexes portant sur les utilisateurs, les organisations, les dépôts, les pull requests, les tickets et les commentaires. Le modèle relationnel est parfaitement adapté à ce domaine : les relations entre ces entités constituent le produit. Une pull request appartient à un dépôt, est créée par un utilisateur, révisée par d’autres utilisateurs, clôture des tickets et déclenche des pipelines d’intégration continue (CI).

Pendant des années, GitHub a exploité une seule instance PostgreSQL principale avec des répliques en lecture. À mesure que l’échelle augmentait, l’entreprise a introduit Vitess (une couche de partitionnement MySQL pour certaines charges de travail) et ProxySQL pour la gestion des connexions — mais le cœur relationnel est resté. La leçon à en tirer n’est pas que PostgreSQL s’adapte à l’infini sans effort. C’est que le modèle relationnel était parfaitement adapté à un domaine défini par des relations, et que l’effort investi dans sa mise à l’échelle en valait la peine précisément parce que la migration vers un autre modèle de données aurait été plus coûteuse.

Twitter : la migration douloureuse de MySQL vers une architecture mixte

Twitter a démarré avec MySQL et a été confronté à une crise d’évolutivité bien documentée, la croissance du nombre d’utilisateurs ayant dépassé les capacités d’une seule base de données relationnelle. Le problème central résidait dans le graphe social — les relations « abonnés/abonnements » entre des centaines de millions d’utilisateurs — et dans le problème de diffusion en cascade des fils d’actualité : lorsqu’un utilisateur comptant 10 millions d’abonnés publie un tweet, celui-ci doit apparaître dans 10 millions de fils d’actualité de manière quasi instantanée.

Le modèle relationnel, tel que Twitter l’avait implémenté, ne pouvait pas prendre en charge cette diffusion des écritures à la vitesse requise. Twitter a migré le graphe social vers un magasin en mémoire personnalisé et a finalement adopté Manhattan (son magasin clé-valeur distribué interne) pour les fils d’actualité et Cassandra pour les autres charges de travail à forte intensité d’écriture.

La leçon à en tirer est nuancée. Les données fondamentales de Twitter — tweets, utilisateurs, relations — sont de nature fondamentalement relationnelle. Le problème ne résidait pas dans le modèle de données, mais dans le volume d’écriture et la diffusion à une échelle nécessitant une distribution. La migration a été coûteuse, techniquement complexe et a nécessité des années d’investissement en ingénierie. À l’échelle de Twitter, c’était la bonne décision. À l’échelle de presque n’importe quelle autre application, cela aurait été prématuré.

MongoDB : une mise en garde concernant la flexibilité du schéma

Au début des années 2010, alors que MongoDB gagnait rapidement en popularité, de nombreuses équipes l’ont adopté principalement pour sa flexibilité de schéma — la possibilité de commencer à stocker des données sans définir de schéma au préalable. Pour le prototypage et le développement en phase initiale, cela a véritablement accéléré les itérations.

Les problèmes sont apparus à mesure que les systèmes mûrissaient. En l’absence d’application stricte du schéma, les incohérences dans les données se sont accumulées progressivement. Des champs qui auraient dû être obligatoires étaient parfois absents. Des valeurs qui auraient dû être des entiers étaient parfois des chaînes de caractères. Des requêtes qui supposaient une structure cohérente renvoyaient des résultats inattendus. Les équipes se sont retrouvées à écrire des validations exhaustives au niveau de l’application, que la base de données aurait pu appliquer automatiquement.

Il ne s’agit pas d’un échec de MongoDB en tant que base de données — c’est un outil adapté à de nombreux cas d’utilisation. C’est l’échec de l’hypothèse selon laquelle la flexibilité du schéma est inconditionnellement bénéfique. La flexibilité a reporté le coût de la réflexion sur la structure des données ; elle ne l’a pas éliminé. Les équipes qui utilisaient MongoDB sans rigueur se sont retrouvées à implémenter une version affaiblie d’un schéma relationnel dans le code de l’application, sans les garanties qu’aurait fournies une base de données relationnelle.

Amazon DynamoDB : une réussite pour le bon cas d’utilisation

Le panier d’achat d’Amazon est l’un des exemples par excellence d’une utilisation réussie de NoSQL. Les exigences étaient claires : le panier d’achat devait être disponible en permanence (un client devait toujours pouvoir ajouter des articles, même en cas de panne régionale), il devait gérer un volume d’écriture massif (des centaines de millions d’utilisateurs ajoutant et supprimant des articles), et le modèle d’accès était simple et connu à l’avance (accès toujours par identifiant client).

L’équipe d’ingénieurs d’Amazon, dans l’article de 2007 qui a inspiré DynamoDB, a expliqué avoir délibérément opté pour la cohérence finale pour le panier : si deux appareils ajoutaient des articles simultanément lors d’une partition du réseau, les deux ajouts seraient conservés une fois la partition rétablie, même si cela impliquait d’afficher brièvement un état légèrement incohérent. Un panier d’achat sur lequel on peut toujours écrire — même au prix d’une brève incohérence — a plus de valeur qu’un panier parfois indisponible.

C’est la conception de DynamoDB autour de ce cas d’utilisation — accès simple clé-valeur, modèles de requêtes connus, disponibilité privilégiée par rapport à la cohérence — qui en fait un excellent outil. Les applications qui tentent d’utiliser DynamoDB comme une base de données relationnelle polyvalente, exécutant des requêtes complexes sur plusieurs entités, rencontrent régulièrement des difficultés.

Airbnb : Elasticsearch pour la recherche, PostgreSQL pour la véracité des données

La recherche sur Airbnb — qui filtre les annonces par lieu, dates, prix, équipements et disponibilité — est une requête qu’aucune base de données relationnelle ne peut traiter efficacement à grande échelle. La combinaison de la recherche géographique, de la correspondance en texte intégral et du filtrage complexe à plusieurs critères sur des millions d’annonces correspond précisément au cas d’utilisation pour lequel Elasticsearch a été conçu.

Airbnb utilise Elasticsearch comme couche de recherche tout en conservant PostgreSQL comme système d’enregistrement. Lorsqu’une annonce est mise à jour, la modification est enregistrée dans PostgreSQL (la source de vérité, avec des garanties ACID complètes), puis propagée de manière asynchrone vers Elasticsearch (l’index de recherche, optimisé pour les modèles de requêtes spécifiques à l’expérience de recherche).

Il s’agit d’un modèle architectural éprouvé : utiliser la base de données adaptée à chaque besoin, maintenir une source de vérité claire et accepter la complexité opérationnelle liée à la synchronisation de plusieurs bases de données. Cela fonctionne parce que les limites sont claires et que les compromis sont bien compris.

Quand choisir une base de données relationnelle

Une base de données relationnelle constitue le choix par défaut approprié pour la plupart des applications. Voici les cas où elle s’impose clairement comme le choix le plus judicieux :

Vos données présentent des relations significatives. Si les entités de votre système sont liées entre elles de manière significative — les utilisateurs et leurs publications, les commandes et leurs lignes de commande, les projets et leurs tâches —, le modèle relationnel représente directement ces relations et vous permet d’effectuer des requêtes efficaces sur l’ensemble de celles-ci.

Vous avez besoin d’une forte cohérence. Transactions financières, gestion des stocks, systèmes de réservation, dossiers médicaux : tout domaine où une lecture erronée a des conséquences réelles nécessite des garanties ACID. Une base de données relationnelle offre cela au niveau du moteur.

Vos schémas de requêtes ne sont pas entièrement connus. Si votre application doit répondre à des questions sur vos données que vous ne pouvez pas entièrement anticiper lors de la conception, la flexibilité de SQL est précieuse. La possibilité d’écrire une requête ad hoc sur un schéma bien normalisé constitue un atout opérationnel majeur.

Votre équipe maîtrise le SQL. Cela peut sembler anodin, mais ce n’est pas le cas. Le SQL est l’une des compétences techniques les plus répandues en génie logiciel. Chaque développeur que vous embaucherez le maîtrisera dans une certaine mesure. Les connaissances opérationnelles — comment ajouter un index, comment lire un plan de requête, comment gérer les sauvegardes — sont largement accessibles. L’écosystème d’outils est mature.

Vous ne savez pas exactement ce dont vous avez besoin. En cas de doute, commencez par PostgreSQL. Il est plus facile d’introduire un magasin de données spécialisé par la suite, une fois que vous aurez compris vos schémas d’accès réels, que de migrer d’un magasin de documents vers un modèle relationnel lorsque vos données s’avèrent plus structurées que vous ne le pensiez.

Quand choisir NoSQL

NoSQL est le bon choix lorsqu’une exigence spécifique ne peut être satisfaite par le modèle relationnel sans un effort disproportionné :

Le volume d’écritures dépasse ce qu’un seul nœud peut gérer. Si votre application doit supporter des centaines de milliers d’écritures par seconde sur un système distribué géographiquement, une évolutivité horizontale sur plusieurs nœuds devient nécessaire. Les bases de données par familles de colonnes comme Cassandra sont conçues pour cela ; les bases de données relationnelles peuvent être distribuées, mais ce n’est pas leur mode de fonctionnement naturel.

Vos données sont véritablement sans schéma ou très variables. Un catalogue de produits où les différents types de produits possèdent des attributs totalement différents, un CMS où les types de contenu évoluent rapidement, un système de journalisation où les schémas d’événements sont définis par des systèmes externes : ces cas tirent parti du stockage de documents, où la structure n’est pas imposée par la base de données.

Votre modèle d’accès principal est la recherche clé-valeur à très grande échelle. Stockages de session, caches, classements en temps réel, indicateurs de fonctionnalités — les charges de travail où vous accédez toujours aux données via une seule clé et n’avez jamais besoin d’effectuer de jointure ou d’agrégation tirent parti de la simplicité et des performances d’un magasin clé-valeur.

Vous modélisez un graphe. Si vos requêtes principales consistent à parcourir des relations — trouver tous les amis de vos amis, identifier le chemin le plus court entre deux nœuds, détecter des dépendances circulaires —, une base de données orientée graphe exprimera ces requêtes de manière plus naturelle et les exécutera plus efficacement qu’un SQL récursif.

Vous avez besoin d’une optimisation pour les séries chronologiques. Des millions de relevés de capteurs, de ticks financiers ou de métriques d’application par seconde, avec des requêtes portant principalement sur des plages de temps, sont mieux gérés par une base de données de séries chronologiques spécialement conçue à cet effet que par une base relationnelle dotée d’une colonne d’horodatage.

La réalité des bases de données multiples

Ce qu’il faut avant tout comprendre concernant l’opposition entre bases de données relationnelles et NoSQL, c’est que, dans la plupart des systèmes matures, il ne s’agit pas d’un choix exclusif. Les systèmes à grande échelle utilisent couramment plusieurs bases de données, chacune choisie en fonction de la charge de travail spécifique qu’elle doit traiter.

PostgreSQL pour le système d’enregistrement. Redis pour la mise en cache des sessions et la limitation de débit. Elasticsearch pour la recherche en texte intégral. InfluxDB pour les métriques d’application. Chaque base de données de cette pile remplit la fonction pour laquelle elle est la plus adaptée, et la couche applicative gère la cohérence entre elles.

Le coût opérationnel de cette complexité est bien réel. Chaque base de données supplémentaire représente un système de plus à surveiller, à sauvegarder, à faire évoluer et à maîtriser. La rigueur technique nécessaire pour maintenir la cohérence entre plusieurs bases — notamment en gérant les scénarios de défaillance où une écriture dans PostgreSQL aboutit mais où la mise à jour subséquente dans Elasticsearch échoue — n’est pas négligeable.

Le point de départ de presque toutes les applications devrait être une base de données relationnelle unique. N’ajoutez des bases de données spécialisées que lorsqu’une exigence spécifique et bien comprise ne peut être satisfaite sans elles. La diversification prématurée des bases de données est une forme d’optimisation prématurée : elle ajoute de la complexité avant même que vous ne sachiez si cette complexité est nécessaire.

Prendre la décision

Les questions qui comptent vraiment lors du choix d’une base de données :

Quelles sont vos exigences en matière de cohérence ? Si la réponse à la question « Que se passe-t-il si un utilisateur consulte des données obsolètes ? » est « C’est un problème grave », vous avez besoin d’ACID. Si la réponse est « C’est légèrement gênant mais acceptable », plusieurs options s’offrent à vous.

Quels sont vos schémas de requêtes ? Si vous savez exactement comment vos données seront consultées et que ce schéma d’accès est simple et implique un volume élevé, vous pouvez optimiser votre solution en conséquence. Si vos schémas d’accès sont complexes ou pas entièrement connus, la flexibilité du SQL est un atout précieux.

Quel est votre volume d’écriture ? Pour la grande majorité des applications, une instance PostgreSQL bien réglée sur un matériel raisonnable gère sans difficulté des milliers d’écritures par seconde. Les cas où cela s’avère véritablement insuffisant sont plus rares que ne le laissait entendre l’engouement pour le NoSQL des années 2010.

Quelle est la structure de vos données ? Des données très homogènes et étroitement liées s’adaptent bien au modèle relationnel. Des données très variables et faiblement liées peuvent mieux convenir à un modèle documentaire.

Quelles sont les compétences de votre équipe ? La maîtrise opérationnelle est essentielle. Une équipe qui connaît PostgreSQL sur le bout des doigts construira un système plus fiable sur PostgreSQL que sur une base de données NoSQL qu’elle est en train d’apprendre, même si cette dernière est théoriquement mieux adaptée.

La base de données relationnelle a survécu à cinquante ans d’évolutions technologiques non pas parce qu’elle est toujours le meilleur outil, mais parce qu’elle constitue un choix par défaut exceptionnellement judicieux : flexible, fiable, bien comprise et s’appuyant sur des décennies de savoir-faire opérationnel. Ne vous en écartez que de manière délibérée, en comprenant clairement ce que vous y gagnez et ce à quoi vous renoncez.