NoSQL

En informatique et en bases de données, NoSQL désigne une famille de systèmes de gestion de base de données (SGBD) qui s'écarte du paradigme classique des bases relationnelles. L'explicitation du
1
terme la plus populaire de l'acronyme estNot only SQL (« pas seulement SQL» en anglais) même si cette interprétation peut être discutée .

La définition exacte de la famille des SGBD NoSQL reste sujette à débat. Le terme se rattache autant à des caractéristiques techniques qu'à une génération historique de SGBD qui a émergé autour des
2
années 2010 . D'après Pramod J. Sadalage et Martin Fowler, la raison principale de l'émergence et de l'adoption des SGBD NoSQL serait le développement des centres de données et la nécessité de
3
posséder un paradigme de bases de données adapté à ce modèle d'infrastructure matérielle.

L'architecture machine en clusters induit une structure logicielle distribuée fonctionnant avec des agrégats répartis sur différents serveurs permettant des accès et modifications concurrentes mais
imposant également de remettre en cause de nombreux fondements de l'architecture SGBD relationnelle traditionnelle, notamment les
propriétés ACID.

Sommaire
Éléments historiques
Domination historique des SGBD relationnels
Pionniers du modèle NoSQL
Invention et popularisation du terme NoSQL
Convention NoSQL de 2009
Théorie
NoSQL orienté-agrégats
NoSQL orienté-graphes
NoSQL sans-schéma
Autres
Marché
Exemples
Notes et références
Voir aussi
Articles connexes
Liens externes

Éléments historiques

Domination historique des SGBD relationnels

Les SGBD relationnels créés dans les années 1970 se sont progressivement imposés jusqu'à devenir le paradigme de bases de données trèsgement
lar dominant au début des années 1990.

Plusieurs autres modèles de bases de données ont émer

gé, tels les SGBD orientés objet, SGBD hiérarchiques, SGBD relationnel-objetmais leur utilisation est restée très limitée.

C'est dans le courant des années 2000 avec le développement de grandes entreprises internet (Google, Amazon, eBay…) brassant des quantités énormes de données et le développement de l'informatique
en grappes que la domination sans partage du modèle relationnel a été remise en question car souf
frant de limites rédhibitoires pour ces nouvelles pratiques.

Pionniers du modèle NoSQL

Ce sont les grandes entreprises du web amenées à traiter des volumes de données très importants qui ont été les premières confrontées aux limitations intrinsèques des SGBD relationnels traditionnels.
Ces systèmes fondés sur une application stricte despropriétés ACID et généralement conçus pour fonctionner sur des ordinateurs uniques, ont rapidement posé des problèmesextensibilité.
d'

Afin de répondre à ces limites, ces entreprises ont commencé à développer leurs propres systèmes de gestion de bases de données pouvant fonctionner sur des architectures matérielles distribuées et
permettant de traiter des volumes de données importants. Les systèmes propriétaires qui en ont résulté, Google (BigTable), Amazon (Dynamo (en)), LinkedIn (Voldemort (en))), Facebook (Cassandra
4
puis HBase), SourceForge.net (MongoDB), Ubuntu One (CouchDB), Baidu (Hypertable) ont été les premiers précurseurs du modèle NoSQL .

Les performances restent bonnes avec la montée en charge en multipliant simplement le nombre de serveurs, solution raisonnable avec la baisse des coûts, en particulier si les revenus croissent en même
5 6
temps que l'activité . Les systèmes géants sont les premiers concernés : énormes quantités de données , 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.

Invention et popularisation du terme NoSQL

La parution d'articles présentant ces systèmes propriétaires a conduit au développement de plusieurs projets souvent open source reprenant à la fin des années 2000/début des années 2010 ces grands
principes, à savoir des systèmes scalables par architectures matérielles distribuées, ne visant pas une application stricte du
standard ACID.

