Big Data et NoSQL - 123SeminarsOnly.com

publicité
De l’explosion des volumes de données liée à l’essor
du Web, à l’émergence de nouvelles architectures de
stockage et d’interrogation de données
Maxime Bérard
Kévin Dumoulin
Thomas Moreau
Guillaume Roche
SI5 - AL
16/11/2012

Contexte actuel

Bases de données NoSQL
de nouvelles architectures de stockage et de traitement
des données.







Bases orientées clé-valeur
Map Reduce
Bases orientées documents
Bases orientées colonnes
Bases orientées graphes
Un tout en un : Hadoop
Conclusion
11/16/2012
2
 Big Data = désigne ensembles de données qui
s’étendent et deviennent très difficiles à stocker et
interroger avec des outils classiques (SGBDR)
 Enjeux économiques importants
 Coût de stockage
 Vitesse de traitement des données (vélocité)
 Pb de variété des données
 Exemples :
 Google
 Réseaux sociaux
 Télécoms
11/16/2012
3
 Atomicité, Cohérence, Isolation,
Durabilité
 Le théorème CAP (Cohérence,
Disponibilité, Résistance)
 Les SGBDR ont une mauvaise
performance en scalabilité horizontale
11/16/2012
4
 « not only SQL »
 Ne remplace SQL, mais constitue une alternative
 Répond aux problématiques de scalabilité horizontale
 S’affranchit des contraintes ACID
11/16/2012
5
 NoSQL
 Associer une clé a une seule valeur
 La valeur est un BLOB
 Pas de structure de champs
 La clé peut être une adresse vers une ressource
11/16/2012
6

Avantages & Inconvénients
+
 Simplicité et extensibilité
 Performances
 Cas d’utilisation très spécifiques
11/16/2012
7

DynamoDB
 Solution proposé par Amazon
 Base de données distribuée
 Excellente « scalabilité » horizontale
 Tolérance aux pannes
 Flexibilité
 Capacité requêtes des tables
11/16/2012
8

Principe de DynamoDB
 Attribut
 Elément
 Table
11/16/2012
9
 Algorithme popularisé par Google
 Permet de diviser et répartir la charge de travail
 Se déroule en 2 phases
 Map
 Reduce
11/16/2012
10

Présentation du concept
 Évolution des bases de données clé-valeur
 Plus de BLOB, mais un document intelligible
 Requêtes sur les champs du documents
 SchemaLess : Pas de schéma de base de données
11/16/2012
11

Comparaison avec les SGBDR
11/16/2012
12

Avantages & Inconvénients
+
 Adapté pour traiter des données hétérogènes
 Très flexible
 Bonne scalabilité horizontale
 Trop permissif
 Pas adapté lorsqu’on a des entités peu autonomes
11/16/2012
13

Quelques exemples
 CouchDB : utilisation de JSON et REST/HTTP
 MongoDB : performances, requêtes évoluées
 Redis : très performant, minimaliste
 Riak : inspiré de Dynamo
11/16/2012
14

Le principe de stockage
 Stockage en colonne
 Sérialisation des données :
1, Jean, null, Chapeau
2, Paul, Polytech, null
3, Jacques, null, null
Etc.
Jean, Paul, Jacques
Polytech
Chapeau, Casquette, Sombrero
id
Nom
1
Jean
2
Paul
3
Jacques
Ecole
CouvreChef
Chapeau
Polytech
4
Casquette
5
Sombrero
Base relationnelle
Nom
Ecole
CouvreChef
Jean (1)
Polytech (2)
Chapeau (1)
Paul (2)
Casquette (4)
Jacques (3)
Sombrero (5)
Base orientée colonnes
 Gain en espace disque :
Possiblement pas de « null »
11/16/2012
15

Avantages & Inconvénients
+





Une capacité de stockage accrue
Compression (travail possible sur des données compressées)
Rapidité d’accès à de gros volumes de données
Ajout de nouveaux types de données/colonnes facilité
Se prêtent bien au clustering + Architecture MPP
 Opérations limitées, efficaces dans un contexte BigData
11/16/2012
16

Quelques exemples
 BigTable
 Base « modèle » et initiatrice du mouvement NoSQL
 Intègre une couche MPP (Massively Parallel Processing) pour le
