Meyer Léonard 2014
L’AVENIR DU NoSQL
Quel avenir pour le NoSQL ?
1
L’AVENIR DU NoSQL
SOMMAIRE
Introduction ... 3
Histoire ... 3
Pourquoi NoSQL ? ... 4
Le Sharding ... 4
La Denormalization ... 5
Le Distributed Caching ... 5
A qui s’adresse le NoSQL ? ... 7
Exemples d’utilisation ... 8
Contre exemples ... 8
Théorème CAP ... 9
ACID ou BASE ? ... 11
Le NoSQL aujourd’hui ... 12
Les différents types de bases ... 12
État de l’art ... 20
Tour d’horizon des leaders ... 22
MongoDB ... 22
Cassandra ... 22
Redis ... 23
Couchbase ... 23
La contre-attaque du NewSQL ... 24
NewSQL et théorème de CAP ... 25
La relève ? ... 27
VoltDB... 27
Aerospike ... 29
NuoDB ... 30
Conclusion ... 31
Résultats et discussions ... 31
Google Spanner ... 32
Le point de vue du la communauté NoSQL ... 34
2
Avis des professionnels ... 35 Conclusion ... 46 Bibliographie... 47
3
Introduction
Les bases de données sont un élément très important dans l’informatique moderne.
Ces dernières années, le modèle relationnel s’est imposé comme la norme. En effet ce dernier permet un respect des propriétés ACID (Atomicity, Consistency, Isolation, Durability) et garanti ainsi la sécurité des données. Cependant ces propriétés demandent des prérequis importants, ce qui peut impacter grandement les performances de la base.
A terme cela peut se traduire par une difficulté de scaling. Certaines entreprises ont donc décidé de se pencher sur une nouvelle technologie afin de pallier aux problèmes de performances, quitte à sacrifier la consistance des données.
Ces différents constats peuvent soulever plusieurs points : Quels sont les différents types de base NoSQL ? Quels sont les avantages et inconvénients du NoSQL ? A-t-il des concurrents ?
L’objet de cette thèse est donc de fournir une réponse à ces questions en rassemblant des informations pertinentes et en investiguant les bases de données identifiées comme Not Only SQL, puis de les comparer avec les bases traditionnelles. Leur popularité générale auprès des professionnels et utilisateurs déterminera leur avenir. Cette popularité se mesura par la présence des solutions NoSQL au sein des entreprises ou solutions de ces derniers, le tout sur une échelle mondiale.
Cela permettra de conclure individuellement puis globalement sur leur pertinence ainsi que leur avenir.
Cette thèse s’adresse donc à tous les novices sur le sujet ainsi que ceux qui s’interrogent quant au bienfondé de cette technologie.
Histoire
Le terme NoSQL est pour la première fois sorti de la bouche de Carlo Strozzi en 1998, lors de la présentation de son système de gestion de bases de données relationnelles open source. Il l’a appelé ainsi à cause de l’absence d’interface SQL pour communiquer. Les bases NoSQL peuvent bien entendu être utilisées avec du SQL, c’est pourquoi Strozzi précise qu’il est plus pertinent d’utiliser le terme « NoREL » car ces dernières s'abstraient du côté relationnel des données. Le mot réapparu en 2009 lorsqu’Eric Evans l’utilisa pour caractériser le nombre grandissant de bases de données non-relationnelles lors d’une présentation sur les bases de données distribuées open source.
4
Pourquoi NoSQL ?
Une application web moderne peut supporter jusqu’à plusieurs millions d’utilisateurs simultanés en répartissant la charge sur un ensemble de serveurs, supervisés par un load balancer. Ces applications sont donc faites pour le scaling out, à savoir ajouter des serveurs afin de supporter de plus en plus d’utilisateurs. Le scaling horizontal (ou « out ») tient donc une place importante dans le contexte du cloud computing, où ajouter et retirer des instances de machines virtuelles se fait à la demande.
A l’opposé, les bases de données relationnelles (RDBMS) n’ont pas tellement évoluées depuis leur apparition il y a une quarantaine d’années, mais elles restent un choix de prédilection. Gérer plus d’utilisateurs devient alors synonyme de moyens financiers importants. Les serveurs imposants sont souvent complexes, propriétaires et très couteux.
De plus les RDBMS nécessitent la conception d’un modèle relationnel avant de pouvoir stocker une quelconque donnée. Si les développeurs réalisent qu’ils ont oublié un champ ou mis un mauvais type de donnée par exemple, le changement devient alors un problème car il modifie en profondeur le modèle de la base. Ainsi ces changements importants sont fréquemment évités.
Dans ce cadre, les développeurs ont créé des techniques visant à pallier aux problèmes de performance.
LE SHARDING
Les bases de données actuelles adoptent encore souvent un modèle centralisé : un serveur unique, éventuellement redondé en mode actif/passif pour la disponibilité. La solution la plus courante pour supporter plus de transactions est la scalabilité verticale : acheter une machine plus puissante (plus d’IO, de CPU, de RAM…). Le sharding quant à lui
FIGURE 1 SCALING D’UNE BASE RELATIONNELLE
5
se traduit par un partitionnement des données sur plusieurs serveurs. Bien que cela contribue à améliorer les performances, il y a quelques revers :
Complexité : Les requêtes SQL deviennent plus complexes, configuration des serveurs, backup difficiles…
Single Point Of Failure : Lorsqu’un shard est down, tout l’est également.
Obligation de maintenir un modèle sur chaque serveur.
LA DENORMALIZATION
Il s’agit d’un procédé qui vise à améliorer les performances en lecture via une redondance ou un groupement des données. Les implémentations de cette méthode se fait via des vues indexés (SQL Server) ou vues matérialisées (Oracle).
LE DISTRIBUTED CACHING
Le caching appliqué aux architectures distribuées (exemple : Memcached). Cela permet d’améliorer les performances en mettant en cache les données souvent demandées.
Mais une fois de plus il y a des problèmes comme des limitations sur les requêtes, la fragmentation du cache ou la disparition du cache lors d’un changement dans les tables.
Toutes ces techniques permettent donc d’étendre les possibilités des RDBMS mais dévoile un certain constat : Les bases de données relationnelles peuvent, mais ne sont pas conçus pour répondre à ce problème de scaling important des applications modernes.
Puisque les vendeurs de bases de données relationnelles n’ont aucun intérêt à proposer des solutions alternatives à des technologies qui génèrent des milliards de dollars, les développeurs ont dû prendre en main le problème. Google et Amazon par exemple sont deux leaders du marché qui ont inventé, développé et dépendent de leur propre technologie NoSQL.
6
En construisant sur leur travail, des vendeurs NoSQL ont commencé à émerger en proposant des solutions dédiées à l’entreprise.
Les systèmes NoSQL, bien que tous différents, partagent des points communs :
Les schémas de la base ne sont pas figés : Les données sont dorénavant bien plus flexibles car la structure et le type des données peuvent changer à tout moment sans forcément impacter l’application.
Sharding automatique : Aussi appelé élasticité, une base NoSQL peut se répartir sur plusieurs serveurs sans l’aide de l’application. De plus des serveurs peuvent être ajoutés ou retirés à la volée. Pour faire simple, un système NoSQL ne devrait jamais avoir à redémarrer.
Support des requêtes distribuées : Le sharding d’une base peut dans certains cas empêcher l’exécution d’une requête complexe. Ce problème est éliminé en NoSQL où on peut conserver toute la puissance du langage même pour récupérer des données réparties sur plusieurs dizaines de serveurs.
Caching intégré : Là où le système relationnel devra posséder une infrastructure physique séparée pour gérer le caching, les systèmes NoSQL le gère nativement de façon transparente pour l’utilisateur.
FIGURE 2 SCALING D’UNE BASE NOSQL
7
A qui s’adresse le NoSQL ?
C’est une évidence de dire qu’il convient de choisir la bonne technologie en fonction du besoin. Il existe cependant certains critères déterminants pour basculer sur du NoSQL.
Taille : Le NoSQL est conçu pour supporter un nombre important d’opérations, de données, d’utilisateurs etc… Quand quelque chose est conçu de manière tellement massive que cela doit devenir distribué. Bien que tous les systèmes NoSQL ne soient pas conçus pour cette problématique, il est possible d’en trouver sans problème.
Performance en écriture : Intérêt principal du géant Google, Facebook (135 milliards de messages par mois), Twitter (7TB de données par jour). Des données qui augmentent chaque année. A 80MB/s cela prend une journée pour stocker 7TB, donc l’écriture doit être distribuée sur un cluster, ce qui implique du MapReduce1, réplication, tolérance aux pannes, consistance… Pour des performances en écriture encore plus puissante, il convient de se tourner vers les systèmes in- memory.
Performance en lecture clé-valeur : Certaines solutions NoSQL ne possèdent pas cet avantage mais comme il s’agit d’un point clé la plupart d’entre elles en sont dotées.
Type de données flexibles : Les solutions NoSQL supportent de nouveaux types de données et c’est une innovation majeure. Les objets complexes peuvent être mappés sans trop de problèmes avec la bonne solution.
Migration modèle de données : L’absence de modèle facilite grandement les migrations. En effet le modèle est en quelque sorte dynamique car il est créé par l’application au run-time.
ACID : Bien que ce ne soit pas le but premier du NoSQL, il existe des solutions permettant de conserver certains (voire tous) aspects des propriétés ACID. Se référer au théorème CAP plus bas et aux propriétés BASE.
Pas de SPOF2 : Toutes les solutions n’en sont pas dotées, mais on dénote la présence d’une configuration relativement simplifiée du load balancing et du cluster sizing. Cela permet d’obtenir une bonne disponibilité.
Simplicité de développement : L’accès aux données est simple. Bien que le modèle relationnel soit simple pour les utilisateurs finaux (les données sont restituées selon la structure de la base), il n’est pas très intuitif pour les
1 MapReduce est un patron d'architecture de développement informatique, popularisé (et non inventé) par Google, dans lequel sont effectués des calculs parallèles, et souvent distribués, de données
potentiellement très volumineuses (> 1 teraoctet).
2 Le Single point of failure est un point d'un système informatique dont le reste du système est
8
développeurs. La réponse pour un problème de base de données ne peut pas toujours être celle d’embauche d’un DBA, le développeur devrait pouvoir être en mesure de le résoudre.
Parallel Computing : On peut également voir que le design pattern MapReduce est souvent embarqué dans les solutions NoSQL, ce qui améliore et facilite les calculs parallèles dans des architectures distribuées.
EXEMPLES D’UTILISATION
Si plusieurs de ces points sont importants pour un développeur, celui-ci devrait prendre en considération l’utilisation des systèmes NoSQL. Voyons des cas d’utilisations plus concrets :
Gestion de larges pans de données non transactionnelles3 comme des logs.
Système en temps réel ou la latence est vitale, comme des jeux par exemple.
Représentation d’objets complexes en base de façon simple.
Des systèmes embarqués qui ne souhaitent pas s’encombrer de l’overhead des bases traditionnelles.
Système de détection de fraudes qui compare les transactions en cours à des patterns connus.
Archivage continu et accessible en permanence.
Application web avec base de données online/offline avec synchronisation à la connexion.
CONTRE EXEMPLES
Bien entendu, le choix d’un système relationnel peut dans la plupart des cas suffire aux utilisations classiques d’une application quelconque. Les points suivants révèlent des cas où l’utilisation du NoSQL n’est pas forcément pertinente ou justifié.
Intégrité des données : Les systèmes NoSQL se base sur l’application pour la protection des données, là où le relationnel utilise une approche déclarative.
Indépendance des données ; En NoSQL, les applications font les données. Un argument en faveur du relationnel est que des données peuvent durer pendant tout le cycle de vie de l’entreprise, bien plus que n’importe quelle application. C’est pourquoi il vaut mieux privilégier le relationnelle dans ce cas.
SQL : Les systèmes NoSQL proposant une interface SQL ne sont pas courants et peut être pas plus adaptés si l’on est amené à vouloir du SQL.
3 Donnée non concernée par un processus métier
9
Relations complexes : Même si certaines solutions NoSQL proposent des relations, les systèmes relationnels ont souvent le dessus sur ce point.
Maturité et stabilité : Les bases relationnelles ont une longueur d’avance sur ce point. Les utilisateurs sont familiers avec leur fonctionnement, leurs possibilités et ont confiance en elles. Il y a aussi plus de documentation et d’outils disponibles pour ces dernières. Dans le doute il est donc plus sage de choisir les relations des bases traditionnelles.
THEOREME CAP
A l’heure de cette thèse, il existe environs 150 solutions NoSQL. Devant cette vague de technologies il devient de plus en plus difficile de savoir vers laquelle se tourner. C’est là qu’intervient le théorème CAP. Ce théorème provient d’une conjecture4 de 2000 faite à l’université de Berkeley par Eric Brewer. En 2002, cette conjecture a été prouvée par Seth Gilbert and Nancy Lynch, des enseignants du MIT, faisant ainsi d’elle un théorème. Le théorème énonce donc qu’il est impossible pour un système distribué de fournir les trois propriétés suivantes à la fois :
Consistency: Tous les noeuds du systèmes voient les même données au même moment.
Availability: Le requête d’écriture et de lecture sont toujours satisfaites.
Partition tolerance: La seule raison qui pousse un système à l’arrêt est la coupure totale du réseau. Autrement dit si une partie du réseau n’est pas opérationnelle, cela n’empêche pas le système de répondre.
Afin de créer une architecture distribuée on doit donc se résoudre à choisir deux de ces propriétés, laissant ainsi trois design possibles :
CP : Les données sont consistantes entre tous les nodes et le système possède une tolérance aux pannes, mais il peut aussi subir des problèmes de latence ou plus généralement, de disponibilité.
AP : Le système répond de façon performante en plus d’être tolérant aux pannes. Cependant rien ne garanti la consistance des données entre les nodes.
CA : Les données sont consistentes entre tous les nodes (tant que les nodes sont online). Toutes les lectures/écritures des nodes concernent les mêmes
4 Une conjecture est une assertion pour laquelle on ne connaît pas encore de démonstration, mais FIGURE 3 ERIC BREWER
10
données. Mais si un problème de réseau apparait, certains nodes seront désynchronisés au niveau des données (et perdront donc la consistance).
Le design CA n’est pas vraiment une option cohérente car un système qui n’est pas partition tolerant sera, par définition, obligé d’abandonner la consistance ou la disponibilité lors d’un problème de partition. C’est pourquoi il existe une version plus moderne du théorème : « Durant un problème de partition, il faut choisir entre la disponibilité et la consistance.».
En examinant les différentes propriétés du théorème, on s’apercoit que si l’ont veut scaler horizontalement de façon importante, nous avons besoin de partition tolerance. Cela rejoint donc la version la plus récente du théorème où il faut choisir entre l’Availability et la Consistency. Les bases de données NoSQL accomplissent cela en perdant le coté transactionnelle du problème.
FIGURE 4 GUIDE VISUEL AU NOSQL
11
ACID OU BASE ?
Il est important de noter que dans la majeure partie des cas, quand quelqu’un fait référence aux principes ACID, il cherche surtout à faire en sorte de conserver l’intégrité des données. Autrement dit que ces données ne deviennent pas corrompus ou se perdent.
Beaucoup de bases NoSQL peuvent fournir ce principe justement via le principe BASE.
Choisir une base NoSQL revient donc à savoir quoi faire au niveau applicatif pour compenser les défauts. A savoir l’implémentation de divers mécanismes tels :
o Contrôle de concurrence optimiste : Procédé visant à faire en sorte de conserver la propriété d’isolation des transactions. Plus précisément chaque transaction cherchera à savoir si elle s’effectue seule ou non.
o Idempotence des opérations : Fait qu’une opération puisse être répétée sans incidence sur le système jusqu’à ce qu’elle réussisse.
o Utilisation des transactions longue durée : Technique aussi appelé
« sagas » utilisé dans des environnements distribués où plusieurs transactions sont groupées avec un identifiant unique afin de restaurer à l’état initial en cas d’annulation. Cette opération aggrège donc un ensemble de transactions ACID réduites, mais plus légères qu’un commit en deux temps.
Le principe BASE est donc plus facile à appliquer que des propriétés ACID complètes. Les processus métiers ne sont au final que des modèlisations des processus du monde réel. Ils arrivent que ces processus échouent, comme quand un vol est annulé. Que faire dans ce cas ? Récupérer son argent ? Partir ailleurs ? Ce sont juste des règles métiers à implémenter différemment en fonction du système. Prenons Amazon qui, afin de tenir la charge d’utilisateurs, a choisi d’occulter l’isolation de ses transactions. Par exemple, deux utilisateurs pourraient croire qu’ils ont acheté le dernier exemplaire d’un même livre.
Amazon estime donc qu’il est plus judicieux de s’excuser envers un utilisateur que de tout ralentir et agacer une myriade d’autres utilisateurs.
Cette notion de BASE (Basically Availabe, Soft State, Eventuallty Consistent) est donc à l’opposé de ACID. Les deux principes ne sont cependant pas mutuellement exclusifs. Le principe BASE abandonne donc la consistance au profit de ces nouvelles propriétés :
Basically available : Le système garantie bien la disponibilité dans le même sens que celle du théorème de CAP.
Soft-State : Indique que l’état du système peut changer à mesure que le temps passe, et ce sans action utilisateur. C’est dû à la propriété suivante.
Eventually consistent : Spécifie que le système sera consistent à mesure que le temps passe, à condition qu’il ne recoive pas une action utilisateur entre temps.
12
A partir de ce constat, comment déterminer lequel de ce choix est le plus pertinent pour un cas d’utilisation donné ?
ACID est nécessaire si :
Beaucoup d’utilisateurs ou processus qui travaillent sur une même donnée au même moment
L’ordre des transactions est très important.
L’affichage de données dépassées n’est pas une option.
Il y a un impact significatif lorsqu’une transaction n’aboutie pas (dans des systèmes financiers en temps réel par exemple).
BASE est possible si :
Les utilisateurs ou processus ont surtout tendances à faire des mises à jour ou travailler sur leurs propres données.
L’ordre des transactions n’est pas un problème (voir l’exemple d’Amazon plus haut).
L’utilisateur sera sur le même écran pendant un moment et regardera de toute façon des données dépassées.
Aucun impact grave lors de l’abandon d’une transaction.
Le NoSQL aujourd’hui
Comme mentionné dans la partie précédente, il existe beaucoup de solutions NoSQL. Certaines comme HBase, MongoDB ou Neo4j apparaissent régulièrement dans l’actualité et sont toutes libellées en tant que NoSQL. Il existe cependant des différences significatives entre elles, liées notamment au théorème de CAP.
LES DIFFERENTS TYPES DE BASES
Associative (ou orientée clé-valeur)
Les bases associatives sont les formes les plus simples de bases NoSQL et portent bien leur nom. Il s’agit d’un système qui stocke des valeurs indexées par des clés uniques.
L’API de requête est très simple puisque basé uniquement sur la clé et contient juste put,
13
get et delete. Les valeurs stockées sont totalement opaques pour la base et ne sont pas liées à un modèle de données prédéfini.
Par conséquent il est impossible de filtrer ou demander une partie des données comme en SQL avec la clause WHERE. Si on ne sait pas précisément ce que l’on veut, on doit alors itérer sur les données, les filtrer puis garder celles que l’on veut. Cela peut vite devenir très intensif d’un point de vue traitement, c’est pourquoi il convient d’éviter cette technologie si on ne connait pas les clés voulues.
En revanche pour une utilisation appropriée permet des performances impressionnantes sur des opérations de lecture/écriture et un scaling horizontal le plus extensible du marché. Pour résumer voici les caractéristiques principales du système associatif :
Aucun SQL
Meilleure scalability horizontal du marché.
Peut ne pas fournir un support des propriétés ACID
Peut offrir une architecture distribuée et tolérante aux pannes.
Implémentations :
DynamoDB : Solution d’Amazon à l’origine de ce type de base. Système ultra scalable basé sur des SSD rapides. Design de type AP selon le théorème de CAP mais peut aussi fournir une consistance éventuelle.
Voldemort : Implémentation open-source de Dynamo. Très scalable via un stockage sur disques. Possibilité d’en faire une base embarquée.
Orientées colonnes
Les bases de données orientées colonnes sont grossièrement une évolution du modèle associatif. Elles constituent la poupe du mouvement NoSQL à cause de leur récurrence dans l’actualité avec des candidats comme HBase ou Cassandra. De par leur
14
structure, les bases orientées colonnes se rapprochent des bases relationnelles, à la différence près que les données sont organisées en colonnes et non en lignes.
Concrètement cela signifie que, contrairement aux bases orientées lignes, les utilisateurs qui souhaitent des informations précises n’auront pas à s’encombrer des informations inutiles des autres colonnes. En effet les bases orientées lignes se doivent de lire entièrement les lignes avant de sélectionner les colonnes désirées par la requête. Les principaux avantages de ce type de système sont donc :
Il est plus performant d’extraire des données pour une densité importante d’informations.
Améliore grandement les performances sur les tris ou agrégations de données car ces opérations sont réalisées via des clés de lignes déjà triées.
Bien entendu si un système est davantage utilisé pour des opérations de mise à jour ou suppression il est plus judicieux de se tourner vers une base orientée lignes. Imaginez la mise à jour d’une dizaine de colonnes pour un enregistrement : avec une organisation en lignes cela fait une recherche, alors qu’en colonnes cela en fait dix. Ces deux systèmes sont souvent considérés comme complémentaires, c’est pourquoi certains organismes font graviter leurs processus métiers autour d’une base relationnelle classique (beaucoup d’update ou delete) et leurs processus de data mining5 autour d’une base orientée colonnes (beaucoup de tri et agrégations).
La multiplication massive du nombre de colonnes rend ce modèle capable de stocker les relations one-to-many ce qui permet de couvrir de nombreux cas. De plus, chaque ligne d’une base orientée colonnes peut posséder son propre modèle (exception faites des column family et autres supercolumn de certaines implémentations). En se référant à la figure ci-dessus on peut donc voir des column family (A, B…E) et des colonnes spécifiques à chaque enregistrement (foo, Tom, scala).
En revanche les requêtes simplistes constituent une contrainte qui destinera ces bases aux applications pouvant se contenter d’un accès à données simplifiées au profit d’une performance, d’une scalabilité et/ou d’une fiabilité accrue.
Implémentations
HBase : Utilise un API Java. Adopte un design CA. Présence de quelques SPOF.
Cassandra : Beaucoup d’API disponibles. Adopte un design AP avec consistance éventuelle. Aucun SPOF car réplication master/master. Moins performant que HBase sur les insertions de données.
5 Le data mining est un processus qui permet d’extraire des informations commercialement pertinentes à partir d’une grande masse d’informations.
15
Orientées documents
Les bases de données orientées documents sont une alternative aux bases orientées colonnes. Elles fonctionnent donc sur le même principe associatif (ici clé-document) mais avec un ajout de fonctionnalités qui passe par la prise en compte de la structure des données stockées sous forme de document. Ces fonctionnalités comprennent :
Ajout, modification, lecture ou suppression de seulement certains champs dans un document
Indexation de champs de document permettant ainsi un accès rapide sans avoir recours uniquement à la clé
Requêtes élaborées pouvant inclure des prédicats sur les champs
. Les bases de données orientées documents sont donc plus flexibles au niveau de l’accès aux données car contrairement à leur équivalent colonnes on peut accéder à des enregistrements en passant par des valeurs. Cette caractéristique les rapproche donc des bases SQL. De plus ce type de base n’est pas « entravé » par un modèle prédéfinie.
Chaque document stocké possède sa propre structure et types. Cependant bien que ces documents ne doivent pas se conformer à un modèle, cela ne veut pas pour autant qu’il n’y a aucune contrainte sur les données. Par exemple il existe beaucoup d’implémentations qui utilisent le format JSON ou XML La plupart des bases orientées documents fournissent des API afin de requêter simplement de manière objet, par conséquent le mapping documents/objets est très simple à réaliser.
Implémentations
MongoDB : Développé en C++. APIs officielles pour beaucoup de langages.
Protocol personnalisé BSON. Réplication master/slave et auto-sharding. Licence AGPL (commercial et freeware).
CouchDB : Développé en Erlang. Protocol http. Réplication master/master. Licence Apache.
16
Orientées objets
Le terme de base de données orientée objets remonte à 1985. La première base commerciale de ce type date quant à elle de 1990, elle a posé les bases du support natif de la persistance pour les langages orientées objets. Un regain d’intérêt est apparu pour ces bases durant la première décennie du 21ème siècle lorsqu’elles sont revenues en force entièrement réécrites en langage objet.
Quand les bases de données sont fortement liées au langage de programmation, il en résulte ce que l’on appelle un système de gestion de base de données orienté objets (OODBMS en anglais) Ces derniers permettent aux développeurs de créer, manipuler et stocker leurs objets en tant que tels dans la base. Ainsi l’application et la base sont fortement liées, contrairement aux systèmes relationnels ou la séparation est distincte, et où ce genre de mapping se réalise via des ORMs6.
Les performances entre les deux dépendent entièrement de l’implémentation. Afin de faire son choix il est pertinent de prendre en compte la scalability horizontal et la durée de vie des données. En effet il est inutile de s’encombrer avec un couplage application/base de données fort si les données seront partagées ou dureront plus longtemps que le programme.
Au-delà de cet aspect, il existe plusieurs atouts notables aux OODBMS:
Relations des objets : La présence de « pointeurs » persistés entre les objets peut sensiblement améliorer les performances par rapport à des jointures SQL classiques.
Pas de couche ORM : Réduit significativement le temps de développement, maintenance et administration.
Modélisation proche de la réalité : Les objets sont organisés et classes et les objets sont associés à des comportements. Le modèle est donc basé sur les objets directement plutôt que sur les données et leur traitement.
Pas d’impedance mismatch7.
Une technologie n’étant jamais parfaite il existe bien entendu des contreparties. Déjà mentionné le couplage fort entre le programme et la base. En effet les OODBMS sont fortement liés à l’API utilisée, et donc à son langage. De plus, étant donné la nature des relations, il n’est pas possible de faire des jointures afin de réaliser des requêtes ad-hoc8.
6 Technique de programmation qui crée l'illusion d'une base de données orientée objet à partir d'une base de données relationnelle en définissant des correspondances entre cette base de données et les objets du langage utilisé.
7 Fait d’effectuer un mapping vers une structure de données différente de la structure source.
8 Une requête ad hoc est une requête qui ne peut pas être déterminé avant son exécution.
17
Peu d’organismes utilisent cette technologie dans un environnement professionnel, c’est pourquoi il est difficile de s’informer dessus et de trouver du personnel qualifié. Il existe cependant quelques exemples :
La bourse de New York utilise Versant pour gérer les actions.
Le Grand collisionneur d’hadrons (particule composite) au CERN en Suisse utilise ObjectivityDB.
ObjectivityDB est également utilisé comme stockage de données pour les noms des composants systèmes, le planning des missions satellites et de la gestion de l’orbite du projet Iridium financé par Motorola.
Implémentations
Objectivity/DB : Réplication master/slave, Nativement .NET et supporte d’autres langages. Langage de requête OQL. Moteur de requêtes parallèles. Licence commerciale.
Db4o : Réplication vers RDBMS, Support du .NET et Java. Interface de requête SQL et plugin Visual Studio. Licence GPL.
Orientées graphes
18
Les bases de données orientées graphes sont des systèmes bien différents des autres bases de données. Pour mieux comprendre, il est nécessaire de revenir sur la notion de scalability. Il y a en fait deux cotés à la scalability d’une base de données : non seulement le volume, mais aussi la complexité des données. Les bases orientées graphes représentent cette complexité en utilisant, comme leur nom l’indique, la théorie des graphes9. En conséquence, même s’il est possible de pousser le volume de donnée gérée assez loin (de l’ordre de plusieurs milliards de nodes et relations), l’idée principale reste d’exprimer des relations très complexes entre des données. Certains diront qu’il est possible d’exprimer de la complexité avec des bases relationnelles, et ils auront raison, à la différence près que les relations des graphes sont définies au niveau des enregistrements de la base et non au niveau du modèle de données. Cela sous-entend deux choses :
Une base relationnelle est plus rapide pour examiner des petits volumes de données. Lors d’une requête dans une base orientée graphe, il est nécessaire d’examiner chaque enregistrement pour déterminer la structure des données, alors que cette structure est déjà connue dans une base relationnelle.
Il est inutile de stocker les relations avec un modèle relationnel, c’est pourquoi la base orientée graphe prendra plus de place.
Le stockage de relations au niveau des données n’a de sens que si ces relations sont toutes très différentes, sinon cela revient à dupliquer la même chose encore et toujours.
Nuançons encore ces propos… Imaginez un table Personne et Cours : Il est fréquent dans un modèle relationnel d’avoir une relation quelconque entre ces deux tables comme le fait qu’une personne puisse faire partie d’un ou plusieurs cours. Que faire alors si l’on veut caractériser davantage cette relation ? Ajouter une table intermédiaire avec les informations désirées. Si par exemple on veut ensuite savoir via une requête combien de personnes sont associées à un cours, on devra réaliser une opération de jointure. Dans la plupart des cas cette opération marchera sans problème mais elle n’est pas la plus performante car ici on doit alors parcourir toutes les tables pour accéder à l’information. Dans le cas d’une base de données orientée graphes, le cours sera directement associé aux personnes concernées, ce qui améliore sensiblement les performances. Imaginez maintenant le même problème mais avec un volume de données plus beaucoup importants : le gain compenserait-il le problème de stockage des relations ? La réponse est probablement positive mais reste incertaine car elle dépend de beaucoup de facteurs (présence d’index, de transactions, des implémentations etc…).
De façon générale on peut dire qu’il est intéressant de choisir ce paradigme lorsqu’on cherche à représenter des structures chaotiques et complexes tel le social graph de Facebook. L’utilisation de bases de données orientées graphes se propage rapidement via une approche hybride où la base relationnelle permet d’obtenir des données brutes et ou la partie graphe permet de fournir des informations sur les données en question. Bien que
9 Théorie visant à savoir trouver et exploiter les propriétés des différents types de graphes.
19
cette approche soit lourde en administration et développement, cela permet d’obtenir des informations très pertinentes liées à la business intelligence 10 grâce au graph mining11.Certaines implémentations respectent même les propriétés ACID et utilise des techniques de compression de données pour prévenir les problèmes de type super node (où un node est tellement connecté que cela revient à rapatrier une partie du graphe avec lui). Les algorithmes de traversal12 et la complexité des relations représentées permettent de fournir des informations que seul un graphe pourrait fournir.de manière performante.
Pour résumer :
Pensé pour des applications avec beaucoup de relations complexes,
La structure du graphe peut évoluer librement.
Les bases orientées graphes ne scalent pas autant horizontalement que leurs alternatives NoSQL.
Peut fournir des informations extrapolées des relations entre certains nodes.
Manque de support via des frameworks ou des outils.
Implémentations
Neo4J : Développé en Java. Supporte beaucoup de langages. Réplication master/slave. Propriétés ACID possibles. Langage de requêtes personnalisé « Cypher ».
Titan : Scalability horizontal très poussée grâce au support d’une base orientée colonnes pour les données. Haute disponibilité avec réplication master/master. Prise en compte d’ACID avec consistance éventuelle. Intégration native avec le framework TinkerPop.
10 L’informatique décisionnelle désigne les moyens, les outils et les méthodes qui permettent de collecter, consolider, modéliser et restituer les données, matérielles ou immatérielles, d'une entreprise en vue d'offrir une aide à la décision et de permettre à un décideur d’avoir une vue d’ensemble de l’activité traitée.
11 Cas particulier de structure mining qui définit un processus de recherche et d’extraction d’informations sur des structures de données semi-organisées.
12 Processus de visiter chaque node d’un arbre au moins une fois.
20
ÉTAT DE L’ART
Après plusieurs années d’âpres critiques, force est de constater que le NoSQL a suscité beaucoup d’intérêts de la part des professionnels. En témoigne Google Trends :
En quatre ou cinq années, l’univers NoSQL a vu son nombre de base de données tripler. Beaucoup de personnes attendaient une consolidation des premières technologies, mais contre toute attente un autre phénomène s’est produit. Le NoSQL explose, et continue d’exploser. Comme dans tous les domaines informatiques, on découvre sans arrêt des opportunités et des défis à relever pour des nouvelles bases de données.
Tout le monde s’accorde à dire que cette explosion est due à Internet et BigData 13 qui ne cessent de rappeler le problème de volume et complexité des données. Durant les années passées, un seul projet NoSQL a échoué : la base de données orientée graphe Sones. La vaste majorité des autres solutions continuent à vivre tranquillement sous licence open source ou commerciale.
Un autre point important à soulever est la perception du NoSQL par l’industrie. On peut nettement voir un clivage entre les acteurs les plus anciens, qui essaient de protéger leurs investissements, et les nouveaux arrivants qui sont principalement des startups remplies d’idées nouvelles. Tandis que ces derniers optent généralement pour une solution hybride, les autres ont encore du mal à accepter le NoSQL. On peut cependant observer un fait intéressant : de plus en plus d’anciennes compagnies se mettent à utiliser ou même développer des technologies NoSQL afin de séparer leurs données analytiques. On citera notamment Oracle qui, en quelques mois, est passé du mépris au développement de Oracle NoSQL Database, une base de données orientée clé-valeur. Microsoft a également discrètement introduit des notions intéressantes dans la version 2012 de SQL Server (gestion de données non structurées via stockage en colonnes par exemple).
13 Big data (littéralement « grosses données » ou « grande quantité de données ») est une expression anglophone utilisée pour désigner des ensembles de données qui deviennent tellement volumineux qu'il en devient difficile de travailler avec des outils classiques de gestion de base de données.
FIGURE 5 EXPLOSION DES RECHERCHES A PARTIR DE 2009
21
Analysons maintenant ces tendances issues des statistiques du site agrégateur d’emplois d’envergure mondiale Indeed.com ;
Ce segment montre une nette progression de l’occurrence dans les offres d’emplois du monde entier toutes catégories confondues. En termes de proportions cela reste en dessous des bases relationnelles classiques qui elles ont plus ou moins stagnées (exception faite de MySQL).
Autre fait notable, le NoSQL commence discrètement à gagner sa place dans les standards PaaS14. En effet les services comme Cloud Foundry, dotCloud ou encore Jelastic font trôner des solutions NoSQL telles que MongoDB ou Redis au milieu des MySQL et autres PostgreSQL. Lorsque l’heure est plus que jamais au cloud, cela constitue une très bonne occasion pour le NoSQL de gagner son momentum. Lorsqu’un utilisateur sera confronté à une décision lors du choix de sa persistance, il est possible qu’il soit amené à repenser à la pertinence de son modèle ou architecture.
La maturation de la littérature NoSQL commence également à se faire sentir. Après deux premiers livres publiés exclusivement en Allemand en 2010 et 2011, des éditeurs connus commencent à s’y mettre. On notera le livre Wiley rédigé par Shashank Tiwari, rempli d’indications intéressantes. La suite ne s’est pas fait attendre avec deux nouveaux livres en 2012. Récent et avec des exemples concrets, le livre « Seven Databases in Seven Weeks » est à retenir. Il prend six bases NoSQL et ajoute PostGreSQL dedans, ce qui en fait une recommandation à ne pas négliger. Citons aussi Manning et son « Making Sense of NoSQL » avec des chapitres très pertinents.
14 PaaS, de l'anglais Platform as a Service, est l'un des types de Cloud computing, principalement FIGURE 6 EXPLOSION DES OFFRES D’EMPLOIS DEPUIS 2010
22
Le fait est que tous ces exemples montrent bien que NoSQL a su trouver sa place au sein de l’écosystème des bases de données. On est donc en droit de se demander qu’en est-il du statut des leaders du marché ? Vers quoi se dirigent-ils ?
Tour d’horizon des leaders
MONGODB
La solution orientée documents souffre encore des disputes virtuelles, et c’est peut être une chose naturelle au vu de l’important que prennent les bases de données ces dernières années. Néanmoins MongoDB avance vite et les seuls problèmes valides concernent généralement des versions dépassées ou un manque de connaissances. Ce dernier point a déjà culminé au sommet de l’absurdité quand certains acteurs se sont plaints de la limite de 2GB sur la version 32 bits, alors que MongoDB le signale clairement dans sa section téléchargements en conseillant la version 64bits pour des usages professionnels.
Quoi qu’il en soit les investissements et partenariats de MongoDB semblent de plus en plus prometteurs :
L’industrie a demandé plus de sécurité et des fonctionnalités LDAP.
Full text search15
Abandon de du moteur javascript SpiderMonkey pour V8 afin d’améliorer les performances MapReduce
Un niveau encore plus fin qu’un lock au niveau des collections pour aider avec les problèmes de concurrence.
Hash shard key.
La plupart de ces points sont en phases d’être réglés et certains sont même déjà arrivés. Beaucoup d’architectes auront remarqué la dernière fonctionnalité. MongoDB s’est souvent vu reproché (notamment par les concurrents) de ne pas implémenter de clé de Shard16 claire et précise, ce qui n’est pas tout à fait vrai car même avant il y avait moyen d’y substituer quelque chose de similaire. Dorénavant MongoDB permettra de configurer simplement une telle clé, ce qui signifie que les utilisateurs pourront en implémenter dans leur sharding s’ils jugent nécessaire.
CASSANDRA
15 Technique de recherche dans un document électronique ou une base de données textuelle, qui consiste pour le moteur de recherche à examiner tous les mots de chaque document enregistré et à essayer de les faire correspondre à ceux fournis par l'utilisateur.
16 Champ dans les collections (au sens MongoDB, donc ensemble de documents) utilisé pour distribuer des documents au sein d’un cluster shard.
23
Base de données orientée colonnes, Cassandra s’en sort elle aussi plutôt bien en ajoutant de nouvelles fonctionnalités au fur et à mesure comme l’amélioration de ses requêtes. Cependant les discussions ne s’arrêtent pas quant au fait que la configuration d’un cluster Cassandra n’est pas une partie de plaisir. Le point le plus notable reste DataStax, l’entreprise derrière Cassandra, qui s’efforce d’intégrer des fonctionnalités de data mining. Depuis le début Cassandra n’était pas considérée comme un puissant système de requêtes, mais depuis peu et avec l’ajout de nouvelles fonctionnalités, il devient envisageable de s’essayer à l’analyse des données.
REDIS
Après avoir connu une grosse croissance en 2010, Redis continue tranquillement son chemin avec l’ajout du « sentinel failover » qui s’occupe de monitorer, notifier et basculer automatiquement des instances en cas de problèmes. L’intégration du langage Lua, bien qu’inattendu car tout le monde utilise du Javascript, permettra d’étendre encore les possibilités de cette base orientée clé-valeur.
COUCHBASE
Depuis sa naissance en 2011 via la fusion de Membase et CouchOne, CouchBase est devenu un acteur important du milieu NoSQL. Son produit CouchBase Server est donc un grand pas en avant. Il est intéressant de voir les influences de CouchOne (avec CouchDB) conservés. Les dernières fonctionnalités de Couchbase sont les suivantes :
Passage d’une orientation clé-valeur à une orientation documents
Support natif du JSON qui permet ainsi d’obtenir des documents avec des différentes structures
Amélioration des requêtes et indexation.
Les documents peuvent être indexés via des vues. Tous les index sont automatiquement distribués à travers les nodes d’un cluster. Les requêtes supportent dorénavant des recherches par clé, par filtre et les agrégats. Les requêtes sont également traitées pendant des changements de topologie (failover etc..)
Réplication XDCR (cross data-centers)
Réplication des données sur plusieurs clusters répartis dans plusieurs data-centers afin de prévenir des catastrophes naturelles ou encore pour rapprocher les données des utilisateurs finaux pour une meilleure expérience.
24
MapReduce incrémental.
Amélioration des performances des fonctions d’agrégation pour des analyses en temps réel
La contre-attaque du NewSQL
Michael Stonebraker, gourou des SGBD, aujourd’hui à la tête de VoltDB, s’est fait connaitre comme un fervent dénonciateur du mouvement NoSQL. Pour Stonebraker il faut une nouvelle génération de bases de données : “Ce qui a changé en 25 ans, c’est que nous soumettons tous des requêtes via Internet, l’effet étant
que cela a envoyé les volumétries au travers du plafond”.
Et outre les volumes en jeu, il se pose la question de la disponibilité : “En 1985, quand vous aviez un service en ligne, l’idée était qu’en cas de crash vous deviez redémarrer le plus rapidement possible à partir de vos backup. Aujourd’hui, tout downtime est impossible : si vous n’êtes pas 100% en ligne, vous êtes hors coup !”.
A partir de là, trois pistes sont possibles : les bases de données SQL traditionnelle : “Vous pouvez exécuter les vieilles bases SQL, que j’appelle les bases “legacy”,
des éléphants donc certaines lignes de code ont été écrites… il y a 30 ans !”. Seconde option, celle du NoSQL. Contrairement à ce qu’on pourrait croire, il se montre tout autant critique sur cette nouvelle génération vis-à-vis des applications OLTP17 : “NoSQL a abandonné SQL, a abandonné des atouts pour gagner en performance et scalability mais ne convient pas à l’OLTP. Il faut le bon outil pour la bonne tâche”. La troisième option évoquée par Stonebraker est d’opter pour NewsSQL : “NewSQL, c’est conserver SQL, conserver le modèle relationnel et conserver ACID tout en ayant la performance et la scalability”.
Alors au final, qu’est-ce que le NewSQL ? NewSQL est né de la rencontre de 3 types d’architecture : relationnelle, NoSQL et grille de données (ou cache distribué). En effet, NewSQL se positionne comme un stockage distribué conçu dans le prolongement des architectures NoSQL, pour des accès transactionnels à fort débit au moyen d’une interface SQL. Du point de vue de la scalability il est donc un concurrent direct de solutions NoSQL comme Cassandra. Mais contrairement à ces solutions il conserve une interface relationnelle via le SQL ce qui est l’une de ces forces. Enfin la plupart des solutions NewSQL proposent un stockage en mémoire. Le stockage en mémoire distribué sur plusieurs machines, sous forme de grille de données est largement utilisé depuis une dizaine d’années dans les environnements où une faible latence est critique, notamment
17 Type d'application informatique qui sert à effectuer des modifications d'informations en temps réel.
Ces systèmes sont caractérisés par un traitement des requêtes très rapides tout en maintenant l’intégrité des données
FIGURE 7 MICHAEL STONEBREAKER
25
dans certaines applications des banques d’investissement. Les solutions NewSQL partagent ainsi un positionnement intermédiaire entre solutions NoSQL et grille de données.
Depuis plusieurs années déjà (fin des années 90), les grilles de données existent.
Elles offrent des débits 10 fois supérieurs aux SSD (Solid State Drive) et des temps d’accès 100 fois inférieurs.
Pendant longtemps, ce type de technologie a été utilisé en tant que cache, du fait des limitations sur la taille de la RAM et de son absence de durabilité (la donnée est perdue en cas de perte d’alimentation). Le caractère distribué du stockage dans les grilles de données a apporté une solution à ces deux problèmes. En permettant d’augmenter la taille du stockage par ajout de machines, elles permettent d’atteindre des volumes de plusieurs centaines de GB, très suffisant pour stocker la plupart des bases transactionnelles. En répliquant une même information sur plusieurs machines, elles permettent de faire survivre la donnée à une coupure électrique sur une machine.
Cette nouvelle génération semble donc régler tous les problèmes que nous rencontrons à la fois avec NoSQL, mais aussi avec les bases relationnelles. Mais alors qu’en est-il de théorème de CAP ?
NewSQL et théorème de CAP
Nous venons donc de définir le NewSQL comme une nouvelle race de bases de données relationnelles créée pour être scalable sur des architectures distribuées, ou encore éviter le problème de la scalability horizontale via la performance. Retenons aussi que cette technologie retient les principes ACID et un possible support du SQL.
En examinant cette description on peut voir qu’elle se rapproche fortement de la trinité du théorème de CAP, à savoir : disponibilité (performance), consistance (ACID) et tolérant aux pannes (architecture distribuée). Ce constat va à l’encontre de la compréhension générale du théorème. Comment est-il alors possible de choisir les trois propriétés ?
Le théorème de CAP n’est en fait pas si simple. Comme le suggère Henry Robinson de Cloudera, il ne s’agit pas juste d’en « choisir deux ».
« En fait, le père du théorème Dr Eric Brewer, a lui-même confirmé que le coté ‘deux sur trois’ de théorème est trompeur. Premièrement, du fait que les pannes soient rares, il y a peu de chances de devoir choisir entre C et A quand le système n’a pas de problème.
Deuxièmement le choix entre C et A peut se produire plusieurs fois dans le système à un niveau de granularité plus faible. Non seulement ces sous-systèmes peuvent faire des choix différents, mais ce choix peut changer en fonction du type d’opération, d’utilisateur ou même de donnée. Au final les trois propriétés ne se résument pas à un choix binaire. La disponibilité par exemple peut être traduite de zéro à cent pourcent, mais il y a aussi beaucoup de niveau de consistance et de pannes »
26
Nous savons en effet depuis le NoSQL que cette affirmation est vraie à cause de l’adoption du principe BASE, ou encore à cause des différentes implémentations comme Cassandra. Il est donc clair qu’il est possible d’avoir des systèmes
tolérants aux pannes, disponibles et bénéficiant d’un certain degré de consistance.
La tolérance aux pannes n’est en revanche pas quelque chose d’aussi ajustable. D’ailleurs la preuve du théorème de CAP se base sur une supposition à son sujet. Coda Hale, un ingénieur à Yammer l’explique : « La tolérance aux pannes est obligatoires dans un environnement distribué. On ne peut pas s’en passer. ».
En effet, comme expliqué dans la partie sur le théorème de CAP, nous avons vu que le design CA n’était pas cohérent. La personne ayant développé cela est un professeur à Yale qui se nomme Daniel Abadi.
Tout comme le fait que les systèmes puissent retenir un certain degré de concistance, Abadi signale qu’il est également possible de ne retenir qu’un certain degré de disponibilité.La disponibilité n’est en fait sacrifiée qu’en cas de panne, selon ses dires. Par conséquent, il en conclu que la consistance et et la disponibilité sont asymétriques et introduit la notion de latence pour rééquilibrer l’équation. Étant donné que le problème consistance contre disponibilité n’est pas présent partout (quand il n’y a pas de panne, il n’y a pas de choix à faire), il note qu’il est plus judicieux de choisir entre la latence et la consistance, qui lui l’est.
En se référant au wiki de Cassandra on comprend tout à fait où il veut en venir :
« Le théorème de CAP stipule que l’on doit choisir entre consistance, disponibilité et tolérance aux pannes. On ne peut pas avoir les trois à la fois et bénéficier d’une bonne latence. Cassandra mets en avant la disponibilité et la tolérance aux pannes (AP). Les compromis entre consistance et latence peuvent être ajustés avec Cassandra. Vous pouvez avoir une forte consistance avec Cassandra (contre une augmentation de la latence ».
Cela confirme donc la démonstration d’Abadi. Le CEO de ScaleDB, Mike Hogan, a également publié un article sur le sujet en définissant le CAP event horizon : « La situation à laquelle la latence pour un cluster excède ce qui est acceptable et que par conséquent il est temps de faire des concessions. »
Pour reprendre son exemple : imaginez une base avec réplication master/slave.
Ajoutez dix slaves et cela ralenti le système. Ajoutez en 90 et il y a un problème de réplication synchrone. En d’autres termes, la consistance à petite échelle n’est pas un problème, mais à grande échelle cela devient impossible car la latence devient inacceptable. Maintenant si vous assignez les slaves seulement en lecture et le master en lecture/écriture vous pourrez utiliser ce système avec réplication synchrone sans atteindre l’event horizon. Cependant si le master subit une panne, tout le système s’écroule. Cela devient donc un problème de disponibilité. Avec une réplication master/master, dès le
FIGURE 8 DANIEL ABADI
27
premier master, on atteint l’event horizon. Il revient ensuite au système de proposer des solutions pour régler les problèmes du CAP, tout en pensant à maintenir une latence faible.
Un exemple plus concret avec le CEO de Citrusleaf qui prétend que son produit bénéficie d’une forte consistance en réduisant l’importance de la disponibilité en cas de panne : « Pendant la panne, Citrusleaf paraitra moins disponible à cause de la latence, jusqu’à ce que la reconfiguration du système se fasse. Pendant cette période, les transactions sont toujours présentes mais mises en file et routées vers d’autres nodes. En théorie le cluster sera donc moins disponible.».
Au final, comme pour la base NoSQL et ACID Citrusleaf, les bases de données NewSQL ne sont pas conçues pour échapper au CAP event horizon en étant tout autant disponibles qu’éventuellement consistante. Elles sont juste conçues pour retarder le plus possible le CAP event horizon. Pour se faire elles possèdent souvent des architectures qui, dans le cas d’une panne, sont très consistantes et bénéficie d’un certain degré de disponibilité.
La relève ?
. VOLTDB
Déjà mentionné auparavant VoltDB, le bébé de Michael Stonebreaker, est une base de données relationnelle en mémoire. Elle est née des travaux académiques réalisés sur le moteur de traitement de transaction H-Store. H-Store a été commercialisé sous le nom de VoltDB pour la première fois en 2010. Trois ans après elle revient avec sa version 3 où elle pousse les performances encore plus loin.
John Hugg, ingénieur chez VoltDB explique clairement le but de la base de données : supporter des applications OLTP dans un contexte de BigData. Inutile de s’intéresser à VoltDB si votre système n’est pas concerné, précise-t-il. Tout ce qui importe c’est donc la vitesse à grande échelle avec des propriétés ACID complètes. Quelques faits notables sur l’architecture :
28
Stockage des données en RAM : Les inconvénients du disque disparaissent comme le buffer pool ou l’attente de fin de blocages du disque
Réplication : Persistance garantie car les données résident sur plusieurs mémoires principales.
Transactions via procédures stockées en Java : L’accès aux données se fait toujours via SQL, mais exécuté depuis une procédure stockée avec un système commit/rollback.
VoltDB se différencie des autres bases de données car ses architectes ont retiré les quatre sources principales d’overhead d’une base : logging (19%), latching18 (19%), locking (17%), B-tree et opérations sur la gestion du buffer (35%). Avec cette approche, VoltDB peut se vanter d’être rapide, sans pour autant perdre les propriétés ACID. A quel point ?
Les représentants de la base prétende être 100 fois plus rapide que MySQL, jusqu’à 13 fois plus rapide que Cassandra et 45 fois plus qu’Oracle. Le tout avec un scaling quasi linéaire jusqu’à 50 nodes, c'est-à-dire que la latence n’augmente pas dramatiquement jusqu’
50 nodes (avec replication).
Bien sûr ces comparaisons ne sont pas très pertinentes, notamment celle avec Cassandra car elle a été conçue pour stocker des petabytes de données réparties sur des centaines de nodes pouvant individuellement être ajouté à chaud. Techniquement il n’y a pas de comparaison. On peut cependant supposer que le but de ce benchmark est essentiellement de prouver que SQL et ACID ne sont pas synonymes de lenteur.
VoltDB reste donc une technologie à surveiller même s’il est facile d’occulter le fait qu’elle ne supporte qu’une partie de SQL ’99, ce qui signifie par exemple pas de ALTER ou DROP. En effet modifier la structure à la volée n’est pas performant et cela va à l’encontre de la philosophie du produit. Par conséquent si on veut modifier la structure du modèle, il faut redémarrer tout le système. Personne n’échappe au théorème CAP.
18 Mécanismes des lock système bas niveau qui coordonne l’accès concurrent à des données partagées
29
AEROSPIKE
Anciennement Citrusleaf, Aerospike est une base de données orientée clé-valeur conçu pour le temps réel. Elle a également racheté la base NewSQL AlchemyDB qui elle prend parti d’amener le relationnel au NoSQL et non l’inverse. Bien qu’Aerospike se revendique NoSQL (et à raison), on peut tout de même dénoter certains aspects intéressants.
L’approche hybride tout en un adoptée est assez novatrice et pour cause :
Données stockées sur SSD de façon optimisé
Index en mémoire
Resharding et repartition des données automatiques
Scaling horizontal linéaire
Entièrement ACID si besoin
99% des transactions en dessous de 1ms
Load balancing
Son coté clé-valeur rend donc Aerospike hautement scalable en plus de bénéficier de bonne performance grâce à son architecture, tout en étant ACID compliant. Le directeur des ventes en ingénierie à Aerospike, Young Paik, a cependant admis certains faits :
Ce n’est pas un substitut à Hadoop. Si on veut analyser 100TB de donner, Aerospike n’est pas un bon choix.
Avoir des enregistrements de plus e 1MB n’est pas une bonne idée.
30
NUODB
NuoDB (par la startup du même nom) a été créé en 2008 en tant que NimbusDB, nom qui fut changé en 2011. NuoDB vend donc des solutions de bases relationnelles clé- valeur via le cloud. Ces bases totalement NewSQL respectent donc les propriétés ACID et bénéficie de l’ensemble de SQL ’99. NuoDB utilise une architecture distribuée objet dans le cloud. Ces objets sont appelés « atom » (atome en français) et possèdent des données et métadonnées les décrivant.
Chaque atom communique donc les uns avec les autres en P2P de manière asynchrone via des messages. NuoDB justifie ce choix en invoquant le fait que les bases de données relationnelles classiques soient difficiles à scale car elles étaient justement synchrones, se reposant sur un système de lock avec un node master qui s’occupait de gérer les transactions. Selon eux, NuoDB est donc capable d’effectuer tout ce qu’une base relationnelle est capable de faire (comme créer, supprimer ou modifier un enregistrement).
Quand un Atom est modifié dans NuoDB, il envoie donc un message à toutes ses copies, répliquant ainsi de manière transactionnelle les changements via un système de file de messages asynchrones.
Autres particularités :
Scalable de façon élastique : Scaling horizontal ou vertical à la volée. L’ajout d’un node augmente systématiquement les performances.
Redondance : L’architecture distribuée continuera de fonctionner même s’il y a plusieurs pannes.
Auto réplication : Un node ajouté est automatiquement répliqué.
Sécurisé : Les messages entre atom sont sécurisés et encryptés par défaut.
Intégration : Support de Java EE, .NET, node.js, Python et autres en plus de fournir des supports ORM tels Hibernate.
NuoDB se présente plus ou moins comme un alien de la persistance et joue beaucoup sur ses points forts. Ils sont cependant tout à fait conscient du théorème CAP et, étant relativement jeune, ils n’ont pas encore dévoilé tous les tenants et aboutissants de leur architecture. En effet la plupart des documents réellement intéressants ne sont pas
31
encore disponibles. Toutefois c’est une approche nouvelle avec beaucoup de promesses et à surveiller de près.
Conclusion
A la lumière des chiffres avancés dans l’état de l’art, nous avons vu que le milieu des bases de données NoSQL est tout à fait présent sur le marché. Cependant de nouveaux concurrents sont récemment arrivés : ces nouveaux challengers NewSQL utilisent une approche qui leur est propre. NoSQL quant à lui continue son chemin. Nous avons aussi vu des technologies hybrides également prometteuses. Qu’en est-il alors du futur de NoSQL ? Va-t-il continuer de creuser son côté BigData et stockage de masse ou essaiera-t-il de se mélanger aux autres mouvements ?
Résultats et discussions
Fin 2013, Michael Stonebreaker est passé sur un podcast audio appelé « Structure Show ». Il fut invité afin de partager son avis concernant l’état du marché des bases de données, NoSQL inclus ainsi qu’Oracle et l’installation MySQL de Facebook. Sa prédiction fut la suivante :
« Il y aura trois, quatre, cinq, voire peut-être six catégories de base de données architecturées très différemment, et pour chaque catégorie on verra deux à trois éditeurs émerger. Et je pense que le cœur, autrement dit les bases de données anciennes générations, vont petit à petit disparaitre. Le tout se fera peut-être sur une dizaine d’années. »
Concernant le NoSQL il ajoute :
« Ma prédiction est que le NoSQL va finir par dire Not Yet SQL […] Cassandra et Mongo ont tous les deux annoncé ce qui ressemble, à moins de pinailler, à un langage haut niveau qui est quasiment du SQL. »
Il affirme aussi que le NoSQL va se rediriger vers ACID et que c’est peut-être même déjà en cours :
« Je pense que le plus gros partisan du non-ACID est historiquement un type appelé Jeff Dean chez Google, qui est essentiellement responsable de tous leurs choix concernant les bases de données. Et il a récemment développé un système appelé Spanner… Il s’agit d’une solution entièrement ACID, et puisque Google retourne vers ACID, je pense que le marché NoSQL va s’éloigner de la consistance éventuelle. »
