Bases de Données AvancéesDataWareHouse et NoSQL

Introduction

Thierry Hamon

Bureau H202Institut Galil�e - Universit� Paris 13

&LIMSI-CNRS

hamon@limsi.frhttps://perso.limsi.fr/hamon/Teaching/P13/BDA-INFO2-2018-2019/

INFO2 – BDA

1/69

Sources des transparents

F. Boufares, LIPN, Université Paris NordP. Marcel, LI, Université de ToursBernard Espinasse, Ecole Polytechnique Universitaire deMarseilleMelanie 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% électroniquetaux de croissance annuel de 50 %

en 2003 : 5 Eo en 2002, 92% électroniqueLyman&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

IntroductionAvant les entrepôts de données/Data Warehouses

La majeure partie des applications Bases de Données reposentaujourd’hui sur trois couches :

La couche la plus externe est celle de qui permet de présenterles données aux utilisateurs.Elle est appelée Graphical User Interfaces GUI.La couche application intermédiaire inclut le programme del’applicationElle 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

BD1

Graphical User Interfaces GUIGUICouche Présentation

BD2

Ressources externes

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

Decision support SystemOLTP Application OLTP ApplicationCouche Application

Couche Base de Données

Insert, Update, DeleteRead, Select

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érationsInsert, 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 ProcessingOLTP.

7/69

BD → ED

IntroductionDonné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, ExecutiveInformation System, Decision Support System DSS)

8/69

BD → ED

IntroductionVers les entrepôts de données

Remarques

Contrairement aux applications OLTP, qui consultent etmettent à jour les données des BD opérationnelles,les DSS lisent les données seulement pour avoir denouvelles 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émentairesmineurs.

9/69

BD → ED

IntroductionVers 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éesdans les BDles analyses historiques sont donc souvent impossibles à cause desopérations de mises à jour qui changent les données historiquesL’utilisation des BD en mode multi-utilisateursce qui implique des opérations de verrouillage des données (Lockingoperations) et donc des problèmes de performancecar les requêtes analytiques demandent l’accès à de très grandsnombre de tuples.

10/69

BD → ED

Introduction

La solution est de séparerla BD orientée Transactionde la BD orientée Aide à la Décisiond’où la naissance du conceptEntrepôt de Données = Data Warehouse.

Les DWH sont physiquement séparés des SGBD opérationnels (BDopérationnelles)

11/69

BD → ED

IntroductionDé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’unprocessus d’aide à la décision

Un système de DWH peut être formellement défini comme untriplet<BD cible, méta-données, un ensemble d'opérations>

L’ensemble des opérations associées peut être présenté en 4catégories (ETL, Agrégation et Groupement)

12/69

BD → ED

Architecture des DWHs

OLAP

BD opérationnelles

Sources externes

Méta−données

Entrepot de données

Intégrer

Maintenir

Extraire

Nettoyer

Transformer

Charger (Load)

Rafraichir

Utiliser

13/69

BD → ED

Introduction

Le DWH intègre des données à partir de sources multiples ethétérogènesafin de répondre aux requêtes du système d’aide à la décision.Ce type d’application est appelé On-Line AnalyticalProcessing OLAPOLAP permet la transformation des données en informationsstratégiques

14/69

BD → ED

Nouveaux concepts/nouvelle perspective

Entrepôt de donnéesrécolte, stockage et gestion efficace des gros volumes dedonnéesOLAPrequêtes interactives complexes sur ces volumesData mining (fouille de données)extraction automatique de propriétés cachéesdonnées → information → connaissances

15/69

BD → ED

Analyse OLAP(On-Line Analytical processing)

Techniques OLAP :apparition en recherche dans les années 70mais développement dans les années 90 dans l’industrie

Réalisation de synthèses, d’analyses et de la consolidationdynamique de données multidimensionnellesManière la plus naturelle d’exploiter un ED étant donné sonorganisation multidimensionnelle

16/69

BD vs. DWH

Introduction : ComparaisonPourquoi pas des SGBDs pour les entrepôts de données ?

les 2 systèmes sont performantsSGBD : calibré pour l’OLTP ; méthodes d’accès index,contrôle de concurrence, repriseEntrepôt : calibré pour l’OLAP ; requêtes OLAP complexes,vue dimensionnelle, consolidation

