Bases de données Avancées

Nicolas Travers & Raphaël Fournier-S’niehotta

Dauphine – MIAGE

Contexte
• Applications et Plateformes Web
▫ Croissance de la quantité de données Exponentielle
▫ Volume à gérer sans précédents
. Besoin de distribuer les calculs et les données
. Nombreux serveurs
. Données hétérogènes, complexes et souvent liées
• Ex :
▫ Google, Amazon, Facebook
▫ Google DataCenter :
. 5000 servers/data center, ~1M de serveurs
▫ Facebook :
. 1 Péta Octets de données

SGBDR : Limitations
• Fonctionnalités
▫ Jointures entre les tables
▫ Construction de requêtes complexes
▫ Contraintes d’intégrité solides
• Contexte distribué
▫ Liens entre entités -> Même serveur
▫ ++ liens -> ++ placement complexe de données

SGBDR : Limitations (2)

• Propriétés ACID pour les transactions
▫ Atomicité, Cohérence, Isolation, Durabilité
• Contexte distribué :
▫ Contraintes ACID très complexes à vérifier
▫ Incompatible avec les performances
ACID vs BASE
• Systèmes distribués modernes utilisent le
modèle BASE
▫ Basically Available : garantie minimale pour taux
de disponibilité face grande quantité de requêtes
▫ Scalable : fonctionne avec un système de taille
importante
▫ Eventually consistent : tous les réplicas atteignent
le même état, après l’arrêt des mises à jour

La Solution : NoSQL
• NoSQL : Not Only SQL
▫ Nouvelle approche de stockage et de gestion de
données
▫ Permet le passage à l’échelle via un contexte
hautement distribué
▫ Gestion de données complexes et hétérogènes
. Pas de schéma pour les objets
• Ne remplace pas les SGBDR !!
▫ Quantité de données énorme (PétaBytes)
▫ Besoin de temps de réponses
▫ Cohérence de données faible
NoSQL BD : Principales
Caractéristiques
• Pas de relations
▫ Pas de schéma physiques ou dynamiques
• Données complexes
▫ Imbrication, tableaux
• Distribution de données (milliers de serveurs)
▫ Parallélisation des traitements (Map/Reduce)
• Replication des données
▫ Disponibilité vs Cohérence (no transactions)
▫ Peu d’écritures, Beaucoup de lectures

Partitionnement des données

• Sharding
▫ Fonction de hachage pour déterminer le
placement de paquets de données sur un
ensemble de serveurs
• Consistent Hashing
▫ Technique de hachage unique et dynamique pour
les données et les serveurs
▫ Distribution en anneau (virtuel)

Mises à jour
• Gestion concurrence multi-version
▫ Idem que dans SGBD
• Maj -> label sur l’ancienne version, ajout de la
nouvelle version
• Anciennes versions nettoyées périodiquement

Différents systèmes NoSQL

• Clé-valeur (Key-Value Store)
▫ Données identifiées par clé unique (utilisées pour
l’interrogation)
▫ DynamoDB, Voldemort, Redis, Riak, MemcacheDB
• Colonnes (Column data)
▫ Relation 1-n “one-to-many” (messages, posts)
▫ HBase, Cassandra, Hypertable
• Documents
▫ Données complexes, attributs/valeurs
▫ MongoDB, CouchDB, Terrastore
• Graphes
▫ Réseaux sociaux…
▫ Neo4j, OrientDB, FlockDB

I – NoSQL & Clé-Valeurs

• Similaires à un “HashMap” distribué
• Couple Clé+Valeur
▫ Pas de schéma pour la valeur (chaine, objet,
entier, binaires…)
• Conséquences :
▫ Pas de structure ni de types
▫ Pas d’expressivité d’interrogation (plus de pré/
post traitement)
Ø DynamoDB (Amazon), Redis (VMWare),
Voldemort (LinkedIn)

I - NoSQL & Clé-Valeurs (2)

