Paradigmes des systèmes NoSQL

Les entreprises ont de plus en plus de mal, à gérer des données qui arrivent sous des formes de plus en plus variées, et qui sont produites de plus en plus rapidement. Les géants du Web (Google, Yahoo, Facebook…) ont ressenti très tôt ce problème, et le besoin pressant de gérer efficacement ce flux important de données. Pour que vous vous fassiez une image claire du problème :
- Yahoo, Google et les autres fournisseurs de services mails gèrent l'envoi de plus de 2,9 millions d'emails dans le monde par seconde
- Amazon doit gérer 72,9 achats en moyenne sur son site par seconde
- Twitter doit publier en temps réel sur son site en moyenne 50 millions de tweets par jour
- Google doit s'organiser pour rendre disponible 5 heures de vidéos téléchargées sur Youtube par seconde
- Facebook doit gérer le partage de 2,46 millions de contenus en moyenne sur son site par minute
- Google doit restituer le résultat en temps quasi-réel de plus de 4 millions de recherches effectués sur son moteur de recherche par minute
- Instagram doit gérer le partage de 216 000 photos effectué sur son site par seconde.
(Stats disponibles en temps réel sur http://www.planetoscope.com/]

Vous rendez-vous maintenant compte de l'ampleur de l'explosion des données et du problème à gérer ?

Avant toute descente en eau profonde, je voudrais simplement rappeler qu'il est attendu d'un SGBD deux fonctions : le stockage et le requêtage des données.

L'approche traditionnelle de gestion des données consiste à centraliser le stockage et le requêtage des données sur un Serveur de Gestion de Bases de Données, contraint par un modèle de données dit "relationnel", construit en amont de la base de données. Ce type de système porte le nom de SGBDR (Systèmes de Gestion de Bases de Données Relationnelles). Ils ont l'avantage de stocker les données sous forme tabulaire (relationnelle), et garantissent l'unicité, la cohérence et l'intégrité des transactions effectuées dans la base de données à travers le mécanisme dit ACID (Atomicité, Cohérence, Isolation et Durabilité).
Nous y reviendrons dans un autre article. En plus, ils proposent un langage de gestion et d'interrogation de données déclaratif et procédural appelé le SQL, qui permet aux analystes métiers, avec relativement peu de compétences, d'aborder le traitement des données.

Cependant, avec le Big Data, les SGBDR ont montré très rapidement leurs limites face, d'une part à la forte volumétrie des données, et d'autre part à la diversité des types de données. En effet, les SGBDR sont conçus pour gérer uniquement des données structurées (tabulaires), de plus l'augmentation du volume des données augmente le temps de latence des requêtes. Cette latence est préjudiciable dans le cadre de nombreux métiers nécessitant des réponses en temps quasi-réel.

Dès lors, la solution conceptuelle au problème n'est plus de centraliser la gestion des données sur ce seul serveur (SGBD), mais de distribuer leur stockage et leur requêtage sur plusieurs ordinateurs (un « cluster » d'ordinateurs). Or, les SGBDR ne sont pas par essence des systèmes distribués. Ils n'arrivent à assurer la distribution des données que sur cinq nœuds (ordinateurs) tout au plus.

C'est donc pour répondre à ces nouvelles exigences de montée en charge, de disponibilité et de distribution du stockage que les SGBD dits "NoSQL" ont émergé, et la conférence du 11 juin 2009 à San Francisco avait précisément pour but d'inaugurer cette nouvelle catégorie de SGBD distribués.

Beaucoup traduisent le "NoSQL" par "No SQL", d'autres par "Not Only SQL". En réalité, le débat n'est pas là !
Le terme NoSQL n'a rien à voir avec la présence ou l'absence du SQL dans le SGBD. Il traduit plutôt un changement d'approche dans la conception du système et de la base de données.
L'approche de conception des SGBDR repose sur la théorie relationnelle (cf. les axiomes de l'algèbre relationnelle) mise en œuvre par Edgar Franck CODD. Or, l'exigence de distribution de données et de haute disponibilité rendent cette approche non-appropriée. Par conséquent, l'approche utilisée en NoSQL est une approche Non-Relationnelle.

L'approche conceptuelle des Systèmes "NoSQL" se fait à deux niveaux :