Le 11 juin 2009, Johan Oskarsson, ingénieur informaticien à Londres, souhaite organiser une rencontre meetup à San Francisco pour effectuer un tour d'horizon de ces nouveaux systèmes « open-source,
distribués et non-relationnels ». Il souhaite un nom percutant et facile à retenir pour cette conférence, après avoir consulté le canal IRC #Cassandra, le nom « NoSQL » est retenu. Cette dénomination ne
devait initialement servir qu'à désigner cette convention mais elle passera à la postérité en devenant la désignation de cette génération d'outils. L'interprétation « not only SQL » ne sera inventée plus tard
3, 7
que comme rétro-acronyme .

De nombreux spécialistes se sont plaints de l'inexactitude du terme « NoSQL » et des confusions qu'il pouvait créer, lui préférant parfois le terme « NoRel » (« not only relational ») ou d'autres
3, 4
désignations plus spécifiques, mais le terme reste le plus populaire .
Convention NoSQL de 2009
Plus de cent développeurs de logiciels ont assisté à des présentations de solutions telles que Projectoldemort,
V Cassandra, Dynomite, HBase, Hypertable, CouchDB et MongoDB.

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 licencesOracle, 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
8
produits comme n'étant pas des SGBD, mais plutôt des logiciels destockage de données .

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.

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 font des requêtes dans 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érents, coexistent souvent dans lesarchitectures métiers.

Théorie
Les caractéristiques principales des SGBD NoSQL sont de permettre la manipulation de volumes de données importants et de permettre une scalabilité horizontale. Ces systèmes ne respectent en général
pas les standards des SGBD relationnels, mais il ne s'agit pas à proprement parler d'une propriété recherchée mais plus d'une concession permettant des traitements plus rapides pour certains types
d'applications.

À ce titre les structures des SGBD restent en date de 2016 très hétérogènes. Nous pouvons cependant citer quelques familles principales émer
gentes.

NoSQL orienté-agrégats
Une des caractéristiques retrouvées dans de nombreux SGBD NoSQL est l'utilisation d’« agrégats de données » constitués d'un ensemble de données souvent « consultées/modifiées en même temps » et
3
qui peuvent être déployées sur des serveurs indépendants.

À titre d'exemple considérons une application de commerce-en-ligne conçue de manière à accéder fréquemment aux informations d'un client (adresses, etc) et à l'historique de ses achats (par exemple
pour lui proposer des réductions).

Un SGBD relationnel typique modélisera ce système en créant une table des informations clients et une table des achats puis enfectuant
ef une jointure entre ces dernières à
chaque opération. Cette architecture pourra poser problème lorsque le nombre de clients/achats deviendra important et seraficile
dif à répartir entre plusieurs serveurs.
A contrario une architecture SGBD NoSQL typique aura tendance à modéliser ce problème en un ensemble d'agrégats constitué des informations d'un client et de ses achats.
Cette architecture est plus facilement scalable. En ef
fet ces agrégats interagissent peu entre eux et peuvent facilement être répartis sur un cluster de serveurs. Cette
architecture pourra par contre poser problème si pour une raison quelconque on est amené à fectuer
ef des requêtes qui ne correspondent pas aux cas d'utilisation
immédiatement considérés. Par exemple une demande de calcul du nombre total de clients ou d'achats pourra être moinsficace ef que dans un système relationnel qui
conserve l'ensemble des clients (resp. achats) dans une table unique.

NoSQL orienté-graphes
Les bases de données orientées graphe permettent de stocker les données sous forme de graphe et de faciliter l'écriture des requêtes en supprimant la plupart des jointures. Par rapport aux bases
9
relationnelles, l'efficacité de ces bases est variable en fonction des systèmes et tâches et des configuration . Ces données sont typiquement celles des réseaux sociaux, réseau de transport, topologies, ou
systèmes de recommandation de documents.

On distingue habituellement les triplestore des bases de données orientées-graphe. Les bases de données graphe fonctionnent avec différents types de graphe (ex: pondérés, clusters, graphe et tables
9
mixtes) et offrent souvent de meilleures performances pour les traversées de graphes . Les triplestore gèrent exclusivement des graphes binaires de triplet RDF (donc centrés sur les relations) mais
proposent des inférences. Les langages de requête dépendent des bases, les triplestore fonctionnent exclusivement avec le langage
SPARQL, voir article détaillé à propos de langages de requête.

