Paradigme des bases de données NoSQL

Le 11 Juin 2009 Lors de la conférence sur les bases de données distribuées tenue à San Francisco, le terme « NoSQL » a été utilisé sur Twitter pour notifier l’évènement. Quelques temps plus tard à l’issue de cette conférence, une nouvelle catégorie de Systèmes de Gestion de Bases de Données (SGBD) émerge: les SGBD dits « NoSQL« 

ce terme « NoSQL », à lui tout seul, a complètement remis en cause les fondements conceptuels des SGBD traditionnels et le moins qu’on puisse dire est qu’il a un effet marketing certain !

Mon objectif dans cette chronique est de revenir sur le contexte technologique et les fondements conceptuels de ces SGBD « NoSQL » ; ainsi vous pourrez voir qu’ils sont une alternative aux SGBDR dans le contexte de Big Data actuel. Aussi, l’objectif est de préparer en douceur votre transition vers l’IaaC (Infrastructure as a Code). Alors, lisez très attentivement !

Contexte technologique des SGBD dits « NoSQL »

Les entreprises ont de plus en plus de mal à gérer des données qui arrivent sous des formes de plus en plus variées et qui sont produites de plus en plus rapidement. Les Géants du Web ont ressenti très tôt ce problème et le besoin pressant de gérer efficacement ce flux important de données. Pour que vous vous fassiez une image claire du problème :

