Tout savoir sur les bases de données noSQL

Pourtant, au cours des années 2000, plusieurs entreprises, qui ne sont pas des éditeurs de logiciels, commencent à développer leurs propres systèmes de gestion de bases de données. C’est le cas de Google, qui, dès 2004, développe Big Table, d’Amazon qui introduit Dynamo en 2007, de Yahoo! qui déploie son propre entrepôt de données Everest en 2007 (*), de Facebook qui en 2008 dévoile Cassandra, ou encore de LinkedIn qui en 2009 présente le projet Voldemort. Deux grandes raisons expliquent ces choix. D’une part, ces « géants du Web », pour reprendre le titre d’un ouvrage qui analyse leurs stratégies IT (Cf. Best Practices, n° 106, 2 avril 2013), se trouvent confrontés plus tôt que d’autres à l’explosion des volumes de données. D’autre part, en tant que fournisseurs de services en ligne, il est vital pour eux de maintenir un très haut niveau de performance dans le temps, faute de quoi les utilisateurs se tourneront vers un service concurrent. Il leur faut donc des systèmes capables à la fois :

• de manipuler des teraoctets, voire des petaoctets de données, généralement distribuées sur de nombreux serveurs et avec des lectures ou écritures très fréquentes, sans que cela ne se ressente sur les performances ni la disponibilité,
• d’accompagner la croissance des données dans le temps en offrant la capacité d’une montée en charge simple, prévisible et à un coût maîtrisé, c’est la fameuse scalability des anglo-saxons,
• d’offrir des modèles très flexibles, les données manipulées étant amenées à changer fréquemment.

Les limites des SGBDR

Or, sur ces points, les acteurs du Web estiment que les SGBDR traditionnels ne suffisent pas à répondre à certains de leurs besoins. Ils leur reprochent notamment une « scalabilité » insuffisante, requérant une architecture matérielle coûteuse, soulignent les limites des stratégies de réplication classiques dans leurs environnements fortement distribués et déplorent une complexité pas forcément justifiée au regard des usages considérés : stocker des images satellites (Google Earth) ou des URL (Google Search), effectuer un grand nombre d’analyses simples sur de gros volumes de données (Yahoo !), assurer la persistance des paniers clients ou des listes de préférences (Amazon) ou encore gérer de très gros volumes de données distribuées sur de nombreux serveurs bon marché en assurant une haute disponibilité (Facebook).

Ces géants du Web explorent donc d’autres approches que le modèle relationnel, optant notamment pour des modèles en colonnes ou des structures « clé-valeur ». Dans le même temps, d’autres solutions non relationnelles commencent à percer, rencontrant également leurs cas d’usage avec la vague des services « 2.0 ».

A l’heure actuelle, la tendance « Not only SQL » recouvre quatre grands types d’approches, même si d’autres pourraient s’y ajouter (Cf. point 3 de cet article) :

• les bases de type clé-valeur : il s’agit du modèle le plus simple, dans lequel on accède à chaque donnée (valeur) à travers une clé. La base s’apparente alors à une table associative et supporte des manipulations basiques (ajout, modification, suppression et recherche par clef/identifiant).
• les bases en colonnes : dans ces bases, souvent inspirées de Big Table, les données ne sont plus stockées cellule par cellule, mais sous la forme de colonnes. Ainsi, dans une base relationnelle orientée cellules, les données seraient stockées sous la forme d’un enregistrement, c’est-à-dire d’une succession de champs (une clé, un nom, un prénom, un code postal). Une base en colonnes stockerait, pour sa part, toutes les clés, puis tous les noms, tous les prénoms, tous les codes postaux… Par ailleurs, dans les bases en colonnes, les données récurrentes ne sont stockées qu’une fois, avec des pointeurs pour indiquer les différents endroits où elles apparaissent.
• les bases en graphes : ces bases stockent les données sous la forme de graphiques en réseau. Les graphiques sont constitués de trois éléments : des nœuds, des relations entre nœuds et des propriétés, sachant que nœuds et relations peuvent avoir des propriétés. Imaginons, par exemple, un nœud « DSI » avec comme propriétés un nom, « Séhiaud », et un prénom, « Olivier », ainsi qu’un nœud « Entreprise ». Une relation entre ces deux nœuds pourrait être « travaille dans », avec une propriété « date d’entrée ».
• les bases orientées documents : ces bases sont conçues pour stocker des données semi-structurées de manière moins rigide que dans les bases relationnelles, qui imposent des schémas très normalisés. Pour cela, elles utilisent notamment des formats comme XML ou JSON (JavaScript Object Notation), un format d’échange de données calqué sur le langage JavaScript, mais indépendant de celui-ci. Les documents ainsi stockés peuvent facilement avoir des sections communes (par exemple un titre, un ou des auteurs) et d’autres qui diffèrent et apparaissent dans un ordre variable (une image associée, un sous-titre, un encadré…). Dans le modèle relationnel classique, ces éléments additionnels auraient été complexes à gérer.