Pour les bases de données orientées graphe, l'utilisation de schéma de données n'est pas toujours nécessaire.

NoSQL sans-schéma
La première étape de la création d'une base de données relationnelle est de définir son schéma c'est-à-dire l'ensemble des tables la composant et l'ensemble des champs de ces tables. Cette étape crée une
certaine rigidité dans l'implémentation, implique d'avoir une vision assez claire des évolutions de l'application et peut poser problème si la structure des données recueillies change dans le temps. Les
systèmes NoSQL sans-schéma peuvent ignorer cette étape et stocker des données hétérogènes au fur et à mesure de leur alimentation. Cette utilisation permet une grande flexibilité et des capacités
d'adaptation au niveau de la base de données. La contrepartie est que les applications qui liront la base de données devront être capables d'intégrer des données plus hétérogènes et de structure plus
complexe.

Autres
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
consiste en lectures sans modification (dans ce cas, seule la propriété de persistance importe).

Pour faire face à des volumes importants de données, auxquelles on accède 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é. Lethéorème CAP démontre qu'il n'est pas possible d'assurer des transactions totalement ACID dans un environnement distribué.

[réf. nécessaire]
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.

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.

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.
10
Ce segment de marché est de ce fait occupé par leslogiciels NoSQL, conçus spécifiquement pour un usage de type Internet . Ces produits abandonnent la représentation matricielle de l'information et le
5
langage de commande SQL en échange d'une simplicité, d'une performance et surtout d'une scalabilité accrues . La complexité de mise en œuvre du traitement des transactions a été réduite dans le but
11
d'obtenir des services plus simples et plus spécialisés .

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
12
ont fait émerger ces solutions. Elles ont comme point commun l'abandon du langage SQL et sont donc nomméesNoSQL. Cela ne signifie pas qu'aucune ne proposera jamais ce langageen option .

Dans le marché des SGBDNoSQL se trouvent Cassandra, MongoDB, Voldemort, CouchDB et SimpleDB. Lors d'un sondage réalisé en 2010 auprès de professionnels de l'informatique, 44 % des sondés
13
répondaient encore qu'ils n'ont jamais entendu parler de NoSQL .

Exemples
Exemples de produits NoSQL:

Accumulo, fondation Apache, Licence Apache 2.0, dérivé d'Hadoop avec des fonctions de sécurité augmentées
Berkeley DB, Oracle Corporation, il existe deux versions en licence libre et propriétaire
BigTable, Google, privé, depuis mai 2015 il existe une version publique sous licence propriétaire
Hypertable, Zvents, GNU GPL 2.0, sponsorisé par Baidu depuis 2009
Cassandra, fondation Apache, Licence Apache 2.0, utilisé par Twitter, Digg...
CouchDB, fondation Apache, Licence Apache 2.0, NoSQL orienté-document
DEX/Sparksee (en), Sparsity Technologies, propriétaire, NoSQLorienté graphe
DocumentDB, Microsoft Azure, propriétaire
DynamoDB (en), Amazon, propriétaire, utilisable essentiellement viaAmazon Web Services
HBase, fondation Apache, Licence Apache 2.0, dérivé d'Hadoop, utilisé notamment par Facebook
MongoDB, MongoDB Inc., GNU AGPL, NoSQL orienté-document
Neo4j, Neo Technology Inc, GNU GPLv3 et GNU AGPLv3, NoSQL orienté graphe
OrientDB, OrientDB Ltd, Licence Apache 2.0, NoSQL orienté graphe
projet Voldemort (en), LinkedIn, privé avec versions publiques sous Apache License 2, stockage de données distribué
Redis, Salvatore Sanfilippo sponsorisé parRedisLab, licence BSD
Riak, Basho Technologies, Licence Apache 2.0 avec modules complémentaires payants (propriétaires), inspiré deDynamoDB
SimpleDB (Amazon.com), mis à disposition viaAmazon Web Services
Oracle NoSQL (en), Oracle Corporation, propriétaire
Bases de données relationnelles ayant une interface NoSQL:

MySQL avec le moteur InnoDB et l'interface memcached

Notes et références
1. Notamment parce que les SGBD relationnels (Postgres, Oracle, SQLServer…) bien
qu'étant inclus dans le «not only SQL » ne sont en général pas inclus dans la famille
« NoSQL »
2. À titre d'exemple, les SGBD orientés objet, bien que « non SQL», ne sont en général
pas considérés comme appartenant à la famille « non SQL».
3. (en) Pramod J. Sadalage et Martin Fowler, NoSQL Distilled: A Brief Guide to the
Emerging World of Polyglot Persistence, Addison-Wesley Professional, 8 août 2012
(ISBN 0321826620).
4. (en) Shashank Tiwari, Professional NoSQL, John Wiley & Sons, 2011
(ISBN 9781118167809)
5. (en) Nick Rozanski, Eoin Woods, Software systems architecture: Working with
Stakeholders using viewpoints and perspectives , Addison-Wesley
(ISBN 9780132906128)
6. 30 pétaoctets pour une migration Facebook(http://www.journaldunet.com/solutions/ds
i/informatique-de-facebook/hadoop-chez-facebook.shtml)
7. Note : le terme « NoSQL» a été pour la première fois utilisé en 1998 par Carlo Strozzi
pour désigner un système relationnel n'utilisant pas le langage SQL«( NoSQL: A
Relational Database Management System» (http://www.strozzi.it/cgi-bin/CSA/tw7/I/en
_US/nosql/Home%20Page)), cette utilisation antérieure est une coïncidence sans lien
avec la famille de SGBD discutée dans le présent article.
8. (en) « No to SQL? Anti-database movement gains steam» (http://www.computerworl
d.com/s/article/9135086/No_to_SQL_Anti_database_movement_gains_steam_) .
9. (en) « Benchmark: PostgreSQL, MongoDB, Neo4j, OrientDB and ArangoDB» (http
s://www.arangodb.com/2015/10/benchmark-postgresql-mongodb-arangodb/), sur
arangodb.com
10. (en) Adriaan De Jonge, Essential App Engine: Building High-Performance Java Apps
with Google App Engine, Addison-Wesley Professional, 2011(ISBN 9780321742636)
11. (en) Daniel A. Keim, Jörn Kohlhammer, Geoffrey Ellis, Florian Mansmann,Mastering
the Information Age - Solving Problems with V isual Analytics (ISBN 9783905673777)
12. (en) Pete Warden, Big Data Glossary, O'Reilly Media, 2011(ISBN 9781449314590)
13. (en) Informations Week: Surprise: 44% Of Business IT Pros Never Heard Of NoSQL
(http://www.informationweek.com/news/software/info_management/227500077?query
Text=nosql+survey)

Voir aussi

Articles connexes Sur les autres projets Wikimedia :

NoSQL, sur le Wiktionnaire

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 U
niverse! », nosql-database.org (consulté le 3 avril 2013) : Liste régulièrement mise à jour des bases NoSQL avec liens vers les
sites projets
Ce document provient de «https://fr.wikipedia.org/w/index.php?title=NoSQL&oldid=143415503 ».

La dernière modification de cette page a été faite le 11 décembre 2017 à 15:31.

Droit d'auteur : les textes sont disponibles souslicence Creative Commons attribution, partage dans les mêmes conditions ; d’autres conditions peuvent s’appliquer
. Voyez les
conditions d’utilisation pour plus de détails, ainsi que lescrédits graphiques. En cas de réutilisation des textes de cette page, voyezcomment citer les auteurs et mentionner la licence
.
Wikipedia® est une marque déposée de laWikimedia Foundation, Inc., organisation de bienfaisance régie par le paragraphe501(c)(3) du code fiscal des États-Unis.