• Opérations CRUD (HTTP)
▫ Create(key,value)
▫ Read(key)
▫ Update(key,value)
▫ Delete(key)
• Passage à l’échelle horizontal
(partionnement/distribution)
• Difficile au niveau vertical
(segmentation des données)

II – NoSQL & Colonnes

• Stockage des données par colonnes
▫ SGBD : tuples (lignes)
• Facile d’ajouter une colonne (pas une ligne)
▫ Schéma peut être dynamique (d’un tuple à l’autre)
Ø BigTable/Hbase (Google), Cassandra
(Facebook&Apache), SimpleDB (Amazon)

II – NoSQL & Colonnes (2)

• Avantages :
▫ Supporte le semi-structurées (XML, JSon)
▫ Indexation de chaque colonne
▫ Passage à l’échelle horizontal
• Désavantages :
▫ Lecture de données complexes ardue
▫ Difficulté de relier les données (distance,
trajectoires, temps)
▫ Requêtes pré-définies (pas à la volée)
III – NoSQL & Documents
• Basé sur le modèle clé-valeur
▫ Ajout de données semi-structurées (JSon ou XML)
• Requêtes : Interface HTTP
▫ Plus complexe que CRUD
Ø MongoDB, CouchDB (Apache), RavenDB,
Terrastore

III – NoSQL & Documents (2)

• Chaque valeur d’un attribut est un document
▫ Type simple existent (Int, String, Date)
▫ Schéma non nécessaire (peut varier d’un document à
l’autre)
▫ Imbrication de données
• Avantages :
▫ Simple mais forte puissance d’expression
▫ Interrogation de tout attribut (+indexation)
▫ Passe facilement à l’échelle
• Désavantages :
▫ Inter-connexion de données complexe
▫ Interrogation sur la clé (+index)

IV – NoSQL & Graph

• Stockage des noeuds, relations et propriétés
▫ Théorie des graphes
▫ Interrogation par traversée de graphe
▫ Appel des données sur demande (parcours
performants)
▫ Modélisation non triviale
Ø Neo4j, OrientDB (Apache), FlockDB (Twitter)

IV – NoSQL & Graph (2)

• Stockage pour
▫ les objets (cf. documents)
▫ les arcs (avec propriétés)
• Sharding/partitionnement difficile
Théorème de Brewer (2000)
Dit : “Théorème de CAP”
• 3 propriétés fondamentales pour les systèmes
distribués
1. Consistency: Tous les serveurs voient la même données
(valeur) en même temps (ou Coherence)
2. Availability: Si un serveur tombe en panne, les données
restent disponibles
3. Partition Tolerance: Le système même partitionné doit
répondre correctement à toute requête (sauf en cas de panne
réseau)
Ø Théorème : Dans un système distribué, il est
impossible que ces 2 propriétées coexistent,
vous devez choisir 2 d’entre elles.
DONNÉES
SEMI-STRUCTURÉES
AVEC JSON
JSon : En pratique
• XML utilisé initialement pour les échanges de
communications Machine/Machine
▫ Trop verbeux et couteux en place
• JSON (JavaScript Object Notation)
▫ Léger, orienté texte, indépendant d’un langage
d’interrogation
▫ Utilisé par certains Web Services (Google API, Twitter
API) ou web dynamique (Ajax)
JSon : Structures
• CLE + VALEUR
▫ “nom” : “Travers”
▫ Clés avec des guillemets, ne pas utiliser ”.-,”
• Objet : collection de pairs “noms/valeurs”
▫ Encapsulé dans des accolades
▫ { “nom” : “Travers”,
“prenom” : “Nicolas”,
“genre” : 1}
• Liste ordonnée de valeurs
• “liste” : [“SQL”, “XML”, “NoSQL”, “Optimisation
BD”, “Recherche d’Information”]

Documents JSon
• Principe : Clé-Valeur
▫ “nom” : “Travers”
• Types de données
▫ Atomique : String, Integer, flotants, booléens…
▫ Liste : tableaux
▫ Documents : objets {…}
Dauphine –

Liste de valeurs : précisions

