Bases de Données Avancées

DataWareHouse et NoSQL
Introduction

Thierry Hamon

Bureau H202
Institut Galil�e - Universit� Paris 13
&
LIMSI-CNRS
hamon@limsi.fr
https://perso.limsi.fr/hamon/Teaching/P13/BDA-INFO2-2018-2019/

INFO2 – BDA

1/69
 Sources des transparents

F. Boufares, LIPN, Université Paris Nord

P. Marcel, LI, Université de Tours
Bernard Espinasse, Ecole Polytechnique Universitaire de
Marseille
Melanie Herschel, Université Paris Sud

2/69
 Introduction

Quelle quantité d’information ? sous quelle forme ?

Il y a plus de 15 ans !

en 2000 :
entre 1 et 2 ExaOctets par année (1 Eo = 220 To)
90% électronique
taux de croissance annuel de 50 %
en 2003 : 5 Eo en 2002, 92% électronique
Lyman&Varian, 2003 (http://groups.ischool.berkeley.edu/archive/
how-much-info-2003/execsum.htm)

Comment accèder à ces données, tirer partie de ces données ?

→ Les bases de données ne suffisent plus

3/69
 BD → ED

Des bases de données aux Entrepôts de données

4/69
 BD → ED

Introduction
Avant les entrepôts de données/Data Warehouses

La majeure partie des applications Bases de Données reposent

aujourd’hui sur trois couches :
La couche la plus externe est celle de qui permet de présenter
les données aux utilisateurs.
Elle est appelée Graphical User Interfaces GUI.
La couche application intermédiaire inclut le programme de
l’application
Elle ne stocke pas les données.
La couche la plus interne gère le stockage des données.
Elle est appelée la couche Base de Données.

5/69
 BD → ED

Introduction

Couche Présentation Graphical User Interfaces GUI GUI

Couche Application OLTP Application OLTP Application Decision support System

Read, Select
Insert, Update, Delete

Couche Base de Données BD1 BD2

Ressources externes
(file system, ftp, www, ...)

6/69
 BD → ED

Introduction
Les applications interrogent les données avec, par exemple,
le langage SQL (Select)
et les mettent à jour par l’intermédiaire des opérations
Insert, Update et Delete
qui constituent des transactions.

Celles-ci doivent avoir certaines propriétés ACID (Atomicité,

Cohérence, Isolation et Durabilité)

Ce type d’application est appelé On-Line Transaction Processing

OLTP.

7/69
 BD → ED

Introduction
Données volumineuses & Besoins nouveaux
Vers les entrepôts de données

→ Systèmes d’Information Décisionnel

Systèmes d’Aide à la Décision (DSS) :

Rapports, Etats, Tableaux de Bord, Graphiques, Synthèses,
Groupement, Agrégat, Résumé ...
(Reporting Tools, Management Information System, Executive
Information System, Decision Support System DSS)

8/69
 BD → ED

Introduction
Vers les entrepôts de données
Remarques

Contrairement aux applications OLTP, qui consultent et

mettent à jour les données des BD opérationnelles,
les DSS lisent les données seulement pour avoir de
nouvelles informations à partir des données sources
Bénéfice de cette approche : seules les BD opérationnelles ont à
être créées et maintenues

Un ensemble de méta-données est utilisés pour les 2 systèmes.

Les DSS ne nécessitent que des travaux supplémentaires
mineurs.

9/69
 BD → ED

Introduction
Vers les entrepôts de données
Remarques

Cependant, il y a plusieurs désavantages :

(quand le DSS et les application OLTP se partagent les mêmes BD)
Un DSS ne peut utiliser que les données actuellement stockées
dans les BD
les analyses historiques sont donc souvent impossibles à cause des
opérations de mises à jour qui changent les données historiques
L’utilisation des BD en mode multi-utilisateurs
ce qui implique des opérations de verrouillage des données (Locking
operations) et donc des problèmes de performance
car les requêtes analytiques demandent l’accès à de très grands
nombre de tuples.

