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 dépendant et dont une panne entraîne l'arrêt complet du système.

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 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 :

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

que l'on soupçonne d'être vraie, en l'absence de contre-exemple.

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

destiné aux entreprises.

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 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

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. »

32

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’est-

ce 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 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é.

33

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.

34

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 processing21, 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 Enchaînement automatique d'une suite de commandes (processus) sur un ordinateur sans

intervention d'un opérateur.

35

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 Les CRM (Customer relationship management) sont des systèmes qui permettant de gérer les

interactions avec des clients.

36

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.

37

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.

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

38

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)

39

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

40

Selon vous, serez-vous amené à utiliser ces technologies dans le futur ?*

Oui

Non

Je ne sais pas

Voici maintenant les résultats du sondage :

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.

55%

45%

Connaissance du NoSQL

Oui, et j'ai contribué à la miseen place d'une solutionNoSQL dans le cadre d'unprojet professionnel

Oui, mais seulement le cotéthéorique

Non

30%

18%

37%

15%

Nombre de projets moyen

1

2

Entre 2 et 5

Plus de 5

41

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.

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.

15%

37%

11%

11%

26%

Taille moyenne des entreprises bénéficiaires

TPE (moins 10 salariés)

PE (entre 10 et 49salariés)

ME (entre 50 et 249salariés)

GE (plus de 250salariés)

Grands groupes (plusde 5000 salariés)

24%

19%55%

2%

Type de NoSQL majoritairement utilisé

Orientée colonnes(Cassandra, HBase...)

Orientée clé-valeur (Redis,Riak...)

Orientée documents(MongoDB, Couchbase,ElasticSearch...)

Orientée graphes (Neo4J,Titan...)

42

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.

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.

39%

33%

24%

4%

Raisons de l'utilisation du NoSQL

Pour de meilleuresperformances

Les changements sur lemodèle de donnéesétaient trop fréquents

Car une baserelationnelle n'était pasnécessaire

Autre

48% 6

8%

74%

861%

911%

108%

Moyenne de satisfaction après livraison (sur 10)

43

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. »

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 :

4%

96%

Futur du NoSQL

Mourir

Remplacer les basesrelationnelles

Cohabiter avec lesbases relationnelles

25%

17%48%

10%

Type de NoSQL majoritairement connu

Orientée colonnes(Cassandra, HBase...)

Orientée clé-valeur(Redis, Riak...)

Orientée documents(MongoDB, Couchbase,ElasticSearch...)Orientée graphes(Neo4J, Titan...)

44

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.

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.

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.

36%

64%

Présence du NoSQL en entreprise

Oui

Non

77%

5%

18%

Utilisation future du NoSQL

Oui

Non

Je ne sais pas

45

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.

46

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.

47

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-theorem-

and-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-or-

eventually-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-CAP-

theorem.

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/couchbase-

server/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://nosql-

database.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/nosql-

europe-tour-dhorizon-des-bases-de-donnees-nosql/.

Hale Coda You Can’t Sacrifice Partition Tolerance | codahale.com [Online] //

codehale.com. - 2010. - 2013. - http://codahale.com/you-cant-sacrifice-partition-tolerance/.

48

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-myths-

and-delivers-

internet.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-event-

horizon.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/clarifications-

cap-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.