Base de données NoSQL

Base de données NoSQL
DÉFINITION, COMPARAISON ET BENCHMARKING
Réalisé par Oussama ARBI

PLAN
Définition
Classification
NoSQL - Définition
NoSQL - Types
NoSQL - SQL vs NoSQL
NoSQL - Benchmarking
NoSQL - Comparaison des fonctionnalités
NewSQL – Définition et Comparaison
Conclusion

4
Définition
Une base de données est essentiellement une collection d'informations organisées de
telle sorte qu'un programme informatique peut rapidement sélectionner les données
souhaitées.

6
Classification
BD hiérarchiques et
en réseau
BD SQL BD NoSQL BD NewSQL
BD Relationnels
BD orientés objet, Colonne,
Document, Clé Valeur,
Graphe …
BD en mémoire …

9
NoSQL
NoSQL désigne une famille de base de données qui s'écarte du paradigme classique des
bases relationnelles. Cette famille traite principalement certains points: être non relationnel,
distribué et horizontalement évolutif. L'explicitation du terme la plus populaire de l'acronyme
est Not only SQL (« pas seulement SQL » en anglais).
Définition

Multi-
value
Multi-
modèle
Orienté
clé valeur
Orienté
colonne
Orienté
objet
11
NoSQL
Types
Orienté
document
NoSQL
Multi-
dimensionnel
Orienté
graphe

12
NoSQL
Types
BD Orienté clé/valeur :
• Définition : Ce type de bases de données peut être vu comme une gigantesque table
associative clé/valeur éventuellement partitionnée sur plusieurs instances. Le modèle s’en
rapprochant le plus est celui du cache. Les structures de données ne sont pas contrôlées par
un schéma. Selon l’implémentation, la clé peut être attribuée ou générée aléatoirement lors
de l’ajout de l’enregistrement. Réputées performantes et capables de gérer un volume
important de données, les bases clé/valeur sont par exemple adaptées à :
 la collecte d’évènements (jeux en ligne),
 la gestions de traces (mesure d’audience)
 la gestions de profils utilisateurs des sites de forte audience (commerce
électronique)
• Exemple : Redis, Riak

13
NoSQL
Types
BD Orienté document :
• Définition : Elles ont vocation à stocker des données semi-structurées, c’est-à-dire dont la
structure n’est pas contrainte par un schéma mais dont le contenu est néanmoins formaté.
L’unité de stockage est un document, généralement au format JSON ou XML. D’une certaine
façon, on peut définir un document comme un ensemble de couples propriété/valeur, dont
la seule contrainte est de respecter le format de représentation. En ce sens, on peut
considérer la base de donnée orientée document comme une sorte d’évolution de la base de
donnée clé/valeur distribuée.
• Exemple : MongoDB, CouchBase, CouchDB

14
NoSQL
Types
BD Orienté colonne:
• Définition : Dans une base de données relationnelles, une table est un ensemble de données
organisées en colonnes dont le nombre est fixe quel que soit le nombre d’enregistrements.
Lorsque l’on insère un enregistrement dans cette table, on spécifie une valeur pour chaque
colonne, null étant une valeur par défaut. dans le modèle orienté colonne, le nombre de
colonnes peut varier pour chaque enregistrement.
• Exemple : Cassandra, HBase

15
NoSQL
Types
BD Orienté graph :
• Définition : Fondées sur la théorie des graphes, elles sont conçues pour modéliser des
structures de données relationnelles aussi diverses qu’un réseau social. Les bases de
données relationnelles sont tout à fait adaptées pour gérer ce type de structures mais elles
atteignent leurs limites sur le champ de la performance quand la profondeur du graphe et le
volume de données à gérer sont importants. Sur ce point, les bases de données orientées
graphe surclassent les SGBDRs. Dans le monde des bases orientées graphe, tout est affaire de
nœuds, de relations et de propriétés. Les propriétés portent aussi bien sur les nœuds que les
relations. Ce modèle est très adapté pour gérer des données sociales ou spatiales, mais
également financières où les relations modéliseraient les dépôts ou retraits.

16
NoSQL
Types
BD Orienté graph :
• Exemple : Neo4j