• Pas de contraintes sur le contenu de la liste
▫ “cours” : [“SQL”, 1, 4.2, null, “Recherche d’Information”]
• Peut contenir des objets
▫ “doc” : [{“test” : 1},
{“test” : {“imbrication” : 1.0}},
{“test” : “texte”, “valeur” : null}]

JSon : Identifiant
• La clé « _id » est communément utilisée pour
identifier un objet
▫ Dans une base, l’objet de même identifiant écrase
la version précédente
▫ Peut être défini automatiquement
. Exemple MongoDB : "_id" : ObjectId(1234567890)

JSon : Exemple complet

{
“_id” : 1234
“nom” : “Travers”, “prenom” : “Nicolas”,
“travail” : {
“Etablissement” : “Cnam”,
“localisation” : {
“rue” : “2 rue conté”,
“ville” : “Paris”,
“CP” : 75141
},
},
“themes” : [ “BD” , “Optimisation BD”, “XML”, “NoSQL”, “RI” ]
}

NoSQL vs Joins
• Contexte distribué = lien entre les données
complexe
• Si l’on considère deux collections de documents
JSon
▫ Pour une jointure entre les deux collections
. Sur quel serveur se fait la jointure ?
. Distribution des données à joindre ?
. Problème de coût (plus cher qu’en local)

Jointures : Solutions (1/3)

1. Effectuer la jointure dans l’application
▫ Récupérer les éléments de coll1
▫ Pour chaque élément de coll1, interroger coll2
▫ Peut être très couteux
▫ Equivalent relationnel d’une boucle imbriquée avec
index non optimisée
2. Réunir le tout dans une même collection
▫ Avec MapReduce créer la jointure dans le
« Reduce » en groupant par valeur de jointure
▫ Coût du « shuffle » augmenté, ainsi que toute
requête sur une des deux collections
▫ Equivalent relationnel d’un index de type Cluster

Jointures : Solutions (2/3)

3. Dénormaliser le schéma
▫ Réunir les informations des deux collections en un même
document lorsque c’est possible
▫ Créer des sous-documents imbriqués contenant les
valeurs jointes
▫ Problème de cohérence des données (répétitions)
▫ Equivalent au résultat de la jointure
▫ Demande un travail de réflexion et de modélisation
. Préférer la dimension : distributivité
▫ Dans l’exemple de document JSon précédent, quel a été
le travail de dénormalisation ?

Jointures : Solutions (3/3)

4. Framework d’exécution de jointure sur les serveurs
▫ Les données de jointures sont distribués sur les serveurs
pour un calcul local
▫ La base NoSQL doit permettre cette distribution (ex:
Hadoop/Pig)
▫ Dépend de la taille de la collection à distribuer
. Algorithmes de jointure basés sur le relationnel (hachage, trifusion)

Conclusion
• NoSQL :
▫ Dédié à un contexte extrêmement distribué
▫ Calcul fortement distribué
▫ 4 types de calculs complexes (clé-valeur,
document, colonnes, graphes)
• Ne doit pas remplacé automatiquement un
SGBD
▫ Propriétés ACID
▫ Requêtes complexes
▫ Performance de jointure
Web 2.0 et les limites des
modèles
relationnels
▶ Beaucoup de donnees
● Digg 3TB
● Facebook 50TB

● Ebay 2PB

▶ Beaucoup d'utilisateurs
▶ Beaucoup de trafic
▶ Et les bases relationnelles pour
gerer tout
cela ?

ACID contre BASE

▶ Atomique
▶ Coherente
▶ Isolee
▶ Durable
▶ Basically Available
▶ Soft state
▶ Eventually consistent

MapReduce
▶Introduit par Google
▶2 etape
● Etape Map → itere sur une liste
d'elements
independants et accomplit une operation
specifique
sur chaque element
 function(doc){}
●Etape Reduce → prend une liste et
combine les
elements selon un algorithme particulier
 fonction(keys, values, rereduce){}
[4] : 9_base_de_données_NoSQL.pdf

