1/23 2/23 Anne-Cécile Caron Master MIAGE - BDA 1er trimestre 2013-2014 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. Le cours d aujourd hui utilise le livre de Serge Abiteboul et al, Web Data Management http://webdam.inria.fr/jorge/ ainsi que le livre blanc de Smile sur : http://www.smile.fr/livres-blancs/culture-du-web/ 3/23 Recherche sur le web 4/23 : Recherche sur le Web 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. 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
Recherche sur le web 5/23 Recherche sur le web 6/23 Inverted File Inverted File - structure I comme le glossaire d un livre I à 1 mot clef on associe une collection de documents qui contiennent ce mot 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. 7/23 8/23 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. 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).
9/23 10 / 23 Schéma : LAN/data center 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. 11 / 23 Bases 12 / 23 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 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 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. I En, on choisit plutôt A+P.
Bases Bases 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. 13 / 23 Fonctions de base 1. map : (K, V )! list(k0, V 0) 14 / 23 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(k0, V 0)! list(k0, list(v 0)) regroupe les couples intermédiaires en fonction de leur clef. 3. reduce : (K0, list(v 0))! (K00, V 00) function reduce(term, counts) output (term, sum(counts)) Bases Exemple 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. 15 / 23 Bases Bases Nous allons voir maintenant les di érents paradigmes utilisés pour les bases. 1. stockage de couples (clé,valeur) 2. bases de documents 3. bases orientées colonnes 4. bases de graphes 16 / 23
Bases Couples (clef,valeur) 17 / 23 Bases 18 / 23 Couples (clef,valeur) La base est une table de hachage distribuée. On dispose en général de 4 opérations : 1. Create : créer un nouveau couple (clef,valeur). La valeur est n importe quel objet. I on stocke une collection 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,... 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. 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 I Voldemort, développé par LinkedIn en interne puis passage en open source. Bases 19 / 23 Bases 20 / 23 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 MapReduce : une vue est donc une liste de couples (clé,valeur) I Les vues sont matérialisées, indexées selon la clef par des B+arbres. Les vues sont mises à jour de façon incrémentale.
Bases Bases orientées colonnes 21 / 23 Bases Bases orientées colonnes 22 / 23 Bases orientées colonnes Exemple : BigTable 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 Bases de graphes 23 / 23 Bases de graphes 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