18
NoSQL
SQL est utilisé à la fois comme nom d'une langue et comme type de base de données.
SQL, la langage, est conçu pour la gestion de données dans des systèmes de gestion de bases de
données relationnelles (RDBMS). Les systèmes de gestion de bases de données relationnelles
sont souvent appelés bases de données SQL, car ils utilisent le langage SQL. Depuis le milieu des
années 1980, SQL est une norme pour l'interrogation et la gestion des ensembles de données
RDBMS.
SQL vs NoSQL

19
NoSQL
• Fonctionnalités SQL
 S'appuyer sur des tables relationnelles
 Utiliser un schéma de données défini
 Réduire la redondance par la normalisation
 Support la fonctionnalité JOIN
 Conçu pour l'intégrité des données
 Support que l’évolutivité verticale (Scale-up/Vertical Scale)
 Utiliser un langage de requête standardisé et simple
 Adoption presque universel
SQL vs NoSQL

20
NoSQL
Les technologies NoSQL n'ont gagné popularité qu'au début des années 2000 quand les
organisations cherchaient des solutions pour loger des quantités massives de données
importantes au repos à un prix plus bas qu'elles ne pouvaient avec les SGBDR et pour être en
mesure de gérer la vitesse de plus en plus élevée des données entrantes.
SQL vs NoSQL

21
NoSQL
Alors qu'une base de données SQL est un concept défini, concret, NoSQL n'est pas. Il
existe d'énormes variations dans les technologies qui relèvent de la catégorie NoSQL (bien
qu'elles partagent généralement certaines caractéristiques). Ainsi, NoSQL est un terme utilisé
pour un large groupe de technologies de gestion des données qui varient en fonctionnalités
mais qui tentent de résoudre certains problèmes clés de bases de données SQL.
SQL vs NoSQL

22
NoSQL
• Fonctionnalités NoSQL
 Ecriture haute performance et évolutivité massive (Scale-out/Horizontal Scale)
 Ne nécessite pas de schéma défini pour l'écriture de données
 Cohérente par défaut
 Soutenir une vaste gamme de langages de programmation et d'outils modernes
SQL vs NoSQL

23
NoSQL
SQL vs NoSQL
Caractéristiques SQL NoSQL
Relationnel
 
Prise en charge du langage
SQL
 *
Complètement conforme
ACID
 *
Évolutivité horizontale  
Schéma
 
High Performance  

NoSQL
Comparaison des fonctionnalités

25
NoSQL
• Pour notre étude, on va utiliser ces BD NoSQL:

26
NoSQL
CouchDB est une base de données NoSQL développée en Erlang, orientée document (au
format JSON) et exposant une API REST HTTP. CouchDB partage avec IBM Notes le concept de
base orientée document avec vue. Une vue est un moyen d’effectuer des requêtes sur la base
de documents. Elle est définie dans un document JSON au format particulier contenant
l’identifiant de la vue ainsi que les fonctions Map/Reduce écrites en JavaScript et implémentant
les règles de recherche. Les vues sont indexées et mises à jour automatiquement à mesure que
des documents sont ajoutés, modifiés ou supprimés. CouchDB est conçu pour ne pas introduire
de verrou lors des accès concurrents (méthode MVCC). En d’autres termes, les accès en lecture
ne bloquent pas les accès en écriture et réciproquement. La scalabilité horizontale est assurée
par réplication

27
NoSQL
MongoDB est un système de gestion de base de données orientée documents
développé par la société 10gen, répartissable sur un nombre quelconque de machine et ne
nécessitant pas de schéma prédéfini des données. Il est écrit en C++.
MongoDB n’est pas MVCC comme CouchDB et implémente un moteur de requêtage plus direct
et expressif que les vues dans ce dernier.
MongoDB permet d’indexer les propriétés des documents afin d’optimiser une recherche.
Par ailleurs les documents, regroupés en collections (équivalent NoSQL des tables), sont stockés
au format BSON (Binary JSON).