NoSQL
•Fournit un modèle de base de données différent du modèle relationnel
ou objet

•NoSQL veut dire « Not Only SQL »

•Les modèles pour les bases de données NoSQL datent des années
1960

•Regain de popularité vers la fin des années 2000

NoSQL
•Principalement utilisé sur des clusters de serveurs

•Permet un modèle qui peut s’étendre plus facilement (scalability)

•Assouplit les contraintes habituellement présentes sur les bases de données

relationnelles

•Permet de gérer rapidement des tonnes de données

NoSQL
•Lesentreprises du WEB 2.0 avaient besoin de solutions
technologiques plus adaptées à leurs besoins
•Développement des systèmes NoSQL propriétaires
•Facebook Cassandra, Hbase

•Google BigTable
•LinkedIn Projet Voldemort

•Amazon DynamoDB, SimpleDB

•Twitter Cassandra

Théorème CAP
•Énoncé par Eric Brewer en 1999

•Indique
qu’il est impossible, pour un système distribué, de garantir en
même temps les trois contraintes suivantes
•Cohérence : Tous les noeuds du système voient les mêmes données au même moment

•Disponibilité : Toutes les requêtes reçoivent une réponse

•Tolérance au partitionnement : Aucune panne ne doit empêcher le système de répondre

correctement (sauf une coupure complète du réseau)
•Il est possible de garantir 2, mais pas 3 contraintes

Théorème CAP
•Habituellement,un système de gestion de base de données garantit la
cohérence et la disponibilité

•Il
existe par contre un temps incompressible entre la mise à jour d’un
noeud et sa synchronisation avec les autres

•Ce temps peut avoir un grand impact sur un système très chargé

Théorème CAP
•Lesbases de données NoSQL tendent à privilégier la
disponibilité et la tolérance au partitionnement
•Il
peut être préférable que deux personnes faisant la même
recherche sur Google obtiennent des résultats différents que
pas de réponses du tout
•Facebook, Twitter, etc. utilisent le même principe

Théorème CAP
•Les bases de données NoSQL sont pratiques dans certaines situations
•Requiert une bonne tolérance au partitionnement

•Requiert une disponibilité à toute épreuve

•Gère un énorme trafic simultané sur un système distribué

•Les bases de données relationnelles peuvent aussi répondre à ces critères
•Souvent plus difficiles à mettre en place par contre

NoSQL - Types
•Il existe différents types de bases de données NoSQL
•Colonne

•Clé/Valeur

•Document

•Graphe

•Etc.
•Les types Document et Graphe sont basés sur le type Clé/Valeur

NoSQL - Colonne
•Les données sont sauvegardées dans des colonnes
•L’inverse des BD relationnelles où les données sont par rangées

•Offre une très grande vitesse

•Très efficace lorsque les données des colonnes se ressemblent

•Adapté à l’interrogation de données

•Peu efficace pour la mise à jour des données

NoSQL – Clé/Valeur
•Chaque entrée de la base de données est représentée par une clé et
une valeur quelconque

•La valeur est une donnée non structurée

•Permet de sauvegarder une très grande quantité de données

facilement

•La recherche dans les valeurs n’est pas évidente

•Les données n’ont aucune structure

NoSQL – Document
•Spécialisation du concept de clé/valeur
•La valeur est un document
•Forme structurée d’une valeur

•Les documents n’ont pas à être tous pareils

•Permet une recherche plus efficace dans les données

•Les documents ont habituellement un format particulier
•XML, JSON, BSON, etc.

NoSQL – Graphe
•Basé sur la théorie des graphes
•Pratiquelorsque les relations entre les données peuvent être
représentées sous forme de graphes

•Plus complexe à utiliser

•Lesrequêtes et les mises à jour de grandes quantités de données

peuvent être très lentes

Paradigme ACID - BASE

•L’acronyme ACID veut dire
•Atomique (Atomicity)

•Consistent (Consistency)

•Isolation (Isolation)

