L`AVENIR DU NoSQL

L’AVENIR DU NoSQL
Quel avenir pour le NoSQL ?
Meyer Léonard
2014
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
1
Le point de vue du la communauté NoSQL ........................................................... 34
Avis des professionnels ......................................................................................... 35
Conclusion ................................................................................................................ 46
Bibliographie.............................................................................................................. 47
2
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.
3
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.
FIGURE 1 SCALING D’UNE BASE RELATIONNELLE
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
4
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.
5
En construisant sur leur travail, des vendeurs NoSQL ont commencé à émerger en
proposant des solutions dédiées à l’entreprise.
FIGURE 2 SCALING D’UNE BASE NOSQL
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.
6
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 MapReduce 1,
réplication, tolérance aux pannes, consistance… Pour des performances en
écriture encore plus puissante, il convient de se tourner vers les systèmes inmemory.
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
7
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
dépendant et dont une panne entraîne l'arrêt complet du système.
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
8
Donnée non concernée par un processus métier
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 conjecture 4 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 :



FIGURE 3 ERIC BREWER
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
9
Une conjecture est une assertion pour laquelle on ne connaît pas encore de démonstration, mais
que l'on soupçonne d'être vraie, en l'absence de contre-exemple.
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.».
FIGURE 4 GUIDE VISUEL AU NOSQL
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.
10
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.
11
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)
12
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,
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
13
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
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.
Le data mining est un processus qui permet d’extraire des informations commercialement
pertinentes à partir d’une grande masse d’informations.
5
14
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).
15
CouchDB : Développé en Erlang. Protocol http. Réplication master/master. Licence
Apache.
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.
16
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.
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
17
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
Théorie visant à savoir trouver et exploiter les propriétés des différents types de graphes.
18
9
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
mining 11 .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.
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.
10
19
É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 :
FIGURE 5 EXPLOSION DES RECHERCHES A PARTIR DE 2009
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).
20
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.
Analysons maintenant ces tendances issues des statistiques du site agrégateur
d’emplois d’envergure mondiale Indeed.com ;
FIGURE 6 EXPLOSION DES OFFRES D’EMPLOIS DEPUIS 2010
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
21
PaaS, de l'anglais Platform as a Service, est l'un des types de Cloud computing, principalement
destiné aux entreprises.
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
22
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.
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.
23

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”, FIGURE 7 MICHAEL STONEBREAKER
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 OLTP 17 : “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
24
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
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 »
25
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.
FIGURE 8 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. »
26
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
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 :
27



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
28
partagées
AEROSPIKE
Anciennement Citrusleaf, Aerospike est une
conçu pour le temps réel. Elle a également racheté
prend parti d’amener le relationnel au NoSQL et
revendique NoSQL (et à raison), on peut
aspects intéressants.
base de données orientée clé-valeur
la base NewSQL AlchemyDB qui elle
non l’inverse. Bien qu’Aerospike se
tout de même dénoter certains
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.
29
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.
30
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
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. »
31
Stonebreaker continue sur la situation d’Oracle :
« L’autre point que je trouve vraiment fascinant et qui n’a pas vraiment été remarqué,
c’est que SAP est maintenant dans le business des bases de données et que… Les clients
de SAP sont les plus gros clients d’Oracle à l’heure actuelle. […] Je m’attends à ce que SAP
soit plein d’arguments pour que leurs clients passent d’Oracle à SAP HANA. »
En effet les systèmes orientés OLAP19 tels Oracle ou HANA constituent le tiers du
marché, et si Oracle en venait à perdre cette part, sa position de leader du marché pourrait
être remis en cause. Concernant le reste, on est en droit de se demander si le seul fait que
Google fasse machine arrière suffise pour que NoSQL en fasse autant… Après tout, qu’estce que Google Spanner au juste ?
Google Spanner
Spanner est une base de données scalable
globalement distribué construite et déployée par Google.
Au plus haut niveau d’abstraction, il s’agit d’une base qui
répartit les données sur plusieurs groupes de machines
à état Paxos 20 dans des datacenters partout dans le
monde. La réplication est utilisée pour une disponibilité
globale et les clients bénéficient d’un failover
automatique entre les répliques. Spanner redistribue
automatiquement les données (auto-sharding) entre
machines dès que la quantité de données ou de
serveurs changent. De plus il migre automatiquement les données afin d’équilibrer la charge
ou répondre aux problèmes techniques.
La base de Google a été conçu pour gérer jusqu’à plusieurs millions de machines
réparties sur des centaines de datacenters et elle peut supporter jusqu’à plusieurs trillions
de lignes. Des applications peuvent utiliser Spanner pour assurer une haute disponibilité
même face à des catastrophes naturelles car la réplication peut même se faire sur plusieurs
continents.
Comme énoncé par Stonebreaker, l’esprit derrière Spanner porte le nom de Jeff
Dean. Ce dernier énonce la raison du revirement de Google vers NewSQL dans le
whitepaper de Spanner :
« Nous pensons qu’il est mieux que les développeurs soient confrontés à des
problèmes liés à une surutilisation des transactions lors d’une monté en charge, plutôt que
devoir réussir à trouver des solutions logicielles pour pallier à l’absence de transactions ».
19
32
Type d'application informatique orienté vers l'analyse sur-le-champ d'informations selon plusieurs
axes, dans le but d'obtenir des rapports de synthèse tels que ceux utilisés en analyse financière. Les
applications de type OLAP sont couramment utilisées en informatique décisionnelle, dans le but
d'aider la direction à avoir une vue transversale de l'activité d'une entreprise.
20 Paxos est une famille de protocole pour résoudre le consensus dans un réseau de nœuds
faillibles. L'approche de la machine à état est une technique pour convertir un algorithme en un
algorithme résistant aux pannes et distribué.
Cela peut sembler ironique puisque Google BigTable a contribué à la révolution
NoSQL… On peut constater que la plupart des critiques à l’égard du NoSQL se sont
avérées être un problème pour Google aussi. Seulement, Google a résolu le problème
comme eux seuls ont l’habitude de le faire : un savant mélange d’une théorie et technologie
avancées. Pour les utilisateurs, il en résulte de véritables transactions, un modèle de
données stricte et un langage de requêtes que beaucoup désiraient, le tout hautement
scalable et disponible.
L’ingéniosité de la plateforme repose dans ce que Google appelle l’API TrueTime.
Concrètement cette API utilise des antennes GPS, des satellites et des horloges atomiques
afin de garantir une synchronisation précise au sein du réseau Google.
Pour bien comprendre l’intérêt de TrueTime, il convient de bien comprendre les
limites des bases de données actuelles. De nos jours il existe beaucoup de bases pouvant
stocker des données sur des milliers de serveurs… La plupart furent inspirées par le papier
sur BigTable ou des technologies similaire comme Dynamo de Amazon. Ces systèmes
fonctionnent bien, mais ils ne sont pas conçus pour gérer des données entre plusieurs data
center. En tout cas pas de manière à ce que les données restent en permanence
consistantes (au sens du théorème CAP).
Selon Andy Gross, l’architecte principal de Riak, une base de données orientée clévaleur inspirée de Dynamo, le problème réside dans le fait que les serveurs doivent
communiquer en permanence via le réseau. Cela permet d’assurer qu’ils puissent stocker et
retrouver facilement des données, seulement cela ralenti fortement le système si on
disperse ces serveurs sur plusieurs emplacements géographiques bien distincts. On en
revient donc au problème de latence lié au théorème CAP.
Max Shireson le président de MongoDb Inc., dont la base de données MongoDb suit
les traces de BigTable, présente le problème sous un autre angle :
« Imaginez-vous en train d’utiliser en web service servant à transférer de l’argent
entre deux banques : l’une en Europe et l’autre en Asie. Si vous êtes en Europe, vous
pourriez voir la complétion du transfert, mais à cause de la latence, quelqu’un en Asie ne le
pourrait peut-être pas. […] Autrement dit le service ne marche pas tout le temps comme il
est supposé le faire puisque tout le monde n’a pas la même vue sur le données. Par
conséquent les données ne sont pas consistantes. »
Si vous imaginez un service utilisé par des millions de personnes, vous pouvez
concevoir l’étendue du problème. En effet, lorsqu’énormément de personnes essaient
d’accéder à un système globalement distribué et qu’il y a une certaine latence dans les
communications, cela devient très difficile de synchroniser le tout.
Bien entendu, Spanner est une technologie propriétaire et tout le monde n’a pas le
moyen de se payer des horloges atomiques. Cependant, Andy Gross précise que Google a
souvent tendance à être le fer de lance de l’open source et que le simple fait de voir
comment procède le géant de l’informatique peut être très intéressant.
33
Le dernier point à soulever reste la situation de Spanner par rapport au théorème
CAP. Sur le papier, la solution de Google semble en effet posséder les trois axes du
théorème. En pratique ce n’est pas le cas… Selon Jeff Darcy, un ingénieur de chez RedHat,
Spanner est en fait un système CP :
« Les span-serveurs forme des groupes Paxos, qui peuvent s’étendre sur plusieurs
datacenters. Chaque groupe a un leader qui maintient une table de verrous tout en tenant
un rôle spécial dans la gestion de la concurrence. […] Une transaction read-write utilise une
gestion de la concurrence pessimiste, ce qui requiert la réponse du leader. C’est un aspect
commun des systèmes CP. […] Basé sur tout ça, mon interprétation est qu’en présence
d’un problème, la possibilité d’écrire sera sacrifiée au profit de la consistance. »
Le point de vue du la communauté NoSQL
Vers fin Avril 2014, la conférence NoSQL Matters s’est déroulée en Allemagne à
Cologne. Divers sujet y ont été abordés, y compris le futur du NoSQL. Pendant 45 minutes,
Ted Dunning s’est attardé sur Big Data et la réaction de l’industrie par rapport aux besoins
futurs.
Pour commencer, il présente ce graphique :
On constate immédiatement un buzz autour de Hadoop depuis 2009, et selon
Dunning c’est un indicateur de la direction que NoSQL doit prendre pour avoir du succès. Il
signale aussi qu’ayant été conçu à l’origine pour du batch processing 21, Hadoop devra se
diriger vers des requêtes en temps réel. Concrètement il s’agit de se consacrer davantage
aux problèmes opérationnels. Pour y parvenir il faudrait que NoSQL soit prêt à évoluer en
une plateforme complète via l’incorporation de ces différents points :
21
34
Enchaînement automatique d'une suite de commandes (processus) sur un ordinateur sans
intervention d'un opérateur.






SQL : Langage standard et supporté par beaucoup de choses. Un support partiel
n’est pas suffisant.
Support des transactions : Possible avec la bonne implémentation. Dunning
évoque également Spanner pour appuyer ce point.
Meilleures performances sur les scans : Des scans lignes par lignes sont bien trop
lents, il faudrait envisager l’orienté colonnes.
Stockage de fichiers : Utile pour les images par exemple.
Snapshots/miroirs : Contrôle de version pour la base.
Agrégats incrémentaux : Faire des opérations d’agrégats au fur et à mesure que
les données arrivent afin d’améliorer les performances lorsque ces opérations seront
demandées.
Du point de vue du co-créateur de Hadoop, Doug Cutting, l’industrie va continuer de
se baser sur les travaux de Google pour progresser. Selon lui Spanner ouvre des
possibilités pour des plateformes open source distribuées comme Hadoop. En effet, Hadoop
permet de traiter des données sur de larges clusters en parallèle. Actuellement la
plateforme est surtout utilisée pour autre chose que de l’OLTP (qui constitue le moteur des
entreprises comme les e-commerces ou CRM22). Spanner démontre qu’il est possible que
de grandes entreprises puissent s’intéresser à Hadoop afin de faire de l’OLTP globalement
distribué. Cutting précise sa pensée :
« Dans la plupart des cas, les gens sont satisfaits avec leur solutions relationnelles
liées aux problèmes OLTP, et il n’y a généralement pas besoin de se diriger vers Hadoop.
[…] Cependant, lorsqu’une entreprise grandit il se peut que le changement opère. Je pense
que le reste d’entre nous vont en arriver là dans les prochaines années… »
Lorsqu’on lui parle du futur de Hadoop, voici sa réponse :
« Tout bouge très vite : je pense que la pratique la plus répandue sera de voir
Hadoop comme un kernel, à la manière de Linux. Cela deviendra de plus en plus le centre
d’un vaste nombre d’applications. »
Avis des professionnels
Jusque-là nous avons surtout obtenu l’avis des gourous et des éditeurs des
technologies concernées, mais qu’en est-il des professionnels du milieu ? Autrement dit, les
gens qui sont en en première ligne et ce qu’ils ont à dire sur le sujet. En outre, j’ai décidé de
réaliser une interview avec un de ces professionnels.
22
35
Les CRM (Customer relationship management) sont des systèmes qui permettant de gérer les
interactions avec des clients.
Bonjour Stéphane, est-ce que tu peux te présenter ?
Je suis Stéphane Landelle, le directeur technique d’EBusiness
Information. Je travaille on va dire… Dans le monde Java au sens
large depuis quasiment une quinzaine d’années. Chez EBusiness je
m’occupe de tout ce qui est animation technique, un peu
d’encadrement de stagiaires, et puis j’anime également certains de
nos projets open source. Depuis quelque temps je développe
beaucoup en Scala.
Connais-tu NoSQL et as-tu déjà croisé ces technologies en entreprise ?
Franchement ça commence juste… De manière générale la France est relativement
frileuse sur le plan technique et attend souvent de voir les technos se stabiliser et guette
notamment ce qui peut se passer sur le marché Américain ou Anglo-saxons. Donc c’est des
technos qu’on voit de plus en plus apparaitre, mais c’est assez récent. Et puis tout le monde
n’a pas besoin de gérer de très grosses volumétries donc tout le monde n’a pas besoin de
Big Data
On commence à voir apparaitre depuis une ou deux années des projets avec du Big
Data, avec notamment d’autres rosters comme du MongoDB ou des gens qui se servent de
Redis, ou encore ElasticSearch qui commence à être de plus en plus répandu.
As-tu déjà utilisé des technologies NoSQL ?
Je monte quelques petits POC. Je ne peux pas tester toutes les technos que je
regarde de près ou de loin, donc voilà… J’ai déjà joué avec MongoDB, un petit peu avec
Cassandra, un petit peu avec ElasticSearch et Neo4J… Ce n’est pas des solutions que j’ai
mis en production, moi personnellement, mais c’est des choses qu’on est en train de mettre
en place car les besoins commencent à apparaitre chez nos clients.
36
As-tu déjà entendu le terme NewSQL ?
J’ai connu les différentes déclinaisons de la signification que peut avoir NoSQL, la
dernière en date étant beaucoup « No, SQL ! » , mais NewSQL non.
Que prédis-tu concernant le futur des bases relationnelles et du NoSQL ?
Il y a une grande différence entre ce qu’on peut observer sur la blogosphère
technique, ce qu’on peut observer dans le marketing des différents vendeurs de base de
données, qu’elles soient relationnelles ou NoSQL, par rapport à ce qui est réellement utilisé
chez les clients sur des projets.
Typiquement, il faut pas se leurrer, les bases de données relationnelles occupent un
très grosse part du marché et vont continuer à l’occuper, ne serait-ce que parce que les
SGBDR continuent également à évoluer. Par exemple que ce soit Oracle ou PostgreSQL,
elles sont maintenant capables de stocker et manipuler du JSON, et SQLite progresse
beaucoup également. Donc voilà les SGBDR sont loin d’être morts et ce qu’il faut voir aussi
c’est que pendant longtemps on a confondu la complexité des SGBDR avec la complexité
des ORMs qu’on construisait par-dessus… Et depuis quelques mois, dans les choses
tendances, ce qu’on voit apparaitre c’est de revenir à des choses plus proches du métal et
recommencer à convenablement maitriser sa base de données relationnelles. Arrêter de
vouloir utiliser des ORMs d’une complexité dingue, comme notamment dans le monde Java
Hibernate/JPA, et puis revenir à des choses plus proches du natif à savoir du SQL, tout en
exploitant convenablement les possibilités des bases de données relationnelles. De plus
que ce soit pour les SGBDR ou NoSQL, il y a besoin d’une vraie expertise pour leur
administration, ce ne sont pas des choses qui s’improvisent.
37
Sur les bases de données NoSQL, on se met à voir un peu plus de recul et
d’intelligence par rapport à leur utilisation. La première approche des gens qui
commercialisait NoSQL c’était de dire « jeter vos bases de données relationnelles » et ça a
causé beaucoup d’échecs donc le discours marketing à maintenant évolué plus dans le
sens de « Not Only SQL », donc trouvez la bonne solution NoSQL adaptée à votre cas
d’utilisation parce que voilà NoSQL c’est un fourre-tout. Vous pouvez avoir besoin de
documents et à ce moment-là MongoDB peut être une solution. Vous pouvez avoir besoin
de stocker uniquement de la clé valeur et à ce moment-là Redis peut être intéressant. Vous
avez besoin de stocker des choses qui sont purement relationnelle comme du graphe,
Neo4J peut être une solution pour vous. Vous n’avez pas les mêmes besoins selon le fait
que vous vouliez gérer des volumes monstrueux ou pas etc… Bref il faut trouver la solution
de stockage adaptée et les différentes technologies NoSQL peuvent être une réponse
pertinente. Mais voilà il n’y a pas de « silver bullet », il faut trouver la bonne solution adaptée
à son besoin.
_______________________
Merci à Stéphane pour sa participation. A travers son interview on peut constater
qu’effectivement la France est un peu un retard par rapport au reste du monde mais que le
NoSQL est tout de même de plus en plus présent dans les entreprises. D’un autre coté les
bases de données relationnelles sont encore là pour longtemps.
Afin de recueillir d’autres avis, j’ai créé un questionnaire en ligne qui fut exposé sur la
toile par mes soins. Il s’adressait exclusivement aux développeurs ou DBA et fut exposé sur
developpez.com ainsi que sur différents groupes d’utilisateurs LinkedIn, Google et Viadeo
comme ceux de MySQL, PostgreSQL, SQL Server, Oracle, MongoDB et Hadoop. Au total,
une cinquantaine d’avis ont été récoltés. Voici le format du questionnaire :
Connaissez-vous le NoSQL ? *
Oui, et j'ai contribué à la mise en place d'une solution NoSQL dans le cadre d'un projet professionnel
Oui, mais seulement le coté théorique
Non
Le reste des questions se modifient en fonction de la réponse. En sachant que la
dernière complète le questionnaire instantanément en classifiant la personne comme
étrangère au NoSQL. Commençons par les réponses engendrées par la première réponse :
Dans combien de projets avez-vous mis en place des solutions NoSQL ?*
1
2
Entre 2 et 5
Plus de 5
En moyenne, de quelle taille étaient les entreprises bénéficiaires de la solution ?*
TPE (moins 10 salariés)
PE (entre 10 et 49 salariés)
ME (entre 50 et 249 salariés)
GE (plus de 250 salariés)
Grands groupes (plus de 5000 salariés)
38
De quel(s) type(s) étaient les solutions NoSQL utilisées pour vos projets ?*
Orientée colonnes (Cassandra, HBase...)
Orientée clé-valeur (Redis, Riak...)
Orientée documents (MongoDB, Couchbase, ElasticSearch...)
Orientée graphes (Neo4J, Titan...)
Pourquoi avoir utilisé une technologie NoSQL ?
Pour de meilleures performances
Les changements sur le modèle de données étaient trop fréquents
Car une base relationnelle n'était pas nécessaire
Autre :
En moyenne et sur une échelle de 1 à 10, quel était le niveau de satisfaction après la livraison ?
Selon vous, dans les prochaines années, les technologies NoSQL sont vouées à :*
O
Mourir
Remplacer les bases relationnelles
Cohabiter avec les bases relationnelles
Autre :
Avez-vous déjà eu des problèmes lors de l'utilisation ou mise en place d'une solution NoSQL ? Si oui,
décrivez-les.
Ensuite les réponses affichées avec la deuxième réponse :
Quel(s) type(s) de technologie NoSQL connaissez-vous ?
Orientée colonnes (Cassandra, HBase...)
Orientée clé-valeur (Redis, Riak...)
Orientée documents (MongoDB, Couchbase, ElasticSearch...)
Orientée graphes (Neo4J, Titan...)
Avez-vous déjà rencontré des technologies NoSQL en entreprise ?*
Oui
Non
39
Selon vous, serez-vous amené à utiliser ces technologies dans le futur ?*
Oui
Non
Je ne sais pas
Voici maintenant les résultats du sondage :
Connaissance du NoSQL
Oui, et j'ai contribué à la mise
en place d'une solution
NoSQL dans le cadre d'un
projet professionnel
Oui, mais seulement le coté
théorique
45%
55%
Non
Parmi les sondés, nous avons donc 45% des personnes qui connaissent le coté
théorique du NoSQL et 55% qui ont déjà contribué à la mise en place d’une solution dans
un cadre professionnel. Le point le plus notable reste que tout le monde connait NoSQL car
je n’ai récolté aucun « Non » pour cette question.
Nombre de projets moyen
15%
30%
1
2
Entre 2 et 5
Plus de 5
37%
18%
40
Parmi ceux qui ont déjà mis en place des solutions NoSQL, 30% d’entre eux l’ont fait
une seule fois, 18% d’entre eux l’ont fait deux fois, 37% d’entre eux l’ont fait entre deux et
cinq fois, et 15% d’entre eux l’ont fait plus de cinq fois. La distribution reste relativement
équilibrée, ce qui témoigne du niveau de différence technique entre les professionnels ayant
répondu.
Taille moyenne des entreprises
bénéficiaires
TPE (moins 10 salariés)
15%
26%
PE (entre 10 et 49
salariés)
ME (entre 50 et 249
salariés)
11%
37%
11%
GE (plus de 250
salariés)
Grands groupes (plus
de 5000 salariés)
Il fut ensuite reporté que les entreprises bénéficiaires de telles solutions étaient
majoritairement des petites entreprises, suivies par les grands groupes. Comme quoi ce
sont les besoins métiers qui comptent et non pas la taille de l’entreprise.
Type de NoSQL majoritairement
utilisé
Orientée colonnes
(Cassandra, HBase...)
2%
24%
55%
19%
Orientée clé-valeur (Redis,
Riak...)
Orientée documents
(MongoDB, Couchbase,
ElasticSearch...)
Orientée graphes (Neo4J,
Titan...)
41
Le groupe le plus utilisé reste clairement l’orientée documents, probablement à cause
du fait qu’il soit simple à aborder pour n’importe quelle personne connaissant le JSON. D’un
autre coté les orientées colonnes sont au coude à coude avec les clé-valeurs. Les
orientées graphes sont très minoritaires et ce n’est pas une surprise puisqu’elles sont
principalement réservées à des applications très spécifiques.
Raisons de l'utilisation du
NoSQL
4%
24%
Pour de meilleures
performances
Les changements sur le
modèle de données
étaient trop fréquents
39%
Car une base
relationnelle n'était pas
nécessaire
33%
Autre
Les raisons qui poussent à l’utilisation d’une technologie NoSQL sont assez
équilibrées, avec l’idée de la performance toujours en tête. On constate aussi que dans 24%
des cas, une base relationnelle n’était pas nécessaire. En effet, inutile de s’embêter avec ça
si on se contente de sauvegarder le contenu d’un panier en ligne ou de faire un cache.clévaleur par exemple.
Moyenne de satisfaction après
livraison (sur 10)
10 4
9 8% 8% 6
8%
11%
7
4%
8
61%
42
A partir de ce graphique, on peut voir que 84% des sondés sont satisfaits (score
supérieur à sept) après leur livraison. Les principales remarques négatives vis-à-vis du
NoSQL en général fut la courbe d’apprentissage ainsi que l’immaturité et le manque de
sécurité de certaines technologies :
« Chaque base a ses spécificités et une stratégie de modélisation différente. Il y a un travail
très important d'appropriation des technos. Tout le monde aujourd'hui est formaté monobase, mono
domaine et relationnelle. C'est très compliqué de sortir des réflexes traditionnels »
« J'ai utilisé plusieurs type de bases dont cassandra v1. Les concepts étaient vraiment
différents, un gros mur à franchir pour arriver à modeliser/utiliser correctement cette base. »
Futur du NoSQL
4%
Mourir
Remplacer les bases
relationnelles
Cohabiter avec les
bases relationnelles
96%
Toujours parmi ceux qui ont déjà utilisé du NoSQL dans un contexte professionnel, il
en ressort que 96% des sondés pensent que le NoSQL va finir par cohabiter avec le relationnel et
seulement 4% pensent qu’il va le supplanter. Le point le plus notable étant qu’aucun des sondés ne
pensent que le NoSQL va mourir. Il y a donc réellement un besoin par rapport aux technologies
traditionnelles.
Passons maintenant aux résultats de ceux qui n’ont jamais utilisé une technologie NoSQL :
Type de NoSQL majoritairement
connu
Orientée colonnes
(Cassandra, HBase...)
10%
25%
48%
17%
Orientée clé-valeur
(Redis, Riak...)
Orientée documents
(MongoDB, Couchbase,
ElasticSearch...)
Orientée graphes
(Neo4J, Titan...)
43
La distribution par rapport à ceux qui ont déjà utilisé du NoSQL n’est pas
bouleversée. On constate juste la réduction de l’orientée documents et la haut de l’orientée
graphes.
Présence du NoSQL en
entreprise
36%
Oui
Non
64%
Parmi ceux qui n’ont jamais utilisé de NoSQL, 36% déclarent en avoir déjà rencontré
en entreprise. Cela reste un chiffre cohérent car les bases relationnelles sont et resteront
leaders pour un bon moment.
Utilisation future du NoSQL
18%
Oui
5%
Non
Je ne sais pas
77%
77% estiment également qu’ils utiliseront une technologie NoSQL dans le futur, ce
qui pousse de nouveau à croire que le NoSQL est parti pour rester.
Bien entendu, toutes ces statistiques ne concernant que la France, c’est pourquoi
nous allons examiner les résultats du récent sondage de RebelLabs sur plus de 2000
développeurs Java. Il est cependant import de noter que ces résultats viennent des lecteurs
de RebelLabs et ne sont pas forcément représentatif de toute la communauté Java.
44
Selon RebelLabs, 53% de ses lecteurs n’utilisent que des technologies intimement
liées au SQL. D’un autre coté 39% disent avoir recours à la « persistance polyglotte ». Seul
4% des personnes interrogées n’utilisent que du NoSQL.
Impossible de comparer avec les résultats du questionnaire car les questions de
RebelLabs étaient davantage portées sur des technologies précises, contrairement aux
différentes catégories. Cependant on peut tout de même voir une certaine ressemblance au
niveau de la domination de l’orientée documents.
45
CONCLUSION
Afin de fournir une réponse quant au futur du NoSQL, il convient de repasser sur ce
que nous venons de voir :
 A la vue des différents sondages, le NoSQL fait désormais partie du paysage des
bases de données
 Le discours premier des vendeurs NoSQL a disparu et ils commencent à revenir
vers le SQL et l’ACID
 Tout le monde n’est pas au cœur de Big Data, et par conséquent les technologies
actuelles vont continuer à prospérer pour des besoins précis d’ici la nouvelle
génération.
 A travers l’apparition de Google Spanner, les leaders du marché NoSQL et
relationnel vont entrer dans une course concernant une solution de stockage
distribuée à grande échelle.
Ces constats sont en fait en accord avec les déclarations de Michael Stonebreaker.
Sur le long terme, les SGBDR et le NoSQL vont s’harmoniser avec le meilleur des deux
mondes, mais le changement ne se fera pas tout de suite car les besoins ne sont pas
encore là, à part pour les géants du web. Actuellement, les bases de données relationnelles
vont continuer à dominer le NoSQL sur des marchés plus traditionnels, et ce dernier sera
toujours utilisé pour des besoins précis. Par ailleurs, avec la reconnaissance du NoSQL
dans le milieu professionnel, on pourrait voir apparaitre de plus en plus d’architectures
basées sur de la persistance polyglotte.
46
BIBLIOGRAPHIE
Aslett Matthew How to to provide a strongly consistent distributed database and not
break CAP Theorem Too much information [Online] // The 451 Group. - 2011. - 2013. http://blogs.the451group.com/information_management/2011/12/14/newsql-cap-theoremand-latency-tolerance/.
Bailis Peter When is "ACID" ACID? Rarely. | Peter Bailis [Online] // Bailis. - Janvier
22, 2013. - 2013. - http://www.bailis.org/blog/when-is-acid-acid-rarely/.
Bojoly Marc OCTO talks ! => NewSQL [Online] // OCTO talks. - 2012. - 2013. http://blog.octo.com/newsql/.
Broecheler Matthias C* 2012: Titan - Big Graph Data With Cassandra. - Aurelius,
2012.
Bulkowski Brian Brian Bulkowski answer to How does CitrusLeaf handle the CAP
theorem? Is it strongly or eventually consitent? - Quora [Online] // Quora. - 2011. - 2013. http://www.quora.com/How-does-CitrusLeaf-handle-the-CAP-theorem-Is-it-strongly-oreventually-consitent/answer/Brian-Bulkowski.
Cade Metz Google Spans Entire Planet With GPS-Powered Database [Online] //
Wired. - http://www.wired.com/2012/09/google-spanner/all/.
Community [En ligne] // Stack Overflow. - 2012. - 2013. - http://stackoverflow.com.
Community Does Google Spanner comply with CAP theorem ? [Online] // Quora. http://www.quora.com/Distributed-Systems/Does-Google-Spanner-comply-with-CAPtheorem.
Community Théorème CAP - Wikipedia [Online] // Wikipedia. - 2010. - 2013. http://fr.wikipedia.org/wiki/Théorème_CAP.
Couchbase Couchbase Server: Distributed, Non-Relational Database | Couchbase
[Online] // Couchbase. - 2012. - 2013. - http://www.couchbase.com/couchbaseserver/overview.
Edlich Stefan Choose the "Right" Database and NewSQL: NoSQL Under Attack
[Conference]. - Copenhagen : Goto conference, 2012.
Edlich Stefan NOSQL Databases [En ligne]. - 2013. - 2013. - http://nosqldatabase.org/.
Figuière Michaël NoSQL Europe : Tour d'horizon des bases de données NoSQL |
Blog Xebia France [Online] // Xebia. - 2010. - 2013. - http://blog.xebia.fr/2010/04/21/nosqleurope-tour-dhorizon-des-bases-de-donnees-nosql/.
47
Hale Coda You Can’t Sacrifice Partition Tolerance | codahale.com [Online] //
codehale.com. - 2010. - 2013. - http://codahale.com/you-cant-sacrifice-partition-tolerance/.
Hoff Todd High Scalability - High Scalability - VoltDB Decapitates Six SQL Urban
Myths and Delivers Internet Scale OLTP in the Process [Online] // High Scalability. - 2010. 2013. - http://highscalability.com/blog/2010/6/28/voltdb-decapitates-six-sql-urban-mythsand-deliversinternet.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+High
Scalability+%28High+Scalability%29.
Hogan Mike Head in the Clouds: The CAP Theorem Event Horizon [Online] // Head
in the Clouds. - 2011. - 2013. - http://scaledb.blogspot.fr/2011/03/cap-theorem-eventhorizon.html.
NuoDB NuoDB | Cloud Database | How it Works NuoDB [Online] // NuoDB. - 2013. 2013. - http://www.nuodb.com/.
RebelLabs Java Tools and Technologies Landscape for 2014 [Online]. http://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-for-2014/.
Robinson Henry CAP Confusion: Problems with partition tolerance; | Apache
Hadoop for the Enterprise | Cloudera [Online] // Cloudera. - 2010. - 2013. http://blog.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/.
Stonebreaker Michael Clarifications on the CAP Theorem and Data-Related Errors
VoltDB Blog [Online] // VoltDB Blog. - 2010. - 2013. - http://blog.voltdb.com/clarificationscap-theorem-and-data-related-errors/.
Stonebreaker Michael Slideshot: Watching Prof. Michael Stonebraker, MIT / One
Size Fits None [Online]. - 2013. - 2014. - http://slideshot.epfl.ch/play/suri_stonebraker.
48