NoSQL

En informatique, NoSQL (Not only SQL en anglais) désigne une catégorie de systèmes de gestion de base de données (SGBD) qui n'est plus fondée sur l'architecture classique des bases relationnelles. L'unité logique n'y est plus la table, et les données ne sont en général pas manipulées avec SQL.

À l'origine, servant à manipuler des bases de données géantes pour des sites web de très grande audience tels que Google, Amazon.com, Facebook ou eBay^[1], le NoSQL s'est aussi étendu par le bas après 2010. Il renonce aux fonctionnalités classiques des SGBD relationnels au profit de la simplicité. Les performances restent bonnes avec la montée en charge (scalabilité) en multipliant simplement le nombre de serveurs, solution raisonnable avec la baisse des coûts, en particulier si les revenus croissent en même temps que l'activité^[2]. Les systèmes géants sont les premiers concernés : énorme quantité de données^[3], structuration relationnelle faible (ou de moindre importance que la capacité d'accès très rapide, quitte à multiplier les serveurs). Un modèle typique en NoSQL est le système clé-valeur, avec une base de données pouvant se résumer topologiquement à un simple tableau associatif unidimensionnel avec des millions — voire des milliards — d'entrées. Parmi les applications typiques, on retrouve des analyses temps-réel, statistiques, du stockage de logs (journaux), etc.

De grands acteurs d'Internet, notamment Google (BigTable), Amazon (Dynamo (en)), LinkedIn (Project Voldemort), Facebook (Cassandra Project puis HBase), SourceForge.net (MongoDB), Ubuntu One (CouchDB), etc., conçoivent et exploitent des bases de données de type NoSQL. D'autres acteurs plus modestes sont à l'origine de grands succès, notamment dans le domaine des stockages clé-valeur (Redis…). Une proportion importante de ces projets est open source et sous licence libre.

Éléments historiques

La rencontre meetup NoSQL de San Francisco du 11 juin 2009 a été particulièrement importante pour le développement de cette tendance. Plus de 100 développeurs de logiciels ont assisté à des présentations de solutions telles que Project Voldemort, Cassandra Project, Dynomite, HBase, Hypertable, CouchDB et MongoDB. Le concept du NoSQL avait cependant déjà une bonne décennie d'ancienneté.

L'expression NoSQL, la plupart du temps interprétée comme Not Only SQL^[4], a été utilisée pour la première fois en 1998^[5]. Elle est pourtant visuellement la combinaison de non et de SQL, ce qui peut faire croire que cette technologie s'oppose à SQL, langage répandu de manipulation des données. Selon Shashank Tiwari dans son livre Professional NoSQL, « les auteurs de ce néologisme ont probablement voulu signifier non-relationnel, mais ont préféré le mot NoSQL parce qu'il sonne mieux » que, par exemple, NoREL. Le mot est aujourd'hui utilisé comme terme générique pour tous les SGBD et les logiciels de stockage de données qui ne suivent pas les principes classiques des SGBD relationnels, objets ou hiérarchiques.

Les SGBD non relationnels, plus anciens que les SGBD relationnels, sont classiques sur les mainframes et les logiciels d'annuaire, performants là où les lectures sont bien plus fréquentes que les écritures (par exemple LDAP). Leur principe connaît une nouvelle jeunesse avec le NoSQL, porté par le domaine des services Internet, car la plupart des logiciels NoSQL sont destinés à permettre la répartition de charge des grands services Internet.

La rencontre de 2009 à San Francisco est considérée comme l'inauguration de la communauté des développeurs de logiciels NoSQL. Des développeurs qui, selon le magazine Computerworld, « racontent comment ils ont renversé la tyrannie des coûteux et lents SGBD relationnels par des moyens plus simples et plus rapides de manipuler des données ». Selon Jon Travis, un des présentateurs de la conférence, « les SGBD relationnels en font trop, alors que les produits NoSQL font exactement ce dont vous avez besoin ». Les leaders de cette communauté sont majoritairement des start-up qui n'avaient pas les moyens d'acquérir les licences Oracle, et ont donc développé leurs propres SGBD en imitant les produits de Google et d'Amazon.com. Les produits qu'ils ont créés peuvent manipuler de très grandes quantités de données (centaines de téraoctets) et offrent une évolutivité à la charge adaptée aux besoins des applications Web 2.0, ce qui les rend pertinents. Les auteurs décrivent leurs produits comme n'étant pas des SGBD, mais plutôt des logiciels de stockage de données^[6].

En 2011, un travail de spécification pour un langage de manipulation standardisé a débuté sous le nom de UnQL (Unstructured Query Language). Il se propose de formaliser la façon dont les bases NoSQL requêtent les collections (le pendant des tables de données pour les bases relationnelles). Bien qu'UnQL ait été présenté comme une abstraction au-dessus de SQL, ce dernier correspondant à un UnQL très contraint, il a été rappelé qu'UnQL ne recouvre pas tout le LDD de SQL. En réalité, les deux domaines, bases relationnelles et NoSQL, répondant à des besoins et des contraintes différentes, coexistent souvent dans les architectures métiers.