•Durable (Durability)
•L’acronyme BASE veut dire
•Basically Available, Soft state, Eventual consistency
•Les bases de données relationnelles et
orientées objet respectent les
principes ACID, les bases de données NoSQL respectent les principes
BASE

Paradigme ACID - BASE

•Atomique (Atomicity)
•Chaque transaction est effectuée en entier ou pas du tout
•Consistent (Consistency)
•Toutes les données écrites respectent les contraintes d’intégrités

•L’état de la base de données est toujours valide

•Isolation (Isolation)
•Une exécution en parallèle des transactions donne le même résultat qu’une
exécution en série
•Durable (Durability)
•Une fois les données écrites, elles restent écrites

Paradigme ACID - BASE

•Lesprincipes ACID impliquent qu’une base de données répartie sur plusieurs
serveurs doit retourner les mêmes valeurs pour une même requête

•C’est problématique dans certaines situations

•Certains logiciels peuvent fonctionner même si les résultats ne sont pas les
mêmes
•Est-ce grave si votre page Facebook n’affiche pas exactement tout ce que vos amis viennent de
publier, tant qu’éventuellement, vous êtes capable de voir ces publications?

Paradigme ACID - BASE

•Les systèmes NoSQL fonctionnent sur ce principe
•Lesdonnées et l’état de la base de données seront
éventuellement cohérents et consistants
•L’important est que l’accès soit toujours permis

•Ne s’appliquent pas à tous les problèmes

•Un système de transaction en ligne ne peut se permettre cette relaxation des
contraintes!

Paradigme ACID - BASE

•Si
la cohérence des données est primordiale, les systèmes
NoSQL ne sont probablement pas les plus intéressants
•Quoi faire lorsqu’on a besoin d’un système distribué
•Pour répondre à un fort achalandage

•Qui garantit la cohérence des données

•Qui garantit les propriétés ACID?

Base de données NewSQL
•Un nouveau type de base de données relationnelle
•Cherche à fournir la même puissance évolutive que les bases
de données NoSQL, mais en garantissant les propriétés ACID
standards
•Pourra peut-être réconcilier SQL et NoSQL?
[4]: Big data & nosql Rédigé par : Belhaj Hajar & Khanoun Chaimae et Encadré par : Mr Badir Hassan

Chaque jour, nous générons plus que 3 trillions d’octets de

données . Dont 90% des données dans le monde ont été
créées au cours des deux dernières années seulement.
Ces données proviennent de partout : Des messages sur les
sites, d'images numériques, d'enregistrements transactionnels
d'achats en ligne et de signaux GPS de téléphones mobiles …….
Aujourd’hui le stockage et interrogation de ces données
deviennent très difficiles avec des outils classiques (SGBDR).
Les sites tels que Facebook, Twitter et d'autres ont lutté
avec ce problème pendant des années. Ils ont grandi de
quelques milliers à des millions et maintenant des centaines de
millions d'utilisateurs.
Les phénomènes Big Data & NoSQL ne cessent de prendre de
l'ampleur, et constituent probablement l'un des nouveaux
enjeux majeurs de demain.

1- Définition
Big Data est un terme populaire
utilisé pour décrire la croissance
exponentielle, la disponibilité et
l'utilisation des informations
structurées ou bien non
structurées.
"Big Data" est un terme appliqué
à des ensembles de données dont
la taille est au-delà de la capacité
des outils logiciels couramment
utilisés pour capturer, gérer et
traiter les données dans un délai
écoulé étant acceptable.
La taille de Big Data est une
cible mouvante, à partir de 2012
allant de quelques dizaines de

téraoctets à plusieurs pétaoctets