De nombreux projets existent aujourd’hui dans ces quatre catégories, dont une proportion importante de solutions en open source. Certains des acteurs précédemment évoqués ont mis à disposition leur technologie, d’autres comme Google ont inspiré des projets similaires. Ne sont listées dans le tableau (voir ci-dessous) que les implémentations publiquement disponibles.

Pour manipuler les données stockées dans ces différents types de solutions, plusieurs technologies se sont développées en parallèle. Parmi celles-ci figurent par exemple :

• Apache Hadoop MapReduce, qui permet de paralléliser le traitement de données afin d’optimiser les opérations sur de gros volumes,
• Apache Hive, pour construire des entrepôts de données et de les interroger avec un langage proche de SQL, HiveQL,
• Apache Pig, une plate-forme pour créer des programmes d’analyse sur de très gros ensembles de données, utilisant un langage haut niveau, le Pig Latin, qui lui-même repose sur MapReduce,
• Apache Mahout, une bibliothèque d’algorithmes de datamining et d’apprentissage automatique basée sur MapReduce,
• Cascading, un framework Java pour aider les développeurs à créer des applications analytiques,
• ElasticSearch, un moteur de recherche et d’analyse distribué, capable d’explorer des documents au format JSON. Il s’apparente à une base orientée documents, mais est davantage conçu pour la lecture (pas de transactions distribuées). Là encore, il s’agit d’une solution basée sur une technologie Apache, en l’occurrence Lucene, moteur de recherche en texte intégral.

On peut citer également une tentative de Couchbase et SQLite en 2011 pour développer un langage de requête général pour les bases NoSQL, le UnQL (Unstructured Data Query Language). Celle-ci n’a cependant pas débouché sur un standard concret, probablement du fait de l’hétérogénéité des technologies NoSQL à prendre en compte.

2. Regard critique

Du côté des atouts de ces solutions, la capacité à redimensionner facilement les infrastructures pour s’adapter à une montée en charge figure en bonne place. Pour maintenir les performances en cas de hausse de la demande, il suffit en effet d’ajouter des serveurs d’entrée de gamme. Nul besoin de se doter de matériels coûteux ou de se préoccuper des stratégies de partitionnement comme c’est souvent le cas avec les bases relationnelles classiques. A titre d’exemple, selon le site de Cassandra, la plus large grappe de serveurs connue, sur laquelle la solution est en production, dépasse 300 téraoctets de données répartis sur plus de 400 machines.

