Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
Bases de Données AvancéesDataWareHouse et NoSQL
Introduction
Thierry Hamon
Bureau H202Institut Galil�e - Universit� Paris 13
&LIMSI-CNRS
[email protected]://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
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