de données dans un seul
ensemble de données.
(Un pétaoctet (dérivé du préfixe SI
peta-) est une unité d'information
égale à un quadrillion (échelle
courte) octets ou 1024 téraoctets.
Le symbole de pétaoctet est PB.
Peta Le préfixe (P) indique la
cinquième puissance à 1000:
( 1 PB =
1000000000000000B =
10005 B = 1015 B = 1
million de giga-octets = 1
000 téraoctets)

2- Caractéristiques de Big Data

 Volume :
De nombreux facteurs
contribuent à l'augmentation du
volume des données - basés sur
les transactions de données

stockées au fil des ans, des

données textuelles constamment
en streaming des médias sociauxet
des quantités croissantes de
données du capteur sont
recueillis.
Dans le passé, le volume de
données excessif a créé un
problème de stockage. Mais avec
la diminution actuelle de coûts de
stockage, autres questions
apparaissent, y compris la façon
de déterminer la pertinence -au
milieu des grands volumes de
données- et la façon d’extraire la
valeur à partir de ces données.
 Variété :
Les données d'aujourd'hui
viennent dans tous types de
formats - de bases de données
traditionnelles aux magasins
hiérarchiques de données créés
par les utilisateurs finaux et les
systèmes OLAP, aux documents
texte, email, vidéo, audio, stock
ticker de données et aussi les
transactions financières-. Selon
certaines estimations, 80% des
données d'une organisation ne
sont pas numériques! Mais ils
doivent encore être inclus dans
les analyses et aussi dans la prise
de décision.
 Vitesse :
Selon Gartner, la vitesse
signifie « à la fois la rapidité de
production de données et à quelle
vitesse les données peuvent être
traitées pour satisfaire la
demande ». Les étiquettes RFID et
les compteurs intelligents
conduisent un besoin croissant
pour faire face aux torrents de
données en temps quasi-réel.
Réagissant assez rapidement pour
faire face à la vitesse est un défi
pour la plupart des organisations.
 Complexité :
Lorsqu’on travaille avec des
énormes volumes de données, on
sait que ces données proviennent
de multiples sources. Cependant,
il est nécessaire de se connecter
et de corréler les relations, les
hiérarchies et les multiples liens
de données sinon ces données
peuvent rapidement échapper de
tout contrôle.
La gouvernance des données
peut aider à déterminer comment
disperser les données se
rapportant à des définitions
communes et comment intégrer
systématiquement les actifs de
données structurées et non
structurées pour produire une
information de qualité qui soit
utile, appropriée et mise à jour

3- Utilisations de Big Data

Dans la dernière année, le Big
data a émergé comme l'une des
tendances les plus étroitement
surveillés dans les IT. Aujourd'hui,
les entreprises générant plus de
données en une seule journée que
l’internet a générée récemment
en 2000.
L'explosion des Big data -une
grande partie de Big data est
complexe et de formats non
structurées -a présenté aux
entreprises une formidable
opportunité de tirer parti de leurs
données pour des analyses
commerciales par le biais de
meilleures analyses.
Wal-Mart a été l'un des pionniers
dans ce domaine, en utilisant
l'analyse prédictive afin de mieux
identifier les préférences des
clients sur une base régionale et
de stocker leurs succursales en
conséquence. Il s'agissait d'une
tactique très efficace qui a donné
un fort retour sur investissement
et leur a permis de se séparer du
paquet de détail. D'autres
industries qui ont pris
connaissance de la tactique de
Wal-Mart ont recueilli un grand
succès lors le traitement et
l’analyse de leurs données et ont
commencé à employer les mêmes
tactiques.
Alors que l'analyse de données
était autrefois considérée comme
un avantage concurrentiel, elle
est de plus en plus considérée
comme une nécessité pour les
entreprises, ce qui a donné
naissance à un mouvement très
important des sciences de
données. Les données ont un
atout considérable pour les
entreprises, et ces dernières
commencent à les traiter en
conséquence.
Dans cet esprit, voici quelques cas
d’utilisations :
 Analyser des millions de
références pour déterminer
les prix optimaux qui
maximisent les bénéfices et
optimisent les stocks.
 Recalculer les portefeuilles
de risques entiers en
quelques minutes et
comprendre les possibilités
futures pour les risques.
 Les données des clients de
mines pour des idées
conduisant de nouvelles
stratégies pour l'acquisition
de clients, la fidélisation
campagne d'optimisation et
prochaines meilleures
offres.