10/69
 BD → ED

Introduction

La solution est de séparer

la BD orientée Transaction
de la BD orientée Aide à la Décision
d’où la naissance du concept
Entrepôt de Données = Data Warehouse.
Les DWH sont physiquement séparés des SGBD opérationnels (BD
opérationnelles)

11/69
 BD → ED

Introduction
Définition rapide d’un Data Warehouse

Le Data Warehouse est une collection de données orientées sujet,

intégrées, non volatiles, historisées, organisées pour le support d’un
processus d’aide à la décision
Un système de DWH peut être formellement défini comme un
triplet
<BD cible, méta-données, un ensemble d'opérations>

L’ensemble des opérations associées peut être présenté en 4

catégories (ETL, Agrégation et Groupement)

12/69
 BD → ED

Architecture des DWHs

Méta−données

Extraire
Sources externes
Nettoyer

Transformer
Utiliser
Charger (Load)
Intégrer

Rafraichir
Entrepot de données OLAP
Maintenir

BD opérationnelles

13/69
 BD → ED

Introduction

Le DWH intègre des données à partir de sources multiples et

hétérogènes
afin de répondre aux requêtes du système d’aide à la décision.
Ce type d’application est appelé On-Line Analytical
Processing OLAP
OLAP permet la transformation des données en informations
stratégiques

14/69
 BD → ED

Nouveaux concepts/nouvelle perspective

Entrepôt de données
récolte, stockage et gestion efficace des gros volumes de
données
OLAP
requêtes interactives complexes sur ces volumes
Data mining (fouille de données)
extraction automatique de propriétés cachées
données → information → connaissances

15/69
 BD → ED

Analyse OLAP
(On-Line Analytical processing)

Techniques OLAP :
apparition en recherche dans les années 70
mais développement dans les années 90 dans l’industrie
Réalisation de synthèses, d’analyses et de la consolidation
dynamique de données multidimensionnelles
Manière la plus naturelle d’exploiter un ED étant donné son
organisation multidimensionnelle

16/69
 BD vs. DWH

Introduction : Comparaison
Pourquoi pas des SGBDs pour les entrepôts de données ?
les 2 systèmes sont performants
SGBD : calibré pour l’OLTP ; méthodes d’accès index,
contrôle de concurrence, reprise
Entrepôt : calibré pour l’OLAP ; requêtes OLAP complexes,
vue dimensionnelle, consolidation
Fonctions et données différentes
Données manquantes : l’aide à la décision (AD) a besoin des
données historiques qui ne se trouvent pas dans les BD
opérationnelles
Consolidation : l’AD a besoin de données consolidées
(agrégats) alors qu’elles sont brutes dans les BD
opérationnelles

17/69
 BD vs. DWH

Introduction : Comparaison
SGBD hétérogènes vs. Entrepôts de données
Traditionnellement, l’intégration de BD hétérogènes se fait par
le biais de
Wrappers/médiateurs au dessus des BD hétérogènes
Approches orientées requêtes
Quand une requête est posée sur un site client, un
métadictionnaire est utilisé pour la traduire en plusieurs
requêtes appropriées à chacune des BD. Le résultat est
l’intégration de réponses partielles
L’exécution des requêtes demande donc beaucoup de
ressources
Entrepôts de données : approche orientée mise à jour
les informations sont intégrées et stockées pour une
interrogation directe
Plus efficace en coût d’exécution des requêtes

18/69
 BD vs. DWH

Introduction : Comparaison

BD opérationnelle vs. Entrepôts de données

OLTP (On-Line Transaction Processing)
Exécution en temps réel des transactions, pour
l’enregistrement des opérations quotidiennes : inventaires,
commandes, paye, comptabilité
Par opposition au traitement en batch
OLAP (On-Line Analytical Processing)
Traitement efficace des requêtes d’analyse pour la prise de
décision qui sont par défaut assez complexes (bien qu’a priori,
elles peuvent être réalisées par les SGBD classiques)