Dans un article sur sa base Big Table, Google cite, pour sa part, les chiffres observés en 2006 : « Un groupe de 14 grappes actives avec un total de 8 069 serveurs tablettes [Ndlr : c’est ainsi que sont désignées les machines individuelles membres d’un cluster] a vu un volume agrégé de plus d’1,2 millions de requêtes par seconde, avec un trafic entrant de près de 741 mégaoctets/seconde et un trafic sortant de 16 gigaoctets/seconde. » Néanmoins, si les meilleures capacités de mise à l’échelle et les performances sur le traitement de gros volumes de données font partie des dénominateurs communs à ces systèmes, le choix ne doit pas se faire sur ces seuls critères. En particulier, selon le théorème CAP (Consistency, Availability, Partition tolerance) formulé par Eric Brewer, professeur à l’université de Berkeley, les systèmes fortement distribués ne peuvent garantir en même temps la cohérence globale des données, la disponibilité et la résistance au morcellement (si une panne du réseau empêche des nœuds de se parler entre eux, le système doit continuer à fonctionner). Selon les objectifs visés, l’un ou l’autre de ces trois aspects devra donc passer au second plan.

Ainsi, les systèmes NoSQL mettent fréquemment l’accent sur la disponibilité (notamment Cassandra, conçue pour éviter d’avoir un point unique de défaillance) et sur la résistance aux pannes. D’autres, comme HBase, privilégient plutôt la cohérence des données au détriment de la disponibilité, en offrant un certain niveau de support des propriétés ACID. Une solution comme Neo4J a, quant à elle, privilégié plutôt la cohérence et la disponibilité, même si des mécanismes de résistance au morcellement ont été ajoutés.

De manière générale, plusieurs solutions proposent des paramétrages ou des mécanismes permettant d’avoir un certain niveau de conformité aux propriétés ACID. Néanmoins, des solutions comme Redis ou MongoDB ne garantissent pas, par exemple, une durabilité au sens strict du terme, ce qui implique un risque, certes minime, de perte de données. Dans Cassandra, c’est la cohérence qui n’est pas garantie, du moins dans l’immédiat, comme expliqué sur le wiki de la solution : « Alors que les données sont répliquées, la dernière version d’une donnée existe quelque part sur l’un des nœuds du cluster, mais d’autres versions plus anciennes subsistent sur d’autres nœuds. A terme, tous les nœuds verront la dernière version. »

Des modèles de données flexibles

De tout ceci, il ressort que ces bases doivent être considérées avant tout pour des applications où la cohérence et la conservation des données ne sont pas vitales, donc à déconseiller pour les applications transactionnelles critiques ou celles soumises à de fortes contraintes de conservation des données. En revanche, dans des domaines où les schémas de données peuvent évoluer fréquemment, ces solutions méritent d’être considérées. Ensuite, il faut bien étudier les cas d’usage envisagés. En effet, chacune des quatre grandes catégories de bases NoSQL a été conçue pour des cas d’usages spécifiques :

• Les bases de type clé-valeur, qui offrent des niveaux de performance élevés tant en lecture qu’en écriture, conviennent notamment aux applications dans lesquelles l’accès aux données s’effectue par un simple identifiant, ou bien pour l’acquisition de gros volumes de données de manière très rapide (collecte de journaux/logs par exemple).
• Les bases en colonnes offrent pour leur part un modèle bien adapté pour certaines applications analytiques qu’elles accélèrent. En effet, elles permettent de ne parcourir que les colonnes contenant les données souhaitées lors d’une requête, alors qu’il faut parcourir tous les champs dans les SGBDR classiques. L’architecture en colonnes est d’ailleurs reprise dans certaines bases relationnelles destinées à des usages décisionnels, comme SAP Sybase IQ ou Teradata Columnar ou InfiniDB.
• Les bases orientées documents, comme leur nom l’indiquent, ciblent plutôt des applications gérant des contenus comme les CMS (Content Management System) ou des données semi-structurées.
• Enfin, les bases en graphes, de par leur structure en réseau, conviennent dès lors qu’il faut modéliser des ensembles de relations complexes et susceptibles d’évoluer. Elles sont utilisées pour la surveillance des réseaux de communication et pour les applications de réseaux sociaux, mais elles trouvent également des applications dans les systèmes géographiques (applications de routage) ou la détection de fraudes.

Les entreprises développant des applications mobiles sont également friandes de ce type de technologies, la souplesse des modèles de données facilitant la mise en place de nouvelles fonctionnalités et les mises à jour fréquentes.