• Yahoo, Google et les autres fournisseurs de services mails gèrent l’envoi de plus de 2,9 Millions d’emails dans le monde par seconde
• Amazon doit gérer 72,9 achats en moyenne sur son site par seconde
• Twitter doit publier en temps réel sur son site en moyenne plus de 21 millions de Tweets par heure
• Google doit s’organiser pour rendre disponible 300 heures de vidéos uplodés sur Youtube par seconde
• facebook doit gérer le partage de 2,46 millions de contenus en moyenne sur son site par minute
• Google doit restituer le résultat en temps quasi-réel de près de 3 millions de recherches effectués sur son moteur de recherche par minute
• Instagram doit gérer le partage de 216 000 photos effectué sur son site par seconde.
• (Stats disponibles en temps réel sur http://www.planetoscope.com/)

Vous rendez-vous maintenant compte de l’ampleur de l’explosion des données et du problème à gérer ?

Avant toute descente en eau profonde, je voudrais simplement rappeler qu’il est attendu d’un SGBD 2 fonctions : le stockage et le requêtage des données.

L’approche traditionnelle de gestion de données consiste à centraliser le stockage et le requêtage des données sur un Serveur de Gestion de Bases de Données contraint par un modèle de données dit « relationnel », construit en amont de la base de données.

Ce type de Système porte le nom de SGBDR (Systèmes de Gestion de Bases de Donnnées Relationnelles). Ils ont l’avantage de stocker les données sous forme tabulaire (relationnelle), et garantissent l’unicité, la cohérence et l’intégrité des transactions effectuées dans la Base de données à travers le mécanisme dit ACID (Atomicité, Cohérance, Isolation et Durabibilité).

Nous y reviendrons dans un autre article. En plus, ils proposent un langage de gestion et d’interrogation de données déclaratif et non-procédural appelé le SQL, qui permet aux analystes métiers avec relativement peu de compétences d’aborder le traitement des données.

Cependant, avec le Big Data, les SGBDR ont montré très rapidement leurs limites face, d’une part à la forte volumétrie des données, et d’autre part à la diversité des types de données. En effet, les SGBDR sont conçus pour gérer uniquement des données structurées (tabulaires), de plus l’augmentation du volume des données augmente le temps de latence des requêtes. Cette latence est préjudiciable dans le cadre de nombreux métiers nécessitant des réponses en temps quasi-réel.

Dès lors, la solution conceptuelle au problème n’est plus de centraliser la gestion des données sur ce seul serveur (SGBD) , mais de distribuer leur stockage et leur requêtage sur plusieurs ordinateurs (un cluster d’ordinateurs). Or, les SGBDR ne sont pas par essence des systèmes distribués. ils n’arrivent à assurer la distribution des données que sur 5 nœuds (ordinateurs) tout au plus.

C’est donc pour répondre à ces nouvelles exigences de montée en charge, de disponibilité et de distribution du stockage que les SGBD dits « NoSQL » ont émergés, et la conférence du 11 juin 2009 à San Francisco avait précisément pour but d’inaugurer cette nouvelle catégorie de SGBD distribués.

Approche conceptuelle des systèmes « NoSQL »

Beaucoup traduisent le « NoSQL » par « No SQL« , d’autres par « Not Only SQL« . En réalité, le débat n’est pas là. Le terme NoSQL n’a rien avoir avec la présence ou l’absence du SQL dans le SGBD. Il traduit plutôt un changement d’approche dans la conception du système et la base de données.

L’appoche de conception des SGBDR repose sur la théorie relationnelle (confère les axiomes de l’algèbre relationnelle) mise en oeuvre par Edgar Franck CODD. Or, L’exigence de distribution de données et de haute disponibilité rendent cette approche non-appropriée. Par conséquent, l’approche utilisée en NoSQL est une approche Non-Relationnelle.

Allons plus en détails. Par définition, l’avantage des SGBDR ou de l’approche relationnelle en générale est qu’elle garantit l’indépendance entre les données et les traitements (séparation totale et distincte entre la couche de données et la couche applicative). Cette indépendance est possible parce qu’une base de données relationnelle s’appuie sur une architecture modulaire segmentées en couches (ou en niveaux) inter-dépendantes.

Cette architecture en couches permet de créer des applications indépendantes des données, car il devient possible de développer et de modifier les applications sans que cela n’affecte la base de données elle-même. Plus encore, cela offre la possibilité de modifier la répartitions des fonctionnalités entre les couches  ou de créer entièrement de nouvelles couches si besoin, sans avoir à re-modifier les applications existantes ou la base de données.

En un mot, l’architecture modulaire répartie en couche  offre :

l’indépendance : indépendance entre la structure et les traitements, indépendance entre les applications et la base de données, indépendance entre le hardware et le software, indépendance entre les applications et les machines qui hébergent ces applications. Vous entendrez parler d’architecture à 2 niveaux, 3 niveaux, ou encore N niveaux pour désigner le nombre de couches selon lesquelles les fonctionnalités de la base de données peuvent être divisées.

En fait, indépendamment du type d’architecture, les fonctionnalités d’une base de données relationnelles sont toujours divisées en 3 couches : une couche interface-utilisateur, une couche applicative et une couche données. Le schéma suivant illustre ce découpage dans une architecture client-Serveur à 3 niveaux.

La figure précédente met en évidence les trois couches qui composent une architecture de base de données relationnelles. Lorsque ces couches sont réparties dans une architecture réseau à 2 niveaux, on parle d’architecture client-serveur à 2 niveaux (ou 2 tiers), auquel cas le serveur cumule les fonctionnalités de la couche de données et de la couche applicative.

Lorsqu’elles sont réparties en trois niveaux, on parle d’architecture client-serveur à 3 niveaux (comme c’est le cas dans la figure). La couche de données héberge la base de données, les données, les fonctions relatives à la sécurité, la gestion des transactions (modèle de concurrence, propriétés de cohérence comme ACID)  et les fonctions d’administration (autorisations, gestion des droits, exposition des données aux utilisateurs, etc.). La couche applicative héberge la logique métier des applications qui exploitent la base de données, c’est-à-dire le code qui est écrit pour adresser les requêtes métiers à la base de données, tandis que la couche interface-utilisateur héberge les fonctionnalités liées à l’interaction avec les données et les applications métiers. La figure suivant illustre ces couches et leurs différentes fonctionnalités.

L’avantage majeur de la répartition de ces fonctionnalités entre les couches est de créer l’indépendance entre la base de données et les applications qui l’exploitent. Cette indépendance favorise la standardisation du développement d’applications de base de données et permet aux développeurs de coder les applications métier sans avoir à encapsuler la structure de la base de données dans le code ou de se soucier de la façon dont le SGBDR gère la base de données. Cependant, dans les SGBDR, c’est justement garantir cette indépendance entre la structure des données et les traitements qui se paie au prix de sa scalabilité. On pourrait à juste titre dire que c’est la plus grande force du SGBDR qui est sa plus grande faiblesse dans le monde actuel. D’où l’apparition des SGBD NoSQL.

L’approche conceptuelle des Systèmes « NoSQL » se fait à 2 niveaux :

• au niveau du Stokage de données : dans le NoSQL, l’unité logique de stockage n’est plus la relation (ou la table en langage courant), mais agrégat (à l’exception des Bases de Données Graphes, dont l’unité de stockage est le noeud).
  l’agrégat est une collection d’objets (tel qu’une image, une vidéo, un document, ou tout autre donnée) référencés par une clé. On accède aux objets de la collection uniquement par la clé. les agrégats n’ont pas de lien logique
  entre eux comme c’est le cas dans les SGBDR où les tables peuvent être liées entre elles au moyen des contraintes d’intégrité référentielles. Chaque agrégat est indépendant, ce qui facilite la distribution des données.
  Souvenez-vous, le but des sgbd NoSQL est d’assurer la distribution du stockage et du requêtage de données sur un nombre théoriquement illimtés de noeuds (cluster d’ordinateurs)
• au niveau de la Haute disponibilité des données : dans un système distribué, assurer la cohérence des données est très contraignante et pénalise les performances du système. Concrètement, le SGBDR, pour assurer la cohérence des données, donc le respect des propriétés ACID, doit utiliser le mécanisme de verrou. C’est l’emploi de ces verrous qui plombe la performance du SGBDR lorsque le nombre de transaction s’accroît. Pour venir à bout de cette limitation, les systèmes NoSQL optent pour un relâchement complet des contraintes d’intégrité référentielles et sémantiques qu’on retrouve dans l’approche relationnelle. Ceci implique une redondance de données et une absence de schéma (ou de modèle) au sein la base de données, et donc une redéfinition même du concept de base de données. C’est ce qu’illustre la figure suivante :

Appliquer le paradigme distribué tel que nous venons de vous l’expliquer aux SGBD n’est pas aussi simple dans la pratique. D’une part, il y’a le fait que les SGBD ont été construits pour garantir la cohérence des données qu’elle héberge et d’autre part, il y’a le fait qu’ils doivent assurer l’indépendance entre les données et les applications.

Redonder les données lors de la distribution pour assurer la haute disponibilité du SGBD est contradictoire avec l’objectif de cohérence.

Changer l’unité logique de stockage de la table à une collection d’objet implique que désormais c’est au développeur d’encoder dans les applications à la fois la logique applicative et la couche « cohérence de données ». 

Dans la réalité, l’application du paradigme NoSQL a conduit à de nombreux arbitrages qui à leur tour ont conduit au développement de plusieurs types de SGBD NoSQL. Dans le point suivant, nous allons vous fournir un panorama complet de ceux-ci.

Panorama des bases de données NoSQL

Comme nous l’avons dit précédemment, assurer la cohérence et l’intégrité des données distribuées dans un cluster pose un certain nombre de problèmes qui requiert plusieurs niveaux d’arbitrages. Ces arbitrages sont à la base des différents types de SGBD NoSQL qui existent actuellement.

L’étude complète de ces arbitrages remplierait des ouvrages entiers et vous emmenerait beaucoup trop loin des objectifs de cette partie. Dans ce point, notre objectif est simplement de vous fournir un panorama non-exhaustif des catégories de solutions NoSQL qui existent actuellement sur le marché. Armés de cette connaissance, vous serez en même de savoir quel type de SGBD NoSQL est susceptible de correspondre à vos besoins de gestion de données.

Il est très important qu’à ce stade, vous vous souveniez qu’est qualifié de « NoSQL », tout SGBD qui ne se fonde pas sur l’approche relationnelle. L’objectif des SGBD NoSQL est d’assurer la distribution du stockage et du requêtage des données sur un nombre théoriquement illimité de nœuds d’un cluster. Pour accomplir cet objectif, les moteurs NoSQL changent de paradigme en matière de stockage de données : dans les SGBD relationnels, l’unité de stockage c’est la relation (ou table), mais celle-ci n’est pas adaptée dans un contexte Big Data. En réponse à cette limite, les éditeurs de moteurs NoSQL vont penser à des approches de stockage plus souples qui favorisent la distribution des données. Ces approches ont donné naissance à 6 catégories de SGBD NoSQL connues à ce jour : les SGBD orientés-clé/valeur, les SGBD orientés-colonnes, les SGBD orientés-documents, les SGBD orientés-graphes, les SGBD orientés-plein Text et les SGBD Natifs XML.

Les SGBD orientés clé-valeur

Ce sont des systèmes d’indexation des objets stockés sur le disque à l’aide d’un mécanisme de clé. Les objets peuvent être des fichiers, des vidéos, des pdf, des images, etc. Ces SGBD fonctionnent exactement comme une table de hachage[1] ou comme un dictionnaire dans lequel à chaque objet stocké sur le disque dur est associé un pointeur (une clé).

A la différence des tables de hachage classiques, les clés des bases orientés clé-valeur sont persistées sur le disque dur. Les utilisateurs n’accèdent pas aux données qui sont stockées sur le disque, ils y pointent à l’aide de la clé de l’objet.  De ce fait, ces moteurs n’ont pas besoin d’un langage d’interrogation de données. Étant donné que ce ne sont que les clés qui sont manipulées, 3 opérations peuvent y être effectuées : le PUT (ajout d’un pointeur), le GET (obtention d’un objet à partir de son pointeur) et le DELETE (suppression d’un pointeur et de l’objet associé).  

La simplicité du système permet au SGBD de distribuer le stockage des données sur un cluster et le rend linéairement scalable. Un use-case de ce type de moteur est par exemple le stockage des pages web. Les moteurs de recherche tels que Google ou Yahoo! utilisent ces SGBD pour stocker simplement des sites web entiers sous forme de clés-valeur. Amazon, dans son offre Cloud Amazon S3 utilise ce type de système pour gérer le stockage des données médias tels que les images et les vidéos.  Quelques exemples de SGBD orienté clé-valeur : Redis et Riak.  

 Les SGBD orientés-colonnes

A ne pas confondre avec les moteurs In-Memory colonne, tels que HP Vertica, Teradata, MonetDB, SybaseIQ qui sont des moteurs de traitement Analytique de type OLAP dans lesquels les données des colonnes d’une table sont persistées dans la même position sur le disque dur.

Les moteurs In-Memory Colonne sont contraires aux moteurs relationnels où ce sont plutôt les lignes qui sont persistées dans la même position sur le disque dur. L’approche In-Memory colonne est très utilisée dans les systèmes OLAP, car la localisation des colonnes dans la même position sur le disque facilite les opérations d’agrégation de données. 

Les SGBD NoSQL orientés-colonne quant à eux sont plus des entrepôts que des moteurs de base de données. Ils sont conçus pour stocker les données éparses ou les données qui ont les mêmes caractéristiques que les matrices creuses, c’est-à-dire des données qui ont plein de valeurs nulles. Ils stockent les données sous forme de grille similaire à une feuille de calcul, dans laquelle la ligne et la colonne sont utilisés comme clé pour récupérer les données. Ils sont considérés comme des entrepôts car ils ne typent pas les données, ne les indexent pas et ne fournissent pas de langage de requête pour l’extraction des données. Grâce à ces caractéristiques, ils distribuent facilement les données et peuvent s’appuyer sur des modèles de calculs externes tels que le MapReduce [2] pour l’exploitation de leurs données. Ils sont particulièrement bien adaptés pour le stockage de fortes volumétries de données. Un use-case des moteurs orientés-colonne est le stockage des données géo spatiales (prenez par exemple le service Google Earth, qui pour chaque centimètre carré de la planète est capable de fournir ses coordonnées géographiques).  Exemples de moteur orienté-colonne : Cassandra, HBase, Google BigTable, Accumulo.

 Les SGBD orientés-documents

Ce sont des SGBD clé/valeurs, à la différence que les valeurs sur lesquels pointent les clés ici ce sont des documents. Les documents stockés peuvent être des documents XML, des documents JSON, etc. L’avantage d’utiliser un SGBD orienté-document est que tout le contenu du document peut être indexé, et selon la structure du document, des requêtes de recherche (le Search) peuvent être adressées au moteur pour récupérer les contenus ayant la ou les mêmes propriétés.

Par contre, cet avantage peut rapidement s’avérer un problème, car puisque tout le contenu des documents peut être indexé, d’une part les indexes peuvent rapidement devenir très volumineux, posant ainsi des questions en matière d’architecture, d’autre part, en fonction de la structure (ou format) des documents, la recherche de contenu peut être plus ou moins compliquée.

Mais dans ces SGBD, ce sont les documents de format JSON qui sont généralement utilisés. Ces SGBD distribuent le stockage des documents sans aucune difficulté particulière. Exemple de SGBD orienté-document : MongoDB.

 Les SGBD orientés-graphes

Les SGBD orientés-graphes sont des moteurs qui sont conçus pour gérer les problèmes dans lesquels les entités du problème entretiennent des relations complexes. C’est par exemple le cas dans les réseaux sociaux. Comparativement à tous les autres moteurs de base de données qui regroupent toutes les données autour d’une table ou d’un agrégat, les moteurs orientés graphe les éclatent autant que possible sous forme de nœuds interconnectés qui forment un graphe.

Pour être formel, un graphe est un ensemble de sujets-prédicats-objets. Organiser les données sous cette forme permet d’activer des fonctionnalités intéressantes telles que l’inférence, le géospatial, le reverse query, et la bitemporalité. Ces fonctionnalités permettent de traverser le graphe de la façon la plus fine possible, de détecter les corrélations et les tendances. Un exemple de graphe : Juvénal habite Garges Sarcelles, Garges Sarcelles appartient au Val d’Oise, Val d’Oise est un département de l’Ile de France, l’île de France est une région de la France. Ce graphe possède 4 triplets (revoir la notion de triplet dans notre ouvrage Maîtrisez l’utilisation des technologies Hadoop, paru chez les éditions Eyrolles ), et dans le premier triplet, Juvénal est le sujet, habite est le prédicat, et Garges Sarcelles est l’objet. Une requête de type inférence permet d’inférer que Juvénal habite dans le Val d’Oise.  Ce type de relation peut être très complexe à modéliser dans une base de données relationnelle.

L’inconvénient des moteurs orientés-graphe cependant est que la forte connectivité du graphe ne permet pas au moteur de pouvoir distribuer le parcours du graphe sur plusieurs nœuds dans un cluster configuré en Shared-Nothing. Tout le graphe doit être stocké en mémoire pour être traité. Par conséquent, pour distribuer l’exploitation du graphe, il faut passer par des clusters Shared-Memory.  Exemple de moteurs orientés-graphe : Neo4J, Infinte Graph, OrientDB.

 Les SGBD orientés-plein Text ou d’indexation de contenu

Nous avons dit précédemment que l’avantage d’utiliser les moteurs orientés-documents c’est leur capacité à indexer le contenu des documents. Cependant, Indexer tout le contenu des documents fait accroitre rapidement à la fois le volume et le temps de construction des indexes à mesure que les documents sont ajoutés à la Base. Par exemple, un document de 20 pages contenant 5000 mots conduit à 5000 indexes ; ajouter 1000 documents dans la base contenant chacun 5000 mots conduit à approximativement 5 000 000 d’indexes à mettre à jour.

Les moteurs orientés Plein-text ou d’indexation de contenu sont des moteurs spécialisés dans l’exploitation de ces indexes pour des fins de recherche textuelle. Ils fournissent des algorithmes de recherche (par exemple Search ranking, stemming, Entity Extraction, Proximity Search, etc.) qui permettent par le biais d’index inversé de rechercher du contenu dans une base documentaire. Google par exemple, construit des indexes inversés à l’aide du MapReduce pour répondre aux recherches qui sont effectuées sur son moteur. Exemples de SGBD d’indexation de contenu : Apache Lucene, Apache Solr, ElasticSearch et Splunk.

 Les moteurs natifs XML

Comme nous l’avons signalé précédemment, l’inconvénient des précédents moteurs NoSQL est la portabilité des applications. En effet, le relâchement des contraintes relationnelles fait que le développeur d’application dans un moteur NoSQL doit lui-même coder à la fois la logique applicative et la couche « cohérence de données« . Ceci empêche de déplacer l’application d’un SGBD (de la même catégorie) à un autre.

Ce problème de portabilité est en partie dû à un manque de standard commun défini à la fois pour le stockage et les requêtes. C’est ce facteur qui a notamment permis aux bases de données relationnelles de s’étendre jusqu’à présent (la présence du SQL, un langage commun d’interrogation de SGBDR garantie la portabilité d’une application d’un SGBDR à un autre, ce qui n’est pas le cas avec les moteurs NoSQL).  Les moteurs natifs XML sont similaires au moteurs orientés-documents, à la différence qu’ils gèrent les documents XML. Le XML empêche l’introduction dans le moteur d’un langage propriétaire pour la gestion et l’interrogation des données.  Les requêtes sont faites sur les documents à l’aide du XQery, un langage standard défini par le W3C pour l’interrogation des documents XML. Exemple de moteurs XML : Berkely XML, existDB, MarkLogic.

En réalité, il existe une pléthore de SGBD NoSQL par catégorie. Nous n’avons cité ici que les plus populaires dans leur catégorie. Vous retrouverez ici la liste complète des SGBD NoSQL développés actuellement.

Nous allons finir cette chronique sur les problématiques des systèmes NoSQL.

Les problématiques des SGBD NoSQL

Malheureusement, malgré toute l’ambition des systèmes NoSQL, ceux-ci ne sont pas la panacée qu’on a voulu nous faire croire. Ces systèmes présentent de sérieuses problématiques dont vous devriez être conscient avant de décider de les adopter. Nous allons dans cette dernière partie de la chronique les lister succintement :

1. la cohérance et l’intégrité des transactions : dans les SGBDR, toutes les transactions doivent être strictement ACID (Atomiques, Conhérantes, Isolées et Durables), sinon elles sont annulées. Les systèmes NoSQL dupliquent les données ; ce qui pose un problème transactionnel dans le cadre de la réplication. Pour faire plus simple, si on enregistre une donnée plusieurs fois, sur plusieurs noeuds d’un cluster, cet enregistrement redondant sera-t’il atomique, cohérent, isolé et durable ? Pas forcément ! En tout cas c’est ce que met en exergue le théorème CAP (Consistency, Availability, Partition tolerance). Nous y reviendrons plus en détail dans une autre chronique.
2. la distribution des données : distribuer les données dans le cluster contraint les systèmes NoSQL à relâcher les contraintes d’intégrité sur la base de données; ceci entraîne une forte redondance des données, qui aura un impact sur la performance des requêtes.
3. l’absence de schéma de données : l’avantage des systèmes relationnels est qu’ils permettent de séparer de façon totalement distincte la couche de données de la couche applicative. Ceci permet aux développeurs de coder les aplications métier sans avoir à encapsuler la structure de la BD dans le code et de développer les applications de façon totalement indépendante de la structure de la BD. Dans les NoSQL par contre, il y’a à priori absence de schéma de données, du coup, il est du ressort du développeur de coder à la fois la logique applicative et la couche « Cohérance de données » dans l’application. Ceci peut rendre difficile soit la mise à jour de l’application, soit la modification de la structure de la base de données.
4. la modélisation, qui change l’approche projet de la BD : Dans le monde du relationnel, la modélisation de la base de données est la première phase obligatoire du projet; de ce modèle va dépendre totalement la suite du projet et les applications qui vont exploiter ces données. Cette approche projet séquentielle exige que chaque étape du développement logiciel soit maîtrisée et terminée avant de passer à l’étape suivante. Dans le monde du NoSQL, toutes les contraintes relationnelles ont été relâchées, ceci se traduit par ue flexibilité au niveau de l’approche projet.
   Les approches itératives de développement (tels que les méthodes agiles) peuvent y être utilisées. Cette flexibilité semble attrayante de prime abord, mais de sérieux problèmes au niveau des plans de continuité ou de gouvernance de données peuvent rapidement survenir.
5. la disponibilité des données : théoriquement, dans un système distribué, garantir un haut niveau de cohérence parmi les données pénalise les performances du système, car celà implique un échange d’informations important entre les noeuds du cluster, ce qui entraînera forcément des temps de latence accrus.

Conclusion

de façon général :

• On n’évalue pas une technologie hors du contexte dans lequel elle a été crée ;
• Le contexte dans lequel une technologie a été crée détermine son but et son but détermine son potentiel, ses caractéristiques et ses faiblesses ;

Alors :

• NoSQL = « Not Only SQL » ou « No SQL »?? Aucun des deux ! Celà signifie simplement, changement d’approche, du relationnel au non-relationnel. On aurait normalement dû dire « NoRel » ;
• est ce que les bases de données NoSQL sont l’avenir des Bases de Données?? C’est possible ! ;
• est ce que le mouvement NoSQL constitue une révolution dans le domaine des bases de données?? Non ! ;
• est ce les bases de données NoSQL sont meilleures que les bases de données relationnelles?? Mauvaise question !

J’espère que cette chronique complète vous a permis de bien comprendre ce qui se cache derrière le mouvement NoSQL et de comprendre les arbitrages que les systèmes NoSQL entraîne. J’espère que grâce à ces informations, vous serez capables d’effectuer un choix aiguisé dans votre projet quant au choix du paradigme de base de données que vous utiliserez. Si vous souhaitez recevoir des chroniques comme celle-ci en permanence ou si vous êtes dans une démarche de reconversion vers la data, téléchargez notre guide de programmation sur Scala suivant, et cela nous permettra de vous ajouter à notre liste de plus de 4000 lecteurs.

---

[1] Une Table de hachage (hash table en anglais), est une table qui assigne à une donnée d’entrée une valeur particulière. La table de hachage, générée par une fonction de hachage, fait correspondre la donnée d’entrée à sa valeur assignée correspondante à l’aide d’une clé.

[2] Le mapreduce est un modèle de calcul distribué utilisé dans dans le cluster computing pour effectuer des traitements de données. Il effectue le traitement d’un fichier de données en 3 tâches indépendantes – une phase Map, une phase Shuffle et une phase Reduce.