28
NoSQL
L’API cliente est spécifique à MongoDB et des drivers sont disponibles dans une multitude de
langages de programmation et les opérations de bases peut être effectuée à partir d’un shell.
Une autre singularité de MongoDB est son support de l’indexation géospatiale en 2D depuis la
version 1.4, à savoir la possibilité de répondre à des requêtes géographiques (par exemple
trouver la station de métro la plus proche de ma position actuelle).
MongoDB supporte le sharding manuel et automatique, c’est-à-dire le partitionnement
horizontal des données. Dit autrement, le sharding fait référence au découpage des collections
de données en plus petites unités (selon un critère donné, par exemple la valeur d’un attribut)
et leur distribution sur un réseau de machines esclaves. On augmente ainsi la capacité de
stockage tout en répartissant le traitement sur des machines de moyenne puissance.
MongoDB supporte un mécanisme de réplication maître/esclave garantissant une plus grande
intégrité des données ainsi qu’une tolérance aux pannes.

29
NoSQL
HBase est un clone de BigTable développé au sein de l’écosystème Hadoop et utilisé par
de nombreuses compagnies, dont Facebook et Yahoo!. Les données sont stockées dans des
fichiers appelés HFiles dans la terminologie HBase et gérés par HDFS, le système de fichier
distribué d’Hadoop qui le sous-tend, garantissant l’intégrité des données. HBase est réputé pour
être très performant en lecture (là ou Cassandra est très performant en écriture), mais on lui
reproche de présenter des points de défaillance inhérent à l’architecture de HDFS et HBase.

30
NoSQL
Dans une infrastructure Hadoop ou HBase, il y a 2 types de machines : les maîtres (le
NameNode HDFS, le Master HBase) et les esclaves (les DataNode HDFS, les RegionServers
HBase). L’infrastructure est inopérante en cas d’indisponibilité d’un composant maître, et
particulièrement en cas d’indisponibilité du Namenode. Composant névralgique de HDFS, ce
dernier gère l’espace de nommage et l’arborescence du système de fichiers, les méta-données
des fichiers et répertoires. Il centralise la localisation des blocs de données répartis sur le
système. Sans Namenode, tous les fichiers peuvent être considérés comme perdus. Il faut
néanmoins tempérer ce risque dans la mesure où les défaillances d’un Namenode sont
extrêmement rares. HBase est ainsi un peu moins centré sur la disponibilité et plus sur la
cohérence des données et la tolérance au partitionnement.

31
NoSQL
Initialement créé par Facebook, Cassandra est le compétiteur le plus sérieux de HBase.
Contrairement à ce dernier, son architecture distribuée et décentralisée le rend hautement
disponible car les nœuds d’un cluster Cassandra jouent tous le même rôle (pas d’architecture
maître/esclave). L’indisponibilité d’un nœud ne met pas en péril l’infrastructure.
En écriture, les données sont d’abord stockées en mémoire (Memtables) et ne basculent sur
disque que lorsque la structure en mémoire a atteint un seuil défini par configuration. Cassandra
a ainsi la particularité d’être plus performante en écriture qu’en lecture au point de la qualifier
de base de données orientée écriture.

32
NoSQL
Tolérant au partitionnement et hautement disponible, Cassandra ne garantit pas de
cohérence stricte (strict consistency) des données. On parle plutôt de cohérence éventuelle
signifiant par là que les mises à jour sont propagées dans l’ensemble des réplicats mais que cela
prendra plus ou moins de temps. On parle également de cohérence personnalisable car le
niveau de consistance peut être ajusté par configuration.
Cassandra supporte la réplication de données sur plusieurs datacenters répartis
géographiquement.

33
NoSQL
Multiple dans ses usages, Redis est également perçue comme une sorte de cache ou
mémoire partagée sur TCP, ce qui le distingue d’une solution de persistance alternative aux
bases de données relationnelles.
A ce jour, Redis n’est pas tolérant aux pannes. C’est un sacrifice dû à la cohérence des données.
Néanmoins, Redis cluster, toujours en cours de développement, est une solution permettant de
distribuer Redis en cluster.
Redis est singulier dans sa manière de gérer les données en écriture. Stockées d’abord en
mémoire, elles ne sont déversées sur disque que périodiquement.