Fonctions et données différentesDonnées manquantes : l’aide à la décision (AD) a besoin desdonnées historiques qui ne se trouvent pas dans les BDopérationnellesConsolidation : l’AD a besoin de données consolidées(agrégats) alors qu’elles sont brutes dans les BDopérationnelles

17/69

BD vs. DWH

Introduction : ComparaisonSGBD hétérogènes vs. Entrepôts de données

Traditionnellement, l’intégration de BD hétérogènes se fait parle biais de

Wrappers/médiateurs au dessus des BD hétérogènesApproches orientées requêtes

Quand une requête est posée sur un site client, unmétadictionnaire est utilisé pour la traduire en plusieursrequêtes appropriées à chacune des BD. Le résultat estl’intégration de réponses partiellesL’exécution des requêtes demande donc beaucoup deressources

Entrepôts de données : approche orientée mise à jourles informations sont intégrées et stockées pour uneinterrogation directePlus 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éesOLTP (On-Line Transaction Processing)

Exécution en temps réel des transactions, pourl’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 dedé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. OLAPDonnées : courantes, détaillées vs. historiques, consolidéesConception : modèle ER + application vs. modèle en étoile +sujetVues : courantes, locales vs. évolutive, intégréeMode d’accès : mise à jour vs. lecture seule mais requêtescomplexes

20/69

BD vs. DWH

Architecture du DWHArchitecture Multi-tiers

MVS (TSO, DB2 ...)

DataWareHouse

UNIX (Oracle, ...)

Windows (SQL Server,

Excel, ...)

Dictionnaire de

Méta−données

Applications en

production

Oracle 9i (Olap)

Oracle Express

Data select

(requetes)

Business Objects

(rapports, analyses)

SAS

(Datamining)

Data Marts

OLAP SERVER

Outils Front−EndControle et chargement des données OLAP

T(ransform)

L(oad)

E(xtract)

����

��������

����

��������

����

��������

21/69

BD vs. DWH

Conception logique des DWHsDonnées multidimentionnelles

Montant des ventes comme une fonction des paramètresproduits, mois, région

Dimensions : Produit, Lieu, Temps

Catégorie

Chemins de consolidation hiérarchiques

Produit

Mois

Régio

n

Industrie

Produit

Pays

Ville

Magasin

Année

Jour

SemaineMois

Trimestre

Région

22/69

Applications

Domaines d’application

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

aider atteindre les objectifs stratégiques d’une entreprise etfaciliter son pilotageavoir une connaissance plus approfondie de l’entrepriseanticiper les besoins clientsprendre en compte les nouveaux canaux de distribution (venteen ligne, etc.)

23/69

Applications

Domaines d’applicationInformatique décisionnelle

Entrepôt de donnéesOutils de veille stratégique et de recueil d’information(intelligence économique)Aide aux décideurs pour prendre les bonnes décisions sur labase des données disponiblesExemples :

Quels sont les 5 produits les plus vendus pour chaquesous-catégorie de produits qui représente plus de 20% desventes dans sa catégorie de produits ?Quelle est la priorité d’expédition et quel est le revenu brutpotentiel des commandes de livres qui ont les 10 plus grandesrecettes 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 clientgestion des commandes, des stocksprévisions de ventesdéfinition de profil utilisateuranalyse de transactions bancairesdé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’applicationDomaine bancaire

Un des premiers utilisateurs des EDRegroupement des informations relatives à un client pour unedemande de créditLors de la commercialisation d’un nouveau produit :Mailing ciblés rapidement élaborés à partir de toutes lesinformations disponibles sur un clientRecherche de fraudes sur les cartes de crédit :Mémorisation des mouvements et contrôles a posteriori, pourdétecter les comportements suspectsÉchanges d’actions et de conseils de courtagesDéterminer des tendances de marchés grâce à :

la mémorisation de l’historiqueune 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éesProcessus en 3 phases :1 Construction de la BD décisionnelle

Modélisation conceptuelle des données multiformes et multi-sourcesConception de l’entrepôt de donnéesAlimentation de l’entrepôt (extraire, nettoyer, transformer, charger)Stockage physique des données