19/69
 BD vs. DWH

Introduction : Comparaison

BD opérationnelle vs. Data Warehouse : OLTP vs. OLAP

Données : courantes, détaillées vs. historiques, consolidées
Conception : modèle ER + application vs. modèle en étoile +
sujet
Vues : courantes, locales vs. évolutive, intégrée
Mode d’accès : mise à jour vs. lecture seule mais requêtes
complexes

20/69
 BD vs. DWH

Architecture du DWH
Architecture Multi-tiers
Data select
Dictionnaire de (requetes)
OLAP SERVER
Méta−données

100
0
Oracle Express 011
100
11
MVS (TSO, DB2 ...)

Business Objects
(rapports, analyses)
E(xtract)
T(ransform)
L(oad) DataWareHouse
111
0
0
100
00
11
UNIX (Oracle, ...) Oracle 9i (Olap)

SAS
(Datamining)

111
0
000
100
11
Windows (SQL Server, Data Marts
Excel, ...)

Applications en Controle et chargement des données OLAP Outils Front−End

production

21/69
 BD vs. DWH

Conception logique des DWHs

Données multidimentionnelles
Montant des ventes comme une fonction des paramètres
produits, mois, région

Dimensions : Produit, Lieu, Temps

Chemins de consolidation hiérarchiques
on
Régi
Région Année
Industrie

Pays Trimestre
Catégorie
Produit

Ville Mois
Semaine
Produit
Magasin Jour

Mois

22/69
 Applications

Domaines d’application

Ceux de l’informatique décisionnelle (Business Intelligence)

pour
aider atteindre les objectifs stratégiques d’une entreprise et
faciliter son pilotage
avoir une connaissance plus approfondie de l’entreprise
anticiper les besoins clients
prendre en compte les nouveaux canaux de distribution (vente
en ligne, etc.)

23/69
 Applications

Domaines d’application
Informatique décisionnelle
Entrepôt de données
Outils de veille stratégique et de recueil d’information
(intelligence économique)
Aide aux décideurs pour prendre les bonnes décisions sur la
base des données disponibles
Exemples :
Quels sont les 5 produits les plus vendus pour chaque
sous-catégorie de produits qui représente plus de 20% des
ventes dans sa catégorie de produits ?
Quelle est la priorité d’expédition et quel est le revenu brut
potentiel des commandes de livres qui ont les 10 plus grandes
recettes brutes parmi les commandes qui n’avaient pas encore
été expédiées ?

24/69
 Applications

Applications

Commerce, finance, transport, télécommunications, santé, services,

...
gestion de la relation client
gestion des commandes, des stocks
prévisions de ventes
définition de profil utilisateur
analyse de transactions bancaires
détection de fraudes
...

25/69
 Applications

Principales applications autour d’un ED

Réalisation de rapports divers (Reporting)

Réalisation de tableaux de bords (Dashboards)
Fouille de données (Data Mining)
Visualisations autour d’un ED (visualizations)
...

26/69
 Applications

Exemple d’application
Domaine bancaire
Un des premiers utilisateurs des ED
Regroupement des informations relatives à un client pour une
demande de crédit
Lors de la commercialisation d’un nouveau produit :
Mailing ciblés rapidement élaborés à partir de toutes les
informations disponibles sur un client
Recherche de fraudes sur les cartes de crédit :
Mémorisation des mouvements et contrôles a posteriori, pour
détecter les comportements suspects
Échanges d’actions et de conseils de courtages
Déterminer des tendances de marchés grâce à :
la mémorisation de l’historique
une exploitation par des outils décisionnels avancés

27/69
 Définition d’un DWH

Construction et d’exploitation d’un entrepôt de données