traitement des données
 Optimisations pour l’indexation
 Non librement distribuée
11/16/2012
17

Quelques exemples
 Vertica
 Utilisée par LinkedIn + Hadoop (MPP à tous les niveaux)
 Compression des données optimisée (données similaires : taux
de compession 50-90%)
 Travail sur les données compressées
 Clustering, solutions de haute disponibilité
 Optimisations : regroupements de colonnes (FlexStore)
 Proche de SQL pour le requêtage
 Idéale pour datawarehouse et stockages/traitements massifs
11/16/2012
18

(Michael Stonebraker)
 Un bloc de stockage ne doit contenir des données que d’une
seule colonne.
 Le taux de compression doit être amélioré
 Il faut pouvoir se passer des ID d’enregistrement
 La base de données orientée colonnes doit disposer d’un
moteur d’exécution au niveau de la colonne et non au niveau
de l’enregistrement
 Le moteur doit pouvoir travailler directement sur les
données compressées et non au travers d’un buffer de
décompression.
 Le moteur doit être capable de traiter aussi bien des
données stockées chronologiquement que sur une clé.
11/16/2012
19

Exemples d’infrastructures de type graphe
 Réseaux sociaux
 Réseaux informatiques
 Intelligence artificielle
(réseau de neurones)
 Relations de préférences
client-produit
11/16/2012
20

Structure de la base
◦ 3 éléments :
 Nœuds
 Liens
 Propriétés
11/16/2012
21

Opération particulière : le parcours transversal
 Nœud de départ
Dinosaure
 Spécification de parcours
Parcours sur les liens « mange »
sur une profondeur de 2 noeuds
 Set obtenu
 => Beaucoup plus rapide
qu’une série de Joins
11/16/2012
22
 Equivalent des liens
d’amitié entre utilisateurs
de Facebook…
 … pour une ville comme
Mougin !
11/16/2012
23

Exemples de bases
 HypergraphDB : intelligence artificielle, web sémantique
 FlockDB : Twitter, pas de parcours transversal
 BigData : très grande capacité, clustering
11/16/2012
24

Avantages & Inconvénients
+
 Parfaitement adaptées à la gestion de données relationnelles
 Algorithmes déjà existants et optimisés
 Architecture modulable selon les besoins
 Inadaptées pour tous les autres cas
11/16/2012
25

Présentation
 Framework open source
 Développé par Apache
 Solution au BigData
 Utilisé par Google, Ebay, IBM et Facebook
11/16/2012
26

Principe
 Base de données
distribuées
 Hadoop Distributed File
System (HDFS)
 MapReduce
11/16/2012
27

Bilan
 Réalisation d'applications extensibles
 Efficace
 Flexible
 Peu impacté par les erreurs
11/16/2012
28
 Des volumes de données à traiter toujours plus grands
 Réseaux sociaux, télécoms, données de tout types
 Besoin de nouvelles solutions de stockage et interrogation
 Réponse au mouvement NoSQL
 Technologies newSQL, bases optimisées, respectant le modèle
ACID
11/16/2012
29
http://blog.xebia.fr/2010/05/04/nosql-europe-bases-de-donnees-orientees-colonnes-et-cassandra/
http://ayende.com/blog/4449/that-no-sql-thing-key-value-stores
http://www.legrandbi.com/2012/02/linkedin-bigdata/
http://dbpedias.com/wiki/NoSQL:Survey_of_Distributed_Databases#NoSQL_Databases
http://readwrite.com/2011/04/20/5-graph-databases-to-consider
http://aws.amazon.com/fr/dynamodb/#functionality
http://blog.xebia.fr/2010/12/15/mongodb-en-pratique/
http://www.legrandbi.com/2009/10/stockage-en-colonnes-adoop-le-duo-gagnant/
http://blog.zenika.com/index.php?post/2012/07/11/Hadoop-et-le-MapReduce-au-service-des-gros-volumes-de-donn%C3%A9es
http://www.youtube.com/user/ibmbigdata
http://www.internetactu.net/2012/10/04/big-data-le-grand-desequilibre/
Et bien d’autres…
11/16/2012
30
11/16/2012
31
Téléchargement