2 Sélection des données à analyserBesoins d’analyse de l’utilisateurData marts (Magasins de données)Cubes multidimensionnelsTableaux ou tables bidimensionnels

3 Analyse des donnéesStastiques et reporting, OLAP, Data Mining

28/69

Définition d’un DWH

Présentation des couches

Graphical User Interfaces GUIGUICouche Présentation

BD2

BD1Target DataBase

Ressources externes

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

Decision support SystemOLTP Application OLTP ApplicationCouche Application

Couche Base de Données

Insert, Update, Delete Read, Select

LoadDataWareHouse

29/69

Définition d’un DWH

Architecture du DWHArchitecture Multi-tiers

MVS (TSO, DB2 ...)

DataWareHouse

UNIX (Oracle, ...)

Windows (SQL Server,

Excel, ...)

Dictionnaire de

Méta−données

Applications en

production

Oracle 9i (Olap)

Oracle Express

Data select

(requetes)

Business Objects

(rapports, analyses)

SAS

(Datamining)

Data Marts

OLAP SERVER

Outils Front−EndControle et chargement des données OLAP

T(ransform)

L(oad)

E(xtract)

����

��������

����

��������

����

��������

30/69

Définition d’un DWH

OpérationsExtraction (Extraction) : Ces opérations permettent de filtrer lesdonnées à partir de données sources (BD, fichiers, sites web...) dansdes BD temporaires.Transformation (Transformation) : Ces opérations permettent detransformer les données extraites dans un format uniforme.Les conflits entre les modèles, les schémas et les données sontrésolus durant cette phase.Chargement (Load) : Ces opérations permettent de charger lesdonné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 cibledoit permettre de stocker les données opérationnelles et les donnéesissues de calculs.

31/69

Architecture

Architecture

Objectifs :regrouper les données sourcesconcevoir le schéma de l’entrepôtremplir l’entrepôtmaintenir l’entrepôt

32/69

Architecture fonctionnelle

Architecture fonctionnelle de l’entrepôtLes données d’un entrepôt se structurent suivant

un axe synthétique : établissement d’une hiérarchied’agrégation incluant

les données détaillées : les événements les plus récentsles données agrégées : synthèse des données détailléesles données fortement agrégées : synthèse à un niveausupérieur des données agrégées

un axe historiqueincluant les données détaillées historisées représentant lesévénements passés

→ Stockage des méta-données : informations concernant lesdonnées de l’ED (provenances, structures, méthodes utilisées pourl’agrégation, ...)

33/69

Architecture fonctionnelle

Entrepôts et magasins de donnéesData Warehouses et Data marts

Entrepôts de donnéesCollecte l’ensemble de l’information utile aux décideurs à partirdes sources de données (BD opérationnelle, BD externes, ...)Centralisation de l’information décisionnelleGarantie de l’intégration des données extraites et de leurpérennité dans le temps

Magasins de donnéesOrientés sujetAide efficace aux processus OLAPExtraction d’une partie des données utiles :

pour une classe d’utilisateurs oupour 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’EDchaque étape de la construction de l’EDle passage d’un niveau de données à un autre (exploitation del’ED)Rôle : définition, fabrication, stockage, accès et présentationdes données

35/69

Données sources

Données sourcesLes données des entreprises sont généralement :

SurabondantesEparpilléesPeu structurées pour l’analyseModifiées quotidiennement

Problème : Prise de décision difficileSolution : Utilisation d’outils et de techniques visant à préparer lesdonnées pour l’analyse Data warehousing

Il s’agit d’une technique visant à extraire des données dedifférentes sources afin de les intégrer selon des formatsplus 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ènesNécessité d’intéger des données hétérogènes, modifiéesquotidiennement

BDrelationnellesobjetsdistribuées

fichiers textesdocuments HTML, XMLbases de connaissances...

Mais aussi des représentations de données et de noms dechamps/colonnes hétérogènes

37/69

Alimentation de l’ED

Processus d’alimentation d’un EDEntreposage des données

Rôle de l’alimentation de l’entrepôtrassembler de multiples données sources souventhétérogèneshomogénéiser les données sources

Homogénéisation réalisée selon des règles précisesLes règles d’homogénéisation sont :

