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 la plus populaire de l'acronyme est (« pas seulement SQL » en anglais) même si cette interprétation peut être discutéeNotamment parce que les SGBD relationnels (Postgres, Oracle, SQLServer…) bien qu'étant inclus dans le « » ne sont en général pas inclus dans la famille « NoSQL ».
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 années 2010À 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 ».. 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 posséder un paradigme de bases de données adapté à ce modèle d'infrastructure matérielle Pramod J. Sadalage et Martin Fowler, , Addison-Wesley Professional, 8 août 2012 ..
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.
É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ès largement dominant au début des années 1990.
Plusieurs autres modèles de bases de données ont émergé, tels que les SGBD orientés objet, SGBD hiérarchiques, SGBD relationnel-objet mais 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 souffrant 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 des propriétés ACID et généralement conçus pour fonctionner sur des ordinateurs uniques ont rapidement posé des problèmes d'extensibilité.
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 qui en ont résulté, Google (BigTable), Amazon (), LinkedIn (Voldemort), Facebook (Cassandra puis HBase), MongoDB, Ubuntu One (CouchDB), Baidu (Hypertable) ont été les précurseurs du modèle NoSQL Shashank Tiwari, , John Wiley & Sons, 2011 .
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 temps que l'activité Nick Rozanski, Eoin Woods, Software systems architecture: Working with Stakeholders using viewpoints and perspectives, Addison-Wesley . Les systèmes géants sont les premiers concernés : énormes quantités de données30 pétaoctets pour une migration Facebook, 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 à 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 , Johan Oskarsson, ingénieur informaticien à Londres, souhaite organiser une rencontre à San Francisco pour effectuer un tour d'horizon de ces nouveaux systèmes . 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 « » ne sera inventée plus tard que comme rétro-acronymeNote : 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 (« »), cette utilisation antérieure est une coïncidence sans lien avec la famille de SGBD discutée dans le présent article..
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 » (« ») ou d'autres 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 Project Voldemort, 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, . Selon Jon Travis, un des présentateurs de la conférence, . 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 « »..
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 (). 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 les architectures 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 : il ne s'agit pas à proprement parler d'une propriété recherchée, mais plutôt 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 émergentes.
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 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 en effectuant une jointure entre ces dernières à chaque opération. Cette architecture pourra poser un problème lorsque le nombre de clients/achats deviendra important et sera difficile à 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 effet, ces agrégats interagissent peu entre eux et peuvent facilement être répartis sur un cluster de serveurs. Cette architecture pourra par contre poser un problème si pour une raison quelconque on est amené à effectuer 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 moins efficace 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 relationnelles, l'efficacité de ces bases est variable en fonction des systèmes et tâches et des configurations. Ces données sont typiquement celles des réseaux sociaux, réseaux de transport, topologies ou systèmes de recommandation de documents.
On distingue habituellement les triplestores 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 mixtes) et offrent souvent de meilleures performances pour les traversées de graphes. Les triplestores gèrent exclusivement des graphes binaires de triplets RDF (donc centrés sur les relations) mais proposent des inférences. Les langages de requête dépendent des bases, les triplestores 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 un 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