34
NoSQL
Réputé pour ses performances (plusieurs dizaines de milliers d’insertions par seconde
sur une machine de série), Redis est particulièrement adapté pour construire des systèmes
analytiques temps réel à grande échelle (monitoring d’applications web par exemple).
A la différence des autres moteurs de type clé/valeur, Redis supporte plusieurs types (chaîne de
caractère, liste ordonnées ou non, table de hachage) permettant de mieux organiser ses
données ainsi qu’un grand nombre d’opérations pour les exploiter (déterminer des intersections
ou union de liste, incrémenter/décrémenter un compteur etc.).
Enfin, Redis dispose d’un support natif du modèle publish/subscribe. Une utilisation conjointe
avec Socket.IO permet par exemple de construire aisément un compteur temps réel de visiteurs
d’un site web.

35
NoSQL
Couchbase Server est une base de données orientée document NoSQL open source et
distribuée. Il utilise une memoire clé/valeur rapide avec cache pour gérer en submillisecond les
opérations de données, des indexeurs spécialement conçus pour des requêtes rapides et un
moteur de requêtes pour l'exécution de requêtes similaires à SQL. Pour les environnements
mobile et Internet des objets, Couchbase Lite fonctionne en mode natif et gère la
synchronisation avec Couchbase Server.

36
NoSQL
Couchbase Server est spécialisé dans la gestion de données à faible latence pour les applications
Web, mobiles et IoT interactives à grande échelle. Les exigences courantes que Couchbase
Server a été conçu pour satisfaire sont les suivantes:
 Modèle de données flexible
 Langage d'interrogation puissant
 Évolutivité
 Performance
 Simple administration
 La haute disponibilité

37
NoSQL
Firebase est un ensemble de services d'hébergement pour n'importe quel type
d'application (Android, iOS, Javascript, Node.js, Java, Unity, PHP, C++ ...). Il propose d'héberger
en NoSQL et en temps réel des bases de données, du contenu, de l'authentification sociale
(Google, Facebook, Twitter et Github), et des notifications, ou encore des services, tel que par
exemple un serveur de communication temps réel.
La base de données Firebase est une base de données en temps réel cloud. Les données sont
stockées en tant que JSON et synchronisées en temps réel à chaque client connecté. Lorsque
vous créez des applications multiplate-forme avec nos SDK iOS, Android et JavaScript, tous vos
clients partagent une instance Realtime Database et reçoivent automatiquement les mises à
jour avec les données les plus récentes.

39
NoSQL
Un « Benchmark » est un banc d'essai permettant de mesurer les performances d'un
système pour le comparer à d'autres, dans notre cas, pour mesurer les performances d’un SQBD
NoSQL et le comparer a des autres SGBDs.
Benchmarking

40
NoSQL
• Pour effectuer un « Benchmarking » pour les BDs NoSQL, on a besoin de :
 Plusieurs serveurs (Nœuds)
 Une machine cliente pour effectuer le test
 Les workloads (Charge de travail) qui seront effectués
Benchmarking

41
NoSQL
Puisque on ne peut pas accorder 16 ou 8 machines pour effectuer ce test, on va se
référer par des « Benchmark » déjà effectuer.
« Endpoint » effectue ce genre de « Benchmark » régulièrement.
Benchmarking

42
NoSQL
• Endpoint a utilisé pour ce test :
 32 instances Amazon EC2 (instance de class i2.xlarge [30.5 GB RAM, 4 CPU, 800 GB
SSD])
 Instance Amazon EC2 (instance de class c3.xlarge [7.5 GB RAM, 4 CPU]) comme
machine cliente
 Ubuntu 14.04 installé dans tous les instances
 YCSB (Yahoo! Cloud Serving Benchmark) installé dans l’instance cliente
 Un standard et framework libre pour le benchmarking NoSQL
• Afin de minimiser l'effet de la variabilité des E/S, le test a été effectué trois fois sur trois jours
différents. De nouvelles instances EC2 ont été utilisées pour chaque essai.
Benchmarking

43
NoSQL
• Les BDs testées:
Benchmarking