Processus en 3 phases :
1 Construction de la BD décisionnelle
Modélisation conceptuelle des données multiformes et multi-sources
Conception de l’entrepôt de données
Alimentation de l’entrepôt (extraire, nettoyer, transformer, charger)
Stockage physique des données
2 Sélection des données à analyser
Besoins d’analyse de l’utilisateur
Data marts (Magasins de données)
Cubes multidimensionnels
Tableaux ou tables bidimensionnels
3 Analyse des données
Stastiques et reporting, OLAP, Data Mining

28/69
 Définition d’un DWH

Présentation des couches

Couche Présentation Graphical User Interfaces GUI GUI

Couche Application OLTP Application OLTP Application Decision support System

Insert, Update, Delete Read, Select

Couche Base de Données BD2

BD1
Target DataBase

Load
DataWareHouse

Ressources externes
(file system, ftp, www, ...)

29/69
 Définition d’un DWH

Architecture du DWH
Architecture Multi-tiers
Data select
Dictionnaire de (requetes)
OLAP SERVER
Méta−données

100
0
Oracle Express 011
100
11
MVS (TSO, DB2 ...)

Business Objects
(rapports, analyses)
E(xtract)
T(ransform)
L(oad) DataWareHouse
111
0
0
100
00
11
UNIX (Oracle, ...) Oracle 9i (Olap)

SAS
(Datamining)

111
0
000
100
11
Windows (SQL Server, Data Marts
Excel, ...)

Applications en Controle et chargement des données OLAP Outils Front−End

production

30/69
 Définition d’un DWH

Opérations
Extraction (Extraction) : Ces opérations permettent de filtrer les
données à partir de données sources (BD, fichiers, sites web...) dans
des BD temporaires.
Transformation (Transformation) : Ces opérations permettent de
transformer les données extraites dans un format uniforme.
Les conflits entre les modèles, les schémas et les données sont
résolus durant cette phase.
Chargement (Load) : Ces opérations permettent de charger les
données transformées dans la BD cible.
La BD cible est souvent implantée avec un SGBD relationnel-objet.
Agrégat et Groupement (Agregating and Grouping) : La BD cible
doit permettre de stocker les données opérationnelles et les données
issues de calculs.

31/69
 Architecture

Architecture

Objectifs :
regrouper les données sources
concevoir le schéma de l’entrepôt
remplir l’entrepôt
maintenir l’entrepôt

32/69
 Architecture fonctionnelle

Architecture fonctionnelle de l’entrepôt

Les données d’un entrepôt se structurent suivant
un axe synthétique : établissement d’une hiérarchie
d’agrégation incluant
les données détaillées : les événements les plus récents
les données agrégées : synthèse des données détaillées
les données fortement agrégées : synthèse à un niveau
supérieur des données agrégées
un axe historique
incluant les données détaillées historisées représentant les
événements passés
→ Stockage des méta-données : informations concernant les
données de l’ED (provenances, structures, méthodes utilisées pour
l’agrégation, ...)

33/69
 Architecture fonctionnelle

Entrepôts et magasins de données

Data Warehouses et Data marts

Entrepôts de données
Collecte l’ensemble de l’information utile aux décideurs à partir
des sources de données (BD opérationnelle, BD externes, ...)
Centralisation de l’information décisionnelle
Garantie de l’intégration des données extraites et de leur
pérennité dans le temps
Magasins de données
Orientés sujet
Aide efficace aux processus OLAP
Extraction d’une partie des données utiles :
pour une classe d’utilisateurs ou
pour un besoin d’analyse spécifique

34/69
 Architecture fonctionnelle

Dictionnaire et méta-données

Dictionnaire contenant des informations (méta-données) sur :

toutes les données de l’ED
chaque étape de la construction de l’ED
le passage d’un niveau de données à un autre (exploitation de
l’ED)
Rôle : définition, fabrication, stockage, accès et présentation
des données

35/69
 Données sources

Données sources
Les données des entreprises sont généralement :
Surabondantes
Eparpillées
Peu structurées pour l’analyse
Modifiées quotidiennement
Problème : Prise de décision difficile
Solution : Utilisation d’outils et de techniques visant à préparer les
données pour l’analyse Data warehousing
Il s’agit d’une technique visant à extraire des données de
différentes sources afin de les intégrer selon des formats
plus adaptés à l’analyse et la prise de décision
→ Problématique d’intégration et définition de wrappers