Théorie

Un système de gestion de base de données (SGBD) relationnel permet de réaliser des transactions atomiques, cohérentes, isolées, et durables (ACID).

Les capacités ACID garantissent que si plusieurs utilisateurs font de manière simultanée des modifications des données, toutes les modifications vont être prises en compte, dans un ordre précis et maîtrisé de manière à avoir un résultat cohérent (intégrité des données) avec l'historique des modifications faites par chacun. La mise en œuvre stricte des capacités ACID entraîne des coûts logiciels importants et un niveau de performance moindre à infrastructure matérielle équivalente.

Les SGBD d'annuaires ont servi de modèle en permettant de lever certaines de ces contraintes en fonction de l'usage, en particulier dans les cas où la grande majorité des accès aux bases de données consistent en lectures sans modification (dans ce cas, seule la propriété de persistance importe).

Pour faire face à des volumes importants de données, accédés de différents endroits du monde, il faut pouvoir répliquer ces données sur différentes machines physiques, c'est ce que l'on appelle un environnement distribué. Le théorème CAP démontre qu'il n'est pas possible d'assurer des transactions totalement ACID dans un environnement distribué.

Le protocole Paxos est très efficace pour la lecture dans un environnement distribué, beaucoup moins pour l'écriture / modification et il ne supporte pas les transactions ACID.^{[réf. nécessaire]}

Les solutions du marché implémentent ce protocole en ajoutant leurs techniques propres pour limiter les conséquences de l'impossibilité d'ACID lors des écritures et mises à jour de données.

Le marché

Les SGBD relationnels sont largement répandus dans les entreprises. Dimensionnés pour une quantité d'informations et un nombre d'utilisateurs typiques d'une entreprise, ils ont pour fonction principale le traitement de transactions.

Ils montrent cependant leurs limites lorsqu'ils sont utilisés dans un périmètre plus large, tel qu'un site web populaire, en répartition de charge (load balancing), fréquenté par des millions de visiteurs dans le monde entier : les SGBD relationnels exigeraient alors des logiciels et des ordinateurs coûteux ainsi que des compétences en optimisation peu répandues.

Ce segment de marché est de ce fait occupé par les logiciels NoSQL, conçus spécifiquement pour un usage de type Internet^[7]. Ces produits abandonnent la représentation matricielle de l'information et le langage de commande SQL en échange d'une simplicité, d'une performance et surtout d'une scalabilité accrues^[2]. La complexité de mise en œuvre du traitement des transactions a été réduite dans le but d'obtenir des services plus simples et plus spécialisés^[8].

Simple à mettre en œuvre, le stockage d'information à l'aide de tableaux associatifs (dits clé / valeur) existe depuis le début de l'histoire des bases de données, en 1970. Des langages comme Perl et PHP les ont rendus familiers aux programmeurs. Les nouvelles demandes en rapport avec les sites web de grande audience apparus dans les années 2000 et la facilité de mise en œuvre des tableaux associatifs ont fait émerger ces solutions. Elles ont comme point commun l'abandon du langage SQL et sont donc nommées NoSQL. Cela ne signifie pas qu'aucune ne proposera jamais ce langage en option^[9].

Dans le marché des SGBD NoSQL se trouvent Cassandra, MongoDB, Voldemort, CouchDB et SimpleDB. Selon Oracle, le « battage » autour de ces produits vient du fait qu'ils sont impliqués dans de grands sites web tels que Facebook, LinkedIn ou Amazon.com. C'est un marché jeune, encore sans réel leader (en 2011). Le marché évolue rapidement et les comparatifs de produits y sont rapidement dépassés^[10],[11]. Lors d'un sondage réalisé en 2010 auprès de professionnels de l'informatique, 44 % des sondés répondaient encore qu'ils n'ont jamais entendu parler de NoSQL^[12].

Exemples

Exemples de produits NoSQL :

• Accumulo
• Berkeley DB (Oracle)
• BigTable (Google)
• Cassandra (Twitter, Digg)
• CouchDB
• DEX/Sparksee (en)
• DynamoDB
• HBase (Facebook)
• MongoDB (SourceForge.net)
• Neo4j
• Project Voldemort (LinkedIn)
• Redis
• Riak
• SimpleDB (Amazon.com)
• Oracle NoSQL (en)

Bases de données relationnelles ayant une interface NoSQL :

• MySQL avec le moteur InnoDB et l'interface memcached

Références

Voir aussi

Articles connexes

• Base de données orientée objet
• Base de données relationnelle
• Base de données orientée colonnes
• Base de données orientée documents
• Base de données orientée graphe
• Système de Gestion de Flux de Données (DSMS, ou SGFD)

Liens externes

• (en) « Your Ultimate Guide to the Non - Relational Universe! », nosql-database.org (consulté le 3 avril 2013) : Liste régulièrement mise à jour des bases NoSQL avec liens vers les sites projets

• Portail des bases de données
• Portail du Web sémantique