Au-delà du relationnel

Le relationnel n’a jamais été la seule réponse

Le chapitre précédent a détaillé la modélisation relationnelle, référence pour des données structurées et fortement liées entre elles, un client à ses commandes. Mais toutes les données ne se prêtent pas également bien à ce moule. Un document imbriqué, un flux d’événements, ou un réseau de relations à explorer, se modélisent parfois plus naturellement hors du relationnel. C’est le territoire du NoSQL (Not Only SQL), terme générique qui recouvre quatre familles assez différentes les unes des autres.

Un panorama en quatre familles

Les bases orientées document, MongoDB en étant l’exemple le plus connu, stockent chaque enregistrement comme un document structuré, souvent au format JSON, qui peut contenir ses propres sous-structures imbriquées. Elles conviennent bien à des objets métier auto-suffisants, un profil utilisateur avec ses préférences, une fiche produit avec ses variantes, dont on lit et écrit l’essentiel d’un seul bloc.

Les bases clé-valeur associent une clé unique à une valeur, sans structure interne imposée à cette valeur. Leur simplicité les rend extrêmement rapides pour des usages ciblés : cache applicatif, session utilisateur, compteur en temps réel. Elles ne conviennent en revanche pas à des requêtes complexes portant sur le contenu de la valeur elle-même.

Les bases orientées colonnes organisent le stockage par colonne plutôt que par ligne, ce qui accélère considérablement les agrégations portant sur un petit nombre de colonnes dans un très grand volume de lignes, un cas fréquent en analytique et en séries temporelles.

Les bases orientées graphe représentent explicitement les nœuds et les relations qui les lient, avec un coût de parcours qui reste stable même quand le graphe s’étend, là où une modélisation relationnelle équivalente multiplierait les jointures. Elles s’imposent pour des besoins de recommandation, de détection de fraude par réseau de relations, ou de représentation de connaissances : voir base de données orientée graphe, Wikipédia.

Choisir, sans céder à la mode

Le théorème CAP formalise un arbitrage central pour tout système de données distribué : en cas de panne réseau entre les nœuds d’un cluster, un système ne peut garantir simultanément la cohérence totale des données (Consistency) et leur disponibilité continue (Availability), il doit choisir laquelle sacrifier temporairement. Les bases relationnelles traditionnelles privilégient historiquement la cohérence, beaucoup de bases NoSQL distribuées privilégient la disponibilité. Ce n’est ni un défaut ni une qualité en soi, c’est un arbitrage à connaître avant de choisir, en fonction de ce que le métier tolère réellement : un compteur de like légèrement en retard n’a pas les mêmes conséquences qu’un solde bancaire incohérent.

Le critère de décision le plus fiable reste la nature des requêtes qu’on prévoit de faire, pas la popularité d’une technologie. Une donnée fortement relationnelle, avec beaucoup de jointures et des contraintes d’intégrité strictes, reste mieux servie par un moteur relationnel. Une donnée dont la structure varie d’un enregistrement à l’autre, ou dont le volume dépasse ce qu’un moteur relationnel unique absorbe confortablement, oriente vers le NoSQL. L’erreur de mode consiste à adopter une base NoSQL parce qu’elle est associée à l’échelle des grandes plateformes du web, sur un projet dont le volume et les contraintes de cohérence appelaient en réalité un relationnel classique, au prix de perdre les garanties d’intégrité sans gagner la performance annoncée. Une architecture polyglotte, qui combine plusieurs paradigmes selon le besoin de chaque domaine de données, est souvent la réponse la plus honnête, à condition d’assumer la complexité opérationnelle que cela ajoute.

Modéliser pour la décision

Modéliser une base transactionnelle et modéliser pour l’analyse décisionnelle répondent à des besoins différents, et prennent souvent des formes différentes. Le schéma en étoile organise les données autour d’une table de faits, qui porte les mesures quantitatives d’un évènement métier (le montant d’une vente, la quantité livrée), entourée de tables de dimensions, qui portent le contexte de cet évènement (le client, le produit, la date, le point de vente). Cette structure, volontairement dénormalisée, privilégie la simplicité et la rapidité des requêtes d’agrégation sur l’intégrité stricte que visait le modèle relationnel du chapitre précédent : ce ne sont pas les mêmes priorités, et ce n’est pas une contradiction. La granularité, le niveau de détail choisi pour une ligne de la table de faits, une vente unitaire ou un total journalier par exemple, est la décision la plus structurante de ce modèle : trop fine, elle alourdit inutilement le volume ; trop grossière, elle interdit certaines analyses futures sans tout reconstruire.

Cette organisation en étoile alimente un entrepôt de données (data warehouse), une base structurée et modélisée par avance pour l’analyse, alimentée par des traitements réguliers depuis les systèmes opérationnels. Le lac de données (data lake) répond à une logique inverse : il stocke les données brutes, structurées ou non, sans schéma imposé à l’entrée, ce qui offre une grande souplesse mais reporte l’effort de structuration au moment de l’exploitation. L’architecture lakehouse, plus récente, combine les deux, la souplesse de stockage d’un lac avec les garanties de structure et de transactions d’un entrepôt, grâce à des formats de table ouverts qui apportent au lac des propriétés jusque-là réservées aux bases relationnelles.

Choisir le bon paradigme de stockage ne suffit pas si la donnée qui y circule reste de mauvaise qualité. C’est l’objet du dernier chapitre de ce cours.