36/69
 Données sources

Données sources hétérogènes

Nécessité d’intéger des données hétérogènes, modifiées
quotidiennement
BD
relationnelles
objets
distribuées
fichiers textes
documents HTML, XML
bases de connaissances
...
Mais aussi des représentations de données et de noms de
champs/colonnes hétérogènes

37/69
 Alimentation de l’ED

Processus d’alimentation d’un ED

Entreposage des données

Rôle de l’alimentation de l’entrepôt

rassembler de multiples données sources souvent
hétérogènes
homogénéiser les données sources
Homogénéisation réalisée selon des règles précises
Les règles d’homogénéisation sont :
mémorisées sous forme de méta-données stockées dans le
dictionnaire de données
utiliser pour assurer des tâches d’administration et de
gestion des données entreposées

38/69
 Alimentation de l’ED

Processus d’alimentation d’un ED

4 étapes :
1 Sélection des données sources
2 Extraction des données
3 Nettoyage et Transformation
4 Chargement

Etapes 1 et 2 : Jusqu’à 80 % du temps de développement d’un

entrepôt

→ outil : Oracle Warehouse Builder (OWB)

39/69
 Alimentation de l’ED

Extraction des données

Un extracteur (wrapper) est associé à chaque source de données

Sélection et extraction des données
Formatage des données dans un format cible commun
en général, le modèle Relationnel
Utilisation d’interfaces comme ODB, OCI, JDBC

40/69
 Alimentation de l’ED

Transformation

Objectif : suppression des incohérences sémantiques entre les

sources, problématique lors de l’intégration
des schémas
des données

41/69
 Alimentation de l’ED

Transformation

Résolution des problèmes survenant lors de l’intégration des

schémas
Demande une solide connaissance de la sémantique des
schémas
Peu traitée par les produits du marché
Nombreux travaux de recherche
Opération généralement réalisée à la main...

42/69
 Alimentation de l’ED

Chargement des données

Objectif : Stockage des données nettoyées et préparées dans la BD
opérationnelle (ODS)

Opération :
risquant d’être assez longue
plutôt mécanique
la moins complexe
Mais il est nécessaire de définir et mettre en place :
des stratégies pour assurer de bonnes conditions à sa
réalisation
une politique de rafraîchissement

43/69
 Alimentation de l’ED

Chargement des données

Définitions de vues relationnelles sur les données sources

Matérialisation des vues dans l’entrepôt
Mais aussi, préparation à la restitution
tris
consolidations (pré-agrégation)
indexation
partitionnement des données
enregistrement de méta-données
...

44/69
 Alimentation de l’ED

Préparation à la restitution

Agrégation
Calcul de vues agrégées
Définition des indexes
Stockage dans le CDW
Personnalisation
Construction de magasin de données (Data Marts)
Construction de cubes de données
Construction des présentations demandées par les utilisateurs

45/69
 Modélisation

Modélisation multidimensionnelle
Lien direct entre les analyses décisionnelles (OLAP) et une
modélisation de l’information conceptuelle :
proche de la perception qu’en a l’analyste
basée sur une vision multidimensionnelle des données
Modèle multidimensitionnel : les données sont vues comme des
data cubes
Un cube de dimension n est dit un cuboïde
Le treillis des cuboïdes d’un entrepôt de données forme un
data cube
La modélisation multidimensionnelle a donné naissance aux
concepts de fait et de dimension (Kimball 1996)

46/69
 Modélisation

Cube de données

47/69
 Modélisation

Exemple de treillis de cube

48/69
 Modélisation

Cube de données

Sujet analysé : un point dans un espace à plusieurs dimensions

Organisation des données pour mettre en évidence le sujet
analysé et les différentes perspectives de l’analyse
data cube (par exemple, les ventes) : vision des données sur
plusieurs dimensions