mémorisées sous forme de méta-données stockées dans ledictionnaire de donnéesutiliser pour assurer des tâches d’administration et degestion 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 sources2 Extraction des données3 Nettoyage et Transformation4 Chargement

Etapes 1 et 2 : Jusqu’à 80 % du temps de développement d’unentrepô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éesSélection et extraction des donnéesFormatage des données dans un format cible commun

en général, le modèle RelationnelUtilisation d’interfaces comme ODB, OCI, JDBC

40/69

Alimentation de l’ED

Transformation

Objectif : suppression des incohérences sémantiques entre lessources, problématique lors de l’intégration

des schémasdes données

41/69

Alimentation de l’ED

Transformation

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

Demande une solide connaissance de la sémantique desschémasPeu 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éesObjectif : Stockage des données nettoyées et préparées dans la BDopérationnelle (ODS)

Opération :risquant d’être assez longueplutôt mécaniquela moins complexe

Mais il est nécessaire de définir et mettre en place :des stratégies pour assurer de bonnes conditions à saréalisationune politique de rafraîchissement

43/69

Alimentation de l’ED

Chargement des données

Définitions de vues relationnelles sur les données sourcesMatérialisation des vues dans l’entrepôtMais aussi, préparation à la restitution

trisconsolidations (pré-agrégation)indexationpartitionnement des donnéesenregistrement de méta-données...

44/69

Alimentation de l’ED

Préparation à la restitution

AgrégationCalcul de vues agrégéesDéfinition des indexesStockage dans le CDW

PersonnalisationConstruction de magasin de données (Data Marts)Construction de cubes de donnéesConstruction des présentations demandées par les utilisateurs

45/69

Modélisation

Modélisation multidimensionnelleLien direct entre les analyses décisionnelles (OLAP) et unemodélisation de l’information conceptuelle :

proche de la perception qu’en a l’analystebasée sur une vision multidimensionnelle des données

Modèle multidimensitionnel : les données sont vues comme desdata cubes

Un cube de dimension n est dit un cuboïdeLe treillis des cuboïdes d’un entrepôt de données forme undata cube

La modélisation multidimensionnelle a donné naissance auxconcepts 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 dimensionsOrganisation des données pour mettre en évidence le sujetanalysé et les différentes perspectives de l’analysedata cube (par exemple, les ventes) : vision des données surplusieurs dimensions

49/69

Modélisation

Concept de faitUn fait :

modélisation du sujet de l’analyseMesures correspondant aux informations de l’activité analyséeMesures numériques, généralement valorisées de façoncontinue. On peut

les additionnerles dénombrercalculer le minimum, le maximum ou la moyenne

Exemple : le fait de Vente peut être constitué des mesuresd’activités suivantes :

quantité de produits vendusmontant total des ventes

50/69

Modélisation

Concept de dimensionAxes ou perspectives caractérisant es mesures de l’activité d’un faitUne dimension :

modélisation un axe d’analysenécessité pour chaque dimension, de définir ses différentsniveaux de détail→ Définition de une (ou plusieurs) hiérarchie(s) de paramètresse compose de paramètres correspondant aux informationsfaisant 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 Tempsla dimension Geographiela dimension Categorie

51/69

Bilan

Conclusion et perspectives

Deux tendances actuellesdatamartsdataweb

construction du Data Warehouse : processus long et difficileConstruction progressive par datamarts

Avantage : rapideInconvénient : risque de cohabitation de datamarts incohérents

DatawebOuverture du data warehouse au web

52/69

Bilan

Plus loin...Big data warehouses

VolumeOptimisation/parallélisation des agrégationsOLAP dans un cloud

VariétéNouveaux modèles multidimensionnels et opérateursd’agrégationEntrepôts NoSQL

VélocitéTravailler en mémoire : problème de l’explosion dimensionnelleFonctions d’oubli

VéracitéQualité des données sourcesSécurité des données entreposées

53/69

NoSQL

NoSQL

54/69

NoSQL

Sources des transparents

Bernd Amann, LIP6Bernard Espinasse, Ecole Polytechnique Universitaire deMarseilleOlivier Guibert, Université de BordeauxAnne-Cécile Caron, Université de Lille

55/69

NoSQL

IntroductionConstats :