44
NoSQL
• Les workloads utilisés :
 Read-mostly workload: 95% lecture, 5% mise à jour
 Read/write: 50% lecture, 50% mise à jour
 Read-modify-write: 50% lecture, 50% lecture-mise à jour-écriture
 Insert-mostly/read: 90% insertion, 10% lecture
Benchmarking

45
NoSQL
Benchmarking
0
50000
100000
150000
200000
250000
300000
350000
1 2 4 8 16 32
Operations/sec
Load process
Cassandra Couchbase Hbase MongoDB

46
NoSQL
Benchmarking
0.00
50,000.00
100,000.00
150,000.00
200,000.00
250,000.00
1 2 4 8 16 32
Operations/sec
Read-mostly Workload

47
NoSQL
Benchmarking
0.00
50,000.00
100,000.00
150,000.00
200,000.00
250,000.00
300,000.00
350,000.00
1 2 4 8 16 32
Operations/sec
Balanced Read/Write Mix

48
NoSQL
Benchmarking
0.00
50,000.00
100,000.00
150,000.00
200,000.00
250,000.00
1 2 4 8 16 32
Operations/sec
Read-Modify-Write Workload

49
NoSQL
Benchmarking
0.00
10,000.00
20,000.00
30,000.00
40,000.00
50,000.00
60,000.00
70,000.00
80,000.00
90,000.00
100,000.00
1 2 4 8 16 32
Operations/sec
Insert-mostly Workload

50
NoSQL
Benchmarking
0.00
200,000.00
400,000.00
600,000.00
800,000.00
1,000,000.00
1,200,000.00
1,400,000.00
1,600,000.00
1,800,000.00
1 2 4 8 16 32
Latence(us)
Read-mostly Workload

51
NoSQL
Benchmarking
0.00
500,000.00
1,000,000.00
1,500,000.00
2,000,000.00
2,500,000.00
3,000,000.00
3,500,000.00
4,000,000.00
1 2 4 8 16 32
Latence(us)
Balanced Read/Write Mix

52
NoSQL
Benchmarking
0.00
1,000,000.00
2,000,000.00
3,000,000.00
4,000,000.00
5,000,000.00
6,000,000.00
7,000,000.00
8,000,000.00
9,000,000.00
1 2 4 8 16 32
Latence(us)
Read-Modify-Write Workload

53
NoSQL
Benchmarking
0.00
200,000.00
400,000.00
600,000.00
800,000.00
1,000,000.00
1,200,000.00
1,400,000.00
1,600,000.00
1,800,000.00
1 2 4 8 16 32
Latence(us)
Insert-mostly Workload

NewSQL
Définition et Comparaison

56
NewSQL
Autour du temps où les solutions NoSQL étaient en cours de développement, un groupe
différent de chercheurs et de développeurs adoptaient une approche différente. Au lieu de jeter
tout sur les systèmes de bases de données relationnelles, ils ont examiné l'architecture et le
traitement traditionnels des RDBMS pour tenter de comprendre ce qui l'empêchait d'étendre à
un plus grand nombre d'utilisateurs et de meilleures performances.

57
NewSQL
Ils ont pu identifier ces caractéristiques limitantes et les supprimer efficacement. Cela a
permis de créer une base de données hautement performante et évolutive qui conserve
certains des principaux avantages des bases de données relationnelles traditionnelles, comme la
conformité et les transactions ACID complètes, le support du langage SQL, etc. Ces nouveaux
systèmes basés sur SQL étaient collectivement Appelé NewSQL.

58
NewSQL
Caractéristiques SQL NoSQL
Relationnel
 
Prise en charge du langage
SQL
 *
Complètement conforme
ACID
 *
Évolutivité horizontale  
Schéma
 
High Performance  
NewSQL







60
Conclusion
Quand il s'agit de la performance, il faut noter qu'il n'y a aucun « Parfait » ou
« Gagnant » parmi les 4 bases de données NoSQL qu’on a testé ou tout autre base. Selon le cas
d'utilisation et les conditions de déploiement, il est presque toujours possible pour une base de
données NoSQL de surpasser une autre.

Base de données NoSQL

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Base de données NoSQL

Similaire à Base de données NoSQL (20)

Base de données NoSQL

Notes de l'éditeur