49/69
 Modélisation

Concept de fait
Un fait :
modélisation du sujet de l’analyse
Mesures correspondant aux informations de l’activité analysée
Mesures numériques, généralement valorisées de façon
continue. On peut
les additionner
les dénombrer
calculer le minimum, le maximum ou la moyenne
Exemple : le fait de Vente peut être constitué des mesures
d’activités suivantes :
quantité de produits vendus
montant total des ventes

50/69
 Modélisation

Concept de dimension
Axes ou perspectives caractérisant es mesures de l’activité d’un fait
Une dimension :
modélisation un axe d’analyse
nécessité pour chaque dimension, de définir ses différents
niveaux de détail
→ Définition de une (ou plusieurs) hiérarchie(s) de paramètres
se compose de paramètres correspondant aux informations
faisant varier les mesures de l’activité
Dans l’exemple précédent :
Analyse du fait Vente suivant différentes perspectives correspondant
à trois dimensions :
la dimension Temps
la dimension Geographie
la dimension Categorie

51/69
 Bilan

Conclusion et perspectives

Deux tendances actuelles

datamarts
dataweb
construction du Data Warehouse : processus long et difficile
Construction progressive par datamarts
Avantage : rapide
Inconvénient : risque de cohabitation de datamarts incohérents
Dataweb
Ouverture du data warehouse au web

52/69
 Bilan

Plus loin...
Big data warehouses
Volume
Optimisation/parallélisation des agrégations
OLAP dans un cloud
Variété
Nouveaux modèles multidimensionnels et opérateurs
d’agrégation
Entrepôts NoSQL
Vélocité
Travailler en mémoire : problème de l’explosion dimensionnelle
Fonctions d’oubli
Véracité
Qualité des données sources
Sécurité des données entreposées

53/69
 NoSQL

NoSQL

54/69
 NoSQL

Sources des transparents

Bernd Amann, LIP6

Bernard Espinasse, Ecole Polytechnique Universitaire de
Marseille
Olivier Guibert, Université de Bordeaux
Anne-Cécile Caron, Université de Lille

55/69
 NoSQL

Introduction
Constats :
De plus en plus de donnnées disponibles ou à manipuler
très grandes plateformes
applications Web (Google, Facebook, Twitter, Amazon, ...)
Nécessite de la gestion des données de manière distribuée
Le respect des propriétés ACID (Atomicité, Cohérence,
Isolation et Durabilité) n’est pas possible dans un
environnement distribué
Aussi, manipulation
de données complexes, hétérogènes, non structurées
de très grands volumes de données (Big Data)

56/69
 NoSQL

Evolutions de la gestion des données

Nouvelles Données :
Web 2.0 : Facebook, Twitter, news, blogs, ...
LOD : graphes, ontologies, ...
Flux : capteurs, GPS, ...
→ Très gros volumes, données pas ou faiblement structurées
Nouveaux Traitements :
Moteurs de recherche
Extraction, analyse, ...
Recommandation, filtrage collaboratif, ...
→ Transformation, agrégation, indexation
Nouvelles Infrastructures :
Cluster, réseaux mobiles, microprocesseurs multi-coeurs, ...
→ Distribution, parallélisation, redondance

57/69
 NoSQL

Augmentation du volume de données

w3resource.com/mongodb/nosql.php

58/69
 NoSQL

Limites de SGBD relationnels/traditionnels

Faible efficacité lorsque les volumes de données sont importants car
Transaction respectant les propriétés ACID
Requêtes LMJ réalisées séquentiellement et préservant
l’intégrité des données
→ Gestion des transaction complexe ayant un impact sur les
performances
Modèle ER flexible mais peu adapté aux données
non-structurées
→ peu performant et couteux en temps de développement
Matériel et logicieux coûteux et compétences en optimisation
peu répandues
→ Nécessité de distribuer les traitements

59/69
 NoSQL