- au niveau du stockage de données : dans le NoSQL, l'unité logique de stockage n'est plus la relation (ou la table en langage courant), mais l'agrégat (à l'exception des Bases de Données Graphes, dont l'unité de stockage est le nœud).
L’agrégat est une collection d’objets (tel qu'une image, une vidéo, un document, ou tout autre donnée) référencés par une clé. On accède aux objets de la collection uniquement par la clé. Les agrégats n'ont pas de lien logique entre eux comme c'est le cas dans les SGBDR où les tables peuvent être liées entre elles au moyen des contraintes d'intégrité référentielles. Chaque agrégat est indépendant, ce qui facilite la distribution des données.
Souvenez-vous, le but des bases NoSQL est d'assurer la distribution du stockage et du requêtage de données sur un nombre théoriquement illimité de nœuds (cluster d'ordinateurs)

- au niveau de la haute disponibilité des données : dans un système distribué, assurer la cohérence des données est très contraignant et pénalise les performances du système. Pour venir à bout de cette limitation, les systèmes NoSQL optent pour un relâchement complet des contraintes d'intégrité référentielles et sémantiques, qu'on retrouve dans l'approche relationnelle.
Ceci implique une redondance de données et une absence de schéma (ou de modèle) au sein la base de données.

- la cohérence et l'intégrité des transactions : dans les SGBDR, toutes les transactions doivent être strictement ACID (Atomiques, Cohérentes, Isolées et Durables), sinon elles sont annulées. Les systèmes NoSQL dupliquent les données; Ce qui pose un problème transactionnel dans le cadre de la réplication. Pour faire plus simple, si on enregistre une donnée plusieurs fois, sur plusieurs nœuds d’un cluster, cet enregistrement redondant sera-t-il atomique, cohérent, isolé et durable ? Pas forcément ! En tous cas c'est ce que met en exergue le théorème CAP (Consistency, Availability, Partition, Tolerance).

- la distribution des données : distribuer les données dans le cluster contraint les systèmes NoSQL à relâcher les contraintes d'intégrité sur la Base de Données ; ceci entraîne une forte redondance des données, qui aura un impact sur la performance des requêtes.

- l'absence de schéma de données : l'avantage des systèmes relationnels est qu'ils permettent de séparer de façon totalement distincte la couche de données, de la couche applicative. Ceci permet aux développeurs de coder les applications métier, sans avoir à encapsuler la structure de la BD dans le code, et de développer les applications de façon totalement indépendante de la structure de la BD. Dans les bases NoSQL en revanche, il y a a priori absence de schéma de données, du coup, il est du ressort du développeur de coder à la fois la logique applicative et la couche "Cohérence de données" dans l'application. Ceci peut rendre difficile soit la mise à jour de l'application, soit la modification de la structure de la base de données.

- la modélisation, qui change l'approche projet de la BD : Dans le monde du relationnel, la modélisation de la base de données est la première phase obligatoire du projet ; de ce modèle va dépendre totalement la suite du projet et les applications qui vont exploiter ces données. Cette approche projet séquentielle exige que chaque étape du développement logiciel soit maîtrisée et terminée avant de passer à l’étape suivante. Dans le monde du NoSQL, toutes les contraintes relationnelles ont été relâchées, ceci se traduit par une flexibilité au niveau de l'approche projet.
Les approches itératives de développement (tels que les méthodes agiles) peuvent y être utilisées. Cette flexibilité semble attrayante de prime abord, mais de sérieux problèmes au niveau des plans de continuité, ou de gouvernance de données peuvent rapidement survenir.

- la disponibilité des données : Théoriquement, dans un système distribué, garantir un haut niveau de cohérence parmi les données pénalise les performances du système, car cela implique un échange d'informations important entre les nœuds du cluster, ce qui entraînera forcément des temps de latence accrus.

De façon générale :
- On n'évalue pas une technologie hors du contexte dans lequel elle a été crée ;
- Le contexte dans lequel une technologie a été créée détermine son but, et son but détermine son potentiel, ses caractéristiques et ses faiblesses ;

Alors :
- NoSQL = "Not Only SQL" ou "No SQL"? Aucun des deux ! Cela signifie simplement, changement d'approche, du relationnel au non-relationnel. On aurait normalement dû les appeler "NoRel" ;
- Est ce que les bases de données NoSQL sont l'avenir des Bases de Données ? C'est possible ! ;
- Est ce que le mouvement NoSQL constitue une révolution dans le domaine des bases de données ? Non ! ;
- Est ce les bases de données NoSQL sont meilleures que les bases de données relationnelles ? Mauvaise question !