De plus en plus de donnnées disponibles ou à manipulertrès grandes plateformesapplications Web (Google, Facebook, Twitter, Amazon, ...)

Nécessite de la gestion des données de manière distribuéeLe respect des propriétés ACID (Atomicité, Cohérence,Isolation et Durabilité) n’est pas possible dans unenvironnement distribuéAussi, manipulation

de données complexes, hétérogènes, non structuréesde très grands volumes de données (Big Data)

56/69

NoSQL

Evolutions de la gestion des donnéesNouvelles 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éesNouveaux Traitements :

Moteurs de rechercheExtraction, analyse, ...Recommandation, filtrage collaboratif, ...

→ Transformation, agrégation, indexationNouvelles 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/traditionnelsFaible efficacité lorsque les volumes de données sont importants car

Transaction respectant les propriétés ACIDRequêtes LMJ réalisées séquentiellement et préservantl’intégrité des données→ Gestion des transaction complexe ayant un impact sur lesperformancesModèle ER flexible mais peu adapté aux donnéesnon-structurées→ peu performant et couteux en temps de développementMatériel et logicieux coûteux et compétences en optimisationpeu répandues→ Nécessité de distribuer les traitements

59/69

NoSQL

NoSQLDéfinition de systèmes « NoSQL » (not only SQL)

Pour répondre à l’augmentation du volume de donnnées àtraiter :

Spécialisation des systèmesSystèmes sur mesurePas d’utilisation de SQL comme langage de requête

Généralement des modèles de données différents :Modèle DocumentModèle ColonneModèle clé/valeurModè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 NoSQLDéfinition

SGBD non fondé surl’architecture des SGBDRopen sourcedistribuéhorizontally scalable (montée en charge par ajout de serveurs)

63/69

NoSQL

SGBD NoSQLSimplification en renonçant aux fonctionnalités classiques desSGBDR :

Redondance (via réplication)Pas forcément de schéma normalisé, initialement voire à termePas de tables mais des collectionsRarement 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éesTransactions pas forcément ACID mais plutôt BASERésisitance aux pannes (P) s’impose pour un système distribué :

AP (accepte de recevoir des données éventuellementincohérentes)CP (attendre que les données soient cohérentes)

64/69

NoSQL

SGBD NoSQLGestion des mégadonnées (big data) du web, des objets connectés,etc.Structure des données hétérogène et évolutiveDonnées complexes et pas toujours renseignéesEnvironnement distribué : données répliquées et accédées d’un peupartout (dans le monde), traitement répartisTechniques de partionnement des BD : sharding, hachage cohérent(consistent hashing)Contrôle de concurrence multi-version (Multi-Version ConcurrencyControl MVCC)Adaptation du protocole PaxosPerformances linéaires avec la montée en charge (les requêtesobtiennent toujours aussi rapidement une réponse)

65/69

NoSQL

Classification de systèmes

Types de données : tables, clés/valeurs, arbres, graphes,documentsParadigme (langages) : MapReduce (PIG, Hive)API / Protocole : JSON/RESTPersistence : mémoire, disque, cloud...Gestion de concurrence / cohérenceRéplication, protocolesLangage 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 serveursConsistent hashing : partitionnement des données surplusieurs serveurs eux-mêmes partitionnés sur un segmentMap Reduce : modèle de programmation parallèle permettantde paralléliser tout un ensemble tâches à effectuer sur unensemble de données,MVCC (Contrôle de Concurrence Multi-Version) : mécanismepermettant d’assurer le contrôle de concurrenceVector-Clock (horloges vectorielles) : mises à jourconcurrentes 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 NoSQLNoSQL = not only SQLPrincipe CAP

Importance de noSQLAnalyse de donnéesPassage à l’échelleParallélisation / partionnement verticale

68/69

Fondements des systèmes NoSQL

Conclusion

Les SGBDR en font trop, alors que les produits NoSQLfont exactement ce dont vous avez besoin (Travis, 2009)

Gestion des BD géantes des sites web de très grande audienceExemple des SGBD d’annuaires : grande majorité des accès aux BDconsistent en lectures sans modification (ainsi, seule la persistancedoit être vérifiée)

« Consensus » actuel :Les SGBD NoSQL ne replacent pas les SGBDR mais les complètenten palliant leurs faiblesses

69/69