NoSQL
Définition de systèmes « NoSQL » (not only SQL)
Pour répondre à l’augmentation du volume de donnnées à
traiter :
Spécialisation des systèmes
Systèmes sur mesure
Pas d’utilisation de SQL comme langage de requête
Généralement des modèles de données différents :
Modèle Document
Modèle Colonne
Modèle clé/valeur
Modèle Graphe
→ Théorème CAP (Cohérence, Disponibilité, Pannes)
(Brewer, 2000)

60/69
 NoSQL

Théorème CAP

w3resource.com/mongodb/nosql.php

61/69
 NoSQL

Systèmes NoSQL

62/69
 NoSQL

SGBD NoSQL
Définition

SGBD non fondé sur

l’architecture des SGBDR
open source
distribué
horizontally scalable (montée en charge par ajout de serveurs)

63/69
 NoSQL

SGBD NoSQL
Simplification en renonçant aux fonctionnalités classiques des
SGBDR :
Redondance (via réplication)
Pas forcément de schéma normalisé, initialement voire à terme
Pas de tables mais des collections
Rarement du SQL mais API simple ou langage spécialisé
Pas forcément de jointure mais multiplication des requêtes,
cache/réplication/données non normalisées, données imbriquées
Transactions pas forcément ACID mais plutôt BASE
Résisitance aux pannes (P) s’impose pour un système distribué :
AP (accepte de recevoir des données éventuellement
incohérentes)
CP (attendre que les données soient cohérentes)

64/69
 NoSQL

SGBD NoSQL
Gestion des mégadonnées (big data) du web, des objets connectés,
etc.
Structure des données hétérogène et évolutive
Données complexes et pas toujours renseignées
Environnement distribué : données répliquées et accédées d’un peu
partout (dans le monde), traitement répartis
Techniques de partionnement des BD : sharding, hachage cohérent
(consistent hashing)
Contrôle de concurrence multi-version (Multi-Version Concurrency
Control MVCC)
Adaptation du protocole Paxos
Performances linéaires avec la montée en charge (les requêtes
obtiennent toujours aussi rapidement une réponse)

65/69
 NoSQL

Classification de systèmes

Types de données : tables, clés/valeurs, arbres, graphes,

documents
Paradigme (langages) : MapReduce (PIG, Hive)
API / Protocole : JSON/REST
Persistence : mémoire, disque, cloud...
Gestion de concurrence / cohérence
Réplication, protocoles
Langage d’implémentation, ...
Voir https://db-engines.com/en/ranking

66/69
 Fondements des systèmes NoSQL

Fondements des systèmes NoSQL

Sharding : partitionnement sur plusieurs serveurs

Consistent hashing : partitionnement des données sur
plusieurs serveurs eux-mêmes partitionnés sur un segment
Map Reduce : modèle de programmation parallèle permettant
de paralléliser tout un ensemble tâches à effectuer sur un
ensemble de données,
MVCC (Contrôle de Concurrence Multi-Version) : mécanisme
permettant d’assurer le contrôle de concurrence
Vector-Clock (horloges vectorielles) : mises à jour
concurrentes en datant les données par des vecteurs d’horloge

67/69
 Fondements des systèmes NoSQL

Conclusion

On a besoin de SQL et de NoSQL

NoSQL = not only SQL
Principe CAP
Importance de noSQL
Analyse de données
Passage à l’échelle
Parallélisation / partionnement verticale

68/69
 Fondements des systèmes NoSQL

Conclusion

Les SGBDR en font trop, alors que les produits NoSQL

font exactement ce dont vous avez besoin (Travis, 2009)

Gestion des BD géantes des sites web de très grande audience

Exemple des SGBD d’annuaires : grande majorité des accès aux BD
consistent en lectures sans modification (ainsi, seule la persistance
doit être vérifiée)
« Consensus » actuel :
Les SGBD NoSQL ne replacent pas les SGBDR mais les complètent
en palliant leurs faiblesses

69/69