1/30 2/30 Anne-Cécile Caron Master MIAGE - SGBD 1er trimestre 2014-2015 I : Not Only SQL, ce n est pas du relationnel, et le contexte d utilisation n est donc pas celui des SGBDR. I Origine : recherche d information sur le web, moteurs type Google, Yahoo, données des réseaux sociaux,... I Besoin de stockage d énormes masses de données. Twitter par exemple reçoit plusieurs Tera-octets de données par jour. I I table d associations - Map - de couples (clef,valeur) I Di érentes approches, rangées dans la famille. 3/30 4/30 Bibliographie Le cours d aujourd hui utilise I le livre de Serge Abiteboul et al, Web Data Management http://webdam.inria.fr/jorge/ I le livre blanc de Smile sur : http://www.smile.fr/livres-blancs/culture-du-web/ I le livre de Eric Redmond et Jim R. Wilson, Seven Databases in Seven Weeks I le livre de Nick Dimiduk et Amandeep Khurana, HBase in Action Pourquoi ces technologies sont passées des acteurs du web au grand public? I Big Data =) Volume, Variété, Vélocité I Exploitation de données externes ajoutées aux données internes, quelles soient structurées (relationnelles, multidimensionnelles) ou non (e.g. documentaires) I Quelques exemples de Big Data : I Service marketing : informatique décisionnelle classique (données structurées), couplée avec l exploitation de mails (données internes non structurés), et des réseaux sociaux (données externes non structurées). I Recherche Scientifique : capteurs qui ramènent énormément de données numériques (accélérateur de particules, télescope,...) ou nécessité de partager des données très volumineuses (génomique,...) I n est qu une partie de cette vaste problématique du Big Data.
Recherche sur le web 5/30 Recherche sur le web 6/30 Un cas d utilisation : Recherche sur le Web Inverted File I collecter les documents publiés sur le web = web crawling. + détecter des changements sur un document déjà parcouru. I traiter ces documents pour extraire l information qu ils contiennent : mots significatifs I construire un index permettant de retrouver les documents les plus pertinents pour 1 mot clef ou un ensemble de mots clefs = inverted files I comme le glossaire d un livre I à 1 mot clef on associe une collection de documents qui contiennent ce mot Recherche sur le web 7/30 8/30 Inverted File - structure I on connaît le nombre de documents n i associés à un terme t i. I on donne un poids w k à chaque document d k associé au terme t i.le poids traduit la pertinence du document pour ce terme. I = système logiciel qui permet de coordonner plusieurs ordinateurs. Généralement, cette coordination se fait par envoi de messages via un réseau auquel sont reliés ces ordinateurs. I Pourquoi? parce qu on manipule un très grand volume de données. Sans distribution, on n a pas d application scalable. I On peut imaginer 2 scenarii de traitement des données : 1. On dispose d un grand ensemble de données, et on doit leur appliquer des traitements disponibles sur des sites distincts. Il faut donc envoyer les données aux endroits appropriés, et enchaîner les exécutions distantes. C est un scénario de type Workflow, que l on peut implémenter avec des web services. ) Traitements distribués. 2. Les données sont distribuées sur un certain nombre de serveurs, et on pousse les programmes vers ces serveurs. Il est en e et plus e cace de transférer un petit programme sur le réseau plutôt qu un grand volume de données. ) Données distribuées. On verra aujourd hui l algorithme MapReduce qui utilise cette approche.
9/30 10 / 30 Exemple : Data Centers de Google I Utilise des LANs (Local Area Networks). On distingue 3 niveaux de communication : 1. Les serveurs sont regroupés en racks. Liaison réseau rapide, environ 1Go/sec. 2. Un data center consiste en un grand nombre de racks, interconnectés par des routeurs (switches). Liaison à 100 Mo/sec. 3. Entre di é r e n t s d a t a c e n t e r s, i l y a a u s s i u n e p o s s i b i l i t é d e communication mais par liaison assez lente (internet - 2-3 Mo/sec) I Les serveurs communiquent par envoi de messages, Ils ne partagent pas de disque ni de ressource de traitement. = architecture shared nothing. I Début 2010 : 1 data center Google contient entre 100 et 200 racks, chacun contenant 40 serveurs. Environ 5000 serveurs par data-center pour un total de 1 millions de serveurs (estimation d après la consommation électrique). Schéma : LAN/data center 11 / 30 12 / 30 Le théorème CAP Aucun système distribué ne peut fournir les 3 propriétés suivantes : 1. Consistency (cohérence) : tous les noeuds voient exactement les mêmes données en même temps 2. Availability (disponibilité) : L échec d un noeud n empêche pas les survivants de continuer à fonctionner 3. Partition tolérance (résistance au partitionnement) : Le système continue à fonctionner malgré la perte d un message du à une panne. Autrement dit, en cas de morcellement du réseau, chaque sous-réseau doit pouvoir fonctionner de façon autonome. pendant l envoi du message M, d 0 6= d I en général, la résistance au partitionnement n est pas discutable dans un système distribué : on doit choisir en A+P ou C+P I Un SGBD relationnel classique va privilégier C+P, avec un système transactionnel distribué et la vérification des propriétés ACID. C est au détriment des performances! I En, on choisit plutôt A+P.
Bases 13 / 30 Bases MapReduce 14 / 30 Bases Dans un contexte distribué, avec un très grand volume de données, sont apparues plusieurs solutions englobées sous le terme de. Ces bases de données ont certaines caractéristiques : I pas de schéma pour les données I données de structures complexes ou imbriquées I mode d utilisation : peu d écritures, beaucoup de lectures I on privilégie la disponibilité à la cohérence : A+P plutôt que C+P,! ces solutions ne contiennent pas de support pour les transactions (ou rarement) I Données distribuées : on a souvent la possibilité d utiliser des algorithmes MapReduce. Algorithme MapReduce I Le programmeur définit 2 fonctions : 1. Map : transforme l entrée en couples (clef,valeur) 2. Reduce : calcule 1 valeur à partir de la liste des valeurs associées à chaque clef I L environnement d exécution de l algorithme MapReduce s occupe de l aspect distribution : le programme est distribué sur les di érents noeuds, on a donc une exécution en parallèle. I Un programme complexe est décomposé en une succession de tâches Map et Reduce. Bases MapReduce 15 / 30 Bases MapReduce 16 / 30 Fonctions de base Exemple 1. map : (K1, V 1)! list(k2, V 2) function map(uri, doc) // uri : nom (id) du document, doc : le contenu du document foreach distinct term in doc output (term, count(term, doc)) 2. shu e :list(k2, V 2)! list(k2, list(v 2)) regroupe les couples intermédiaires en fonction de leur clef. 3. reduce : (K2, list(v 2))! list(k3, V 3) function reduce(term, counts) output (term, sum(counts)) On reprend les documents du transparent 4, on applique les fonctions map et reduce du transparent précédent pour compter le nombre de documents par terme.
Bases 17 / 30 Bases Couples (clef,valeur) 18 / 30 Bases Couples (clef,valeur) Nous allons voir maintenant les di érents paradigmes utilisés pour les bases. La base est une table de hachage distribuée. On dispose en général de 4 opérations : 1. stockage de couples (clé,valeur) 2. bases de documents 3. bases orientées colonnes 4. bases de graphes 1. Create : créer un nouveau couple (clef,valeur). La valeur est n importe quel objet. 2. Read : lire un objet connaissant sa clef 3. Update : mettre à jour l objet associé à une clef 4. Delete : supprimer un objet connaissant sa clef on ne peut pas e ectuer de requête sur le contenu des objets stockés. Quelques exemples : I Amazon Dynamo, dont Riak est l implémentation Open Source. I Redis, projet sponsorisé par VMWare. Pas dans un contexte BigData puisque toutes les données doivent tenir en mémoire. I Voldemort, développé par LinkedIn en interne puis passage en open source. Bases Couples (clef,valeur) 19 / 30 Bases 20 / 30 Exemple : Riak I stockage (clé,valeur) distribué : hachage distribué I on stocke une collection de documents I accès via une API Rest-ful (put, get, post, delete) I pas de schéma, les données stockées sont quelconques : images, texte (libre, ou semi-structuré comme XML et JSON), vidéos,... I pas de langage de requête, pas d opération un peu complexe que l on pourrait envoyer via une URL I gère la réplication : un cluster primaire qui contrôle la réplication sur un ou plusieurs clusters secondaires I Théorème CAP : privilégie A+P I programmation MapReduce essentiellement en Erlang (aussi en d autres langages comme javascript mais moins performant). I Si on intègre le moteur de recherche full-text à la SolR, Riak devient (presque) une base de documents. I un document a une structure arborescente : il contient une liste de champs, un champs a une valeur qui peut elle même être une liste de champs,... I le format choisi est semi-structuré comme JSON ou XML. On peut stocker n importe quel objet, via une sérialization I les documents n ont pas de schéma : grande flexibilité Quelques exemples : I MongoDB I CouchDB fondation Apache I RavenDB
Bases 21 / 30 Bases 22 / 30 Exemple : CouchDB I Modèle semi-structuré, basé sur JSON (Javascript object notation). { "title": "The Social network", "year": "2010", "director": {"last_name": "Fincher", "first_name": "David"}, "actors": [ {"first_name": "Jesse", "last_name": "Eisenberg"}, {"first_name": "Rooney", "last_name": "Mara"} ] } I CouchDB propose des vues structurées définies grâce au paradigme bfseries MapReduce : une vue est donc une liste de couples (clé,valeur) I Les vues sont matérialisées, indexées selon la clé par des B+arbres. Les vues sont mises à jour de façon incrémentale. I interrogation : http://le/chemin/jusquaux/vues/par_annee?startkey="2000"&endkey="2005" Bases 23 / 30 Bases 24 / 30 Exemple de vue CouchDB I Les données sont stockées par colonne, non par ligne. I On peut facilement ajouter des colonnes aux tables, par contre l insertion d une ligne est plus coûteuse. I Quand les données d une colonne se ressemblent, on peut facilement compresser la colonne. I Ce concept de base orientée colonnes existait avant I MonetDB pour le modèle relationnel, I modèle e cace pour des requêtes OLAP Quelques exemples en : I BigTable de Google et son implémentation open source (Apache) HBase. Google utilise BigTable pour l indexation des pages web, Google Earth, Google analytics,... I SimpleDB de Amazon I Cassandra fondation Apache, projet né chez Facebook.
Bases 25 / 30 Bases 26 / 30 HBase - le Modèle de données I Table :lesdonnéessontorganiséesentables I Ligne : Dans une table, on stocke des lignes, identifiées par leur Rowkey. I Famille de colonnes : A l intérieur d une ligne, les données sont groupées par familles de colonnes. Ces familles ont un impact sur le stockage physique, et doivent être connues à l avance. Toutes les lignes d une table ont les mêmes familles de colonne (donc ces familles constituent le schéma de la table). I Colonne : Les données d une famille de colonnes sont découpées en colonnes. Ces colonnes ne sont pas connues à l avance, et on n a pas toujours les mêmes colonnes d une ligne à l autre. I Cellule : pour 1 ligne, 1 famille et 1 colonne, on a 1 seule cellule. I Version :Lesvaleursd unecellulesontversionnées. I il n y a pas vraiment de type de données : tout est traité comme byte []. I HBase peut-être vue comme une sorted map of maps. Bases 27 / 30 Bases 28 / 30 HBase Architecture BigTable/HBase I HBase est construit au dessus de HDFS, système de fichier distribué. I 1 table est stockée dans une ou plusieurs régions, Le découpage se fait par famille de colonnes, chacune stockée dans des HFiles (HDFS). I HBase est construit au dessus de Hadoop, framework de programmation distribuée, basé sur MapReduce! HBase propose donc aussi une API pour MapReduce I HBase est fortement consistent (C+P) sur 1 cluster : HDFS gère la réplication des données à chaque écriture, et si un serveur de régions tombe en panne, il faut modifier les informations dans quelle région trouver quelle donnée, pendant ce temps la base n est plus disponible. Quand on a plusieurs clusters, les clusters de réplication ne donnent pas forcément la donnée la plus récente (mais système eventually consistent ). I HBase ne permet pas l indexation des données, autrement qu avec la rowkey. I HBase permet de gérer beaucoup de données... il n est pas adapté pour 1 seule machine. même architecture pour BigTable et HBase. Une région HBase correspond à une tablet BigTable
Bases Bases de graphes 29 / 30 Bases Bases de graphes 30 / 30 Bases de graphes Exemple : Neo4j I Utilisation d un moteur de stockage pour les objets, du type base de documents. I Mécanisme permettant de décrire des arcs (relations entre objets), arcs orientés et pouvant posséder des propriétés I Ces bases sont adaptées à la manipulation d objets complexes organisés en réseaux : cartographie, réseaux sociaux, web sémantique... Quelques exemples : I Neo4j I OrientDB fondation Apache I très e cace pour traverser un graphe (pas de jointure) I algorithmes classiques sur les graphes, que l on peut appeler avec l interface REST I Par défaut, Neo4j gère des transactions avec les propriétés ACID. I Pour le passage à l échelle en mode distribué, utiliser Neo4j HA (pour High Availability) : available et partition tolerant (A+P du théorème CAP) I Peut gérer plus de 30 milliards de sommets, et plus de 30 milliards de relations (arcs). I Pas de support pour de la programmation MapReduce