Dans tous les cas, il faut garder à l’esprit qu’il s’agit de technologies récentes, dont la maturité reste encore faible. Certaines des solutions mentionnées sont donc susceptibles de disparaître, tandis que d’autres encore peu connues peuvent se développer. Par ailleurs, les considérations relatives à la sécurité (chiffrement des données, protection contre les attaques par injections via JavaScript, traçabilité des connexions…) restent pour l’instant assez peu prises en compte par les différents acteurs à l’origine de ces solutions, ce qui peut présenter des risques en matière de protection de la vie privée.

3. Que faire ? Quelques pistes de solutions

A l’heure actuelle, ce type de solution est largement utilisé chez les grands acteurs du Web et par les start-ups du secteur : Twitter (Redis, Cassandra), LinkedIn (projet Voldemort, Couchbase), Facebook (HBase), eBay (Cloudera), le site de petites annonces géolocalisées Craigslist (MongoDB, Redis), le forum communautaire Reddit (Cassandra), le média social Foursquare (MongoDB), Viadeo (Neo4J…).

D’autres types d’entreprises s’appuient également sur ces technologies : des laboratoires pharmaceutiques comme Janssen, client de Neo4J, des acteurs des télécoms comme Orange Digital (MongoDB), Telenor et SFR (Neo4J) ou Comcast (Riak), des entreprises de distribution comme Walmart Labs (Cassandra) ou Leroy Merlin (MongoDB), des acteurs de la recherche et de l’éducation comme le CERN (MongoDB) ou le National Cancer Institute (Cloudera), ou encore des médias et des entreprises de divertissement comme Blizzard, le Guardian (Redis) ou le site spécialisé sur les productions audiovisuelles IMDB (DynamoDB).

Cette diversité des utilisateurs et des cas d’usage montre que ces solutions peuvent trouver leur place dans les systèmes d’information des entreprises. Néanmoins, les experts du domaine s’accordent sur un point : ces technologies sont davantage complémentaires que concurrentes des bases relationnelles traditionnelles, et, hors cas particuliers, elles n’ont pas vocation à les remplacer. Certaines applications peuvent même bénéficier d’une association des deux technologies : le SGBDR, lorsque les données ont intérêt à être mises en relation les unes avec les autres ou quand leur cohérence est primordiale ; une ou plusieurs solutions NoSQL, quand les données ne font pas l’objet de requêtes poussées ou quand elles n’ont pas forcément vocation à être conservées à tout prix. Si le modèle relationnel convient fort bien dans 80 % des cas, mais s’avère mal adapté aux 20 % restants, pourquoi s’échiner à y faire rentrer à tout prix des données, alors qu’il existe désormais d’autres choix ?

Pour démarrer sur ce type de technologie, la première chose à faire est d’identifier les cas d’usages possibles, voire d’en imaginer, ces solutions se prêtant bien à la création de services Web ou mobiles. Un grand nombre de solutions étant proposées en open source, nul besoin de gros investissements préalables pour commencer à les évaluer.

La difficulté réside plutôt du côté des ressources humaines : en effet, la plupart de ces solutions ont moins de cinq ans d’existence et fort peu de personnes disposent déjà d’une expérience sur celles-ci. Plutôt que de chercher à recruter un hypothétique expert, il est donc plus judicieux de miser sur l’auto-apprentissage, à condition de pouvoir y consacrer un peu de temps. Un projet pilote peut ainsi fournir l’occasion aux équipes internes d’expérimenter ce type de technologie et de les tester dans le contexte de l’entreprise. La curiosité d’esprit et l’envie d’apprendre sont les principaux critères à prendre en compte pour identifier les profils adéquats à ce type de projet. Néanmoins, quelques compétences techniques peuvent également faciliter la prise en main des bases NoSQL : la connaissance des SGBD traditionnels et de leurs modèles de données, celle des architectures distribuées, ainsi qu’une certaine maîtrise des langages de programmation utilisés par ces solutions, notamment Java, Erlang ou C++.

Si l’entreprise ne parvient pas à dégager le temps nécessaire ou que les bons profils ne sont pas disponibles, il reste deux possibilités : faire appel à des consultants, s’il existe un besoin concret auquel ces solutions peuvent remédier ; ou attendre l’arrivée sur le marché de solutions hybrides permettant d’expérimenter ces approches à moindre risque (à moindre coût, cela reste à voir). La plupart des acteurs traditionnels du marché des bases de données (EMC Greenplum, Teradata, IBM Informix, SAP Sybase) ont en effet commencé à intégrer des fonctionnalités inspirées du monde NoSQL, comme le support de MapReduce ou la prise en charge du format JSON.

(*) Celui-ci n’est pas une technologie NoSQL stricto sensu puisqu’il utilise ce langage pour manipuler les données. Néanmoins, il repose sur un modèle en colonnes plutôt qu’un modèle relationnel classique.

Tableau des principales solutions disponibles
Nom de la solution	Fournisseur	Type de technologie	Licence	URL
Cassandra	Projet créé par Facebook et transmis à l’Apache Software Foundation	Colonnes, accent mis sur la haute disponibilité	Open source	cassandra.apache.org Datastax (www.datastax.com) fournit une offre packagée autour de Cassandra
Couchbase	Couchbase	Documents	Open source	www.couchbase.com
CouchDB	Apache Software Foundation	Documents	Open source	couchdb.apache.org
DEX	Sparsity Technologies	Graphes	Propriétaire	www.sparsity-technologies.com
DynamoDB	Disponible sous forme de service sur le cloud Amazon	Clé-valeur distribuée	Propriétaire	aws.amazon.com/fr/dynamodb
HBase	Apache Software Foundation	Colonnes HBase est la base de référence dans les architectures Hadoop et repose sur le systЏme de fichiers distribué HDFS (Hadoop Distributed File System).	Open source	hbase.apache.org Cloudera (www.cloudera.com) propose une offre packagée Hadoop incluant HBase
MongoDB	MongoDB	Documents	Open source	www.mongodb.org
Neo4J	NeoTechnology	Graphes	Open source	www.neo4j.org
Oracle NoSQL Database	Oracle	Clé-valeur distribuée	Propriétaire	www.oracle.com/fr/products/database/nosql/overview/index.html
Projet Voldemort	Projet initialement développé par LinkedIn puis ouvert à la communauté	Clé-valeur distribuée	Open source	www.project-voldemort.com/voldemort
Redis	Développement communautaire	Clé-valeur stand alone en mémoire (stockage structuré très rapide, mais sans la capacité de montée en charge des solutions distribuées)	Open source	redis.io
Riak	Basho Technologies	Clé-valeur distribuée	Open source	basho.com/riak
SimpleDB	Disponible sous forme de service sur le cloud Amazon	Clé-valeur limitée en taille de tables et en nombre de requêtes/seconde	Propriétaire	aws.amazon.com/fr/simpledb
Source : Best Practices Systèmes d’Information.

---

Les propriétés ACID en bref

Atomicité : chaque transaction est considérée comme un tout. Si une transaction contient plusieurs manipulations sur les données, mais que l’une d’elles échoue, alors aucune des modifications ne sera appliquée.

Cohérence : aucune transaction ne peut laisser la base dans un état invalide par rapport aux règles définies dans le modèle. Si une transaction contient, par exemple, un type de données ne correspondant pas à celui prévu pour un champ, elle échouera.

Isolation : si deux transactions s’exécutent de manière concurrente sur les mêmes données, le système doit faire en sorte qu’elles n’interfèrent pas. Cette propriété peut être implémentée à travers divers mécanismes de contrôle comme le verrouillage des données.

Durabilité : une fois qu’une transaction est validée, son résultat doit être stocké de manière permanente sur un support non volatile (c’est-à-dire capable de conserver les données même hors tension).