data liftjan2012

ConstatsTravaux dans le contexte des SGBDR

MapReduceTravaux dans le contexte des bases NoSQL

Conclusion

NoSQL et le stockage de triplets RDFAG ANR Datalift (17-18 janvier 2012)

Olivier Cure

UPEMLV , LIGM UMR CNRS 8049, France

January 19, 2012

Olivier Cure



Conclusion

Plan

Constats sur RDF

Travaux dans le contexte des SGBDR

Map Reduce

Travaux dans le contexte des bases NoSQL

Conclusion

Olivier Cure



Conclusion

Constats

RDF est un modele de donnees sans aucune recommendationsur l’organisation de la persistance des triplets.

Plusieurs solutions disponibles sur des technologies differentes.

Fournir une solution efficace, performante, robuste etpermettant une montee en charge est toujours un problemeouvert.

Ecosysteme des bases de donnees riche et en evolution.

Olivier Cure



Conclusion

Olivier Cure



Conclusion

Ecosysteme NoSQL

Olivier Cure



Conclusion

Objectifs de la presentation

Mettre evidence les principales approches au travers desparametres suivants:

couche de stockageindexationtraitement des requetes

dans les solutions SGBDR et NoSQL

Olivier Cure



Conclusion

Travaux dans le contexte des SGBDR

Les premieres solutions de persistance de triplets RDF sebasent sur les SGBDR (Jena, Sesame, 3Store, Redland,swStore, etc.)

Plusieurs dispositions possibles:

’Triple Table’: ensemble des triplets dans une unique tableavec 3 colonnes (Sujet, Propriete, Objet).’Clustered property table’: Une table par regroupement deproprietes.’Property class table’: Regroupement des sujets d’une classedans une table.’Vertically partitioned table’: 1 table par propriete. (swStore)

Olivier Cure



Conclusion

Indexation

Efficacite de l’execution des requetes depend du systemed’indexation

Les principales solutions se basent sur de multiples indices(Hexastore, Kowari, Virtuoso, RDF-3X, YARS, etc.)

Hexastore propose une solution basee sur 6 indexes differents:pso, pos, spo, sop, ops et osp; 6 indexes binaires(sp,so,ps,po,os,op) et 3 unaires (s,p,o)

Olivier Cure



Conclusion

Limites de l’approche SGBDR

Distribution des donnees sur plusieurs machines: ’sharding’manuel, temps de latence lie aux replications avec unenvironnement ACID.

Parallelisation de certains traitements: difficile d’integrer desenvironnements comme MapReduce → Hadapt, Oracle etcloudera, Vertica.

Maintenance des (15!) indexes et performance avec lesrequetes de modification

Olivier Cure



Conclusion

Approches distribuees1 distribue les noeuds du graphe sur un cluster de machines.

Chaque machine stocke son sous-graphe dans une instanceRDF-3X

Les sous graphes partagent des noeuds pour eviter descommunications inter-machines.

Certaines requetes s’executeront en parallele en utilisantHadoop (implementation de MapReduce).

Autres solutions distribuees: YARS2, SHARD, Virtuoso

1Huand et al: Scalable SPARQL Querying of Large RDF Graphs. VLDB2011

Olivier Cure



Conclusion

MapReduce

Killer application of cloud computing

Un environnement pour realiser des calculs en parallele sur desdonnees distribuees 2

Hadoop, une implementation open-source de la fondationApache s’integre avec de nombreuses bases NoSQL (HBase,Cassandra, CouchDB, etc.).

Tolerance aux pannes avec redistribution automatique destaches sur le noeuds de la grappe de machine.

Nombreuses extensions apparaissent: apprentissage (Mahout),traitement de graphes (Giraph), etc.

2J. Dean et al. ”MapReduce: Simplified Data Processing on Large Clusters”OSDI 2004

Olivier Cure



Conclusion

Olivier Cure



Conclusion

Key-valueColumn familyDocumentGrapheProchaines extensions

Definition de NoSQL

Not Only SQL

Un ensemble de BD repondant :

a la croissance exponentielle de la taille des bases de donneesla structuration des documents stockesla connectivite des donneesl’architecture des applications exploitant des bases de donnees

Olivier Cure



Conclusion


Motivation par le theoreme de CAP3,4

Dans un systeme informatique distribue, il n’est possibled’avoir simultanement plus de deux des proprietes suivantes:

Consistency: un service est execute totalement ou pas du tout(proche du concept d’Atomicite d’ACID)Availability: le service est toujours accessiblePartitioning tolerance: aucun ensemble de pannes autre que larupture totale du reseau n’est acceptable pour que le systemene fonctionne pas.

3talk at ACM PODC 20004S. Gilbert, N.Lynch: Brewer’s conjecture and the feasibility of consistent,

available, partition-tolerant web services. SIGACT News 33(2): 51-59 (2002)Olivier Cure



Conclusion


Olivier Cure



Conclusion


Les choix possibles

CA, i.e. faire sans ’partition tolerance’ : Tout sur une seulemachine, pas de ’scaling out’.

CP, i.e. faire sans ’availability’: probleme de temps de latenceentre operations de modification. Complexite de solutions derecouvrement des bases.

AP, i.e. faire sans ’consistency’. En fait, il y a un spectre desniveaux de consistance, ex: ’eventual consistency’. Un levierimportant des solutions NoSQL.

Olivier Cure



Conclusion


Olivier Cure



Conclusion


Ecosysteme NoSQL

4 categories NoSQL

Key Value storeColumn familyDocumentGraphe

Olivier Cure



Conclusion


Key-Value (1)

Origine: Dynamo @ Amazon 5

Modele de donnes: Mapping global de couples de cle valeur.Hash map distribue

Modele le plus simple.

Autres systemes: Voldemort (LinkedIn), Tokyo (Cabinet,Tyrant), Riak (Basho), Oracle NOSQL

5G. De Candia et al. Dynamo: Amazon’s highly available key-value store.SOSP 2007

Olivier Cure



Conclusion


Stockage RDF base Key-Value

Riak: distribue, ’horizontal scaling’, map reduce.

Experimentation de M.Hausenblas sur le stockage de tripletsRDF sur Riak.

En associant chaque ressource RDF a un objet Riak.

Olivier Cure



Conclusion


Column family

Origine: Bigtable @ Google 6

Modele de donnees: une unique table avec des familles decolonnes

Autres systemes: HBase (Apache), Cassandra (Apache),HyperTable, SimpleDB

6F. Chang et al. Bigtable: a distributed storage system for structured data.OSDI 2006

Olivier Cure



Conclusion


Cassandra

Organisation sous forme de couples cle-valeur imbriquees

keyspace → ColumnFamily → row key → columnKey → value

keyspace → ColumnFamily → row key → super column key→ columnKey → value

Une colonne est composee d’un nom, d’une valeur et d’untimestamp (versioning)

Les colonnes et super colonnes sont triees

Olivier Cure



Conclusion


Cassandra (2)

Distribution suivant le principe de ’Consistent hashing’, surune anneau avec une replication automatique

Distribution apres panne est automatique

Differents niveaux de consistance

Olivier Cure



Conclusion


Exemple Column family

Olivier Cure



Conclusion


Stockage RDF base Column Family

Application de l’indexation de Hexastore dans HBase7.Traitement des requetes SPARQL dans le frameworkMapReduce.

CumulusRDF8 propose 2 approches: une base sur les supercolonnes de Cassandra et une basee strictement sur les famillesde colonnes. Exploite 3 indexes dans la version super colonnes

7J. Sun et al. Scalable RDF Store Based on HBase and MapReduce.ICACTE 2010

8G. Ladwig et al. CumulusRDF: Linked Data Management on NestedKey-Value Stores. SSWS 2011

Olivier Cure



Conclusion


Stockage RDF base Column Family (2)

Stratusstore9: 1 unique index sur le sujet des triplets sur labase SimpleDB du cloud d’Amazon.

9R. Stein et al: RDF On Cloud Number Nine. NeFoRS 2010Olivier Cure



Conclusion


Document

Origine: Lotus notes

Modele de donnees: Collections de documents ou undocument est une collection de couples cle-valeur

Autres systemes: CouchDB (Apache), MongoDB (10gen),Terrastore

Olivier Cure



Conclusion


MongoDB

Une collection regroupe des documents.

Un document est l’unite de base et correspond a une instanceJSON.

Support du document imbrique, listes.

Chaque document a une cle unique dans une collection.

Les collections sont stockees dans une base de donnees.

Support de l’indexation dans une collection

Olivier Cure



Conclusion


MongoDB (2)

Taille max. d’un document:4Mo.

2Go avec GridFS

Replication basee sur une approche Master-Slave avec reprisesur panne automatique.

Replication asynchrone

Sharding automatique et transparent

Quand ’sharder’: probleme d’espace disque, ecrire plus vite,plus de cache

Olivier Cure



Conclusion


Exemple Document DB

Olivier Cure



Conclusion


Stockage RDF base NoSQL document

Un adaptateur pour le stockage de triplets RDF sur CouchDB(rdf-couchdb sur github)

Un adaptateur pour MongoDB (MongoDB-RDF sur github)

Olivier Cure



Conclusion


Graphe

Origine: Theorie des graphes

Modele de donnees: Noeuds avec des proprietes

Autres systemes: Neo4J, InfiniteGraph, Sones GraphDB,Trinity (Microsoft), FlockDB (Twitter donne a Apache)

Olivier Cure



Conclusion


Neo4J

Inspire de Lotus Notes

Des couples cle-valeur sur les noeuds et les proprietes.

Moteur de stockage sur disque binaire en natif

Transactionel

Sharding est manuel

Montee en charge: 1 milliard d’entites (Ok) pas 100 milliards.

Olivier Cure



Conclusion


Stockage RDF base sur BD graphe

Support natif de SPARQL sur Neo4J

Pas d’experimentation visible (probleme de distribution)

Olivier Cure



Conclusion


Olivier Cure



Conclusion


En general, on peut representer une instance d’un modeledans les autres modeles.

Pour les systemes existants:

Points communs: pas de schema, pas de jointurePrincipales differences: approche de consistance, detection desconflits, controle de la concurrence, integration du parallelisme

Olivier Cure



Conclusion


Plus d’ACIDity10

MongoDB ajoute ’durable logging storage’ dans sa version 1.7Cassandra ajoute une consistance forte dans la version 1.0

Des langages de requetes:

MongoDB en a un depuis el debutCassandra : CQLCouchbase : UnQLNeo4J : Cypher

Plus de Schema

10Emil Eifrem at NOSQL eXchange 2011Olivier Cure



Conclusion


Avantages de l’approche NoSQL

Distribution des donnees

Bonne integration avec MapReduce (Hadoop)

Nombreux projets tres actifs

RDF semble plus adapte a un contexte BASE que ACID

Olivier Cure



Conclusion


Limites de l’approche NoSQL

Maturite des implementations

Jointures

Langages de requetes

Heterogeneite des modeles

Manque d’outils pour l’administration

Olivier Cure



Conclusion

Conclusion

Probleme du stockage de triplets est ouvert car il fautrepondre aux besoins de

distribution des donneesparallelisation des traitementsMaintenance des triplets et des indexes

NoSQL a de nombreux atouts mais les SGBDR s’adaptent(e.g. mecanisme de transaction en RAM).

L’adoption d’une approche doit etre motiee par les usages destriplets et choisir l’outil le plus adapte

Quelques pistes: nouvelles solutions pour l’indexation (e.g.’index cracking’), prendre en compte les ontologies, nouvellesinfrastructures hybrides SGBDR-NoSQL, etc.

Olivier Cure



Conclusion

Persistance polyglotte

Dans 11 nous avons propose une couche d’abstraction pourl’acces a des donnees stockees dans des SGBDR et NoSQL.

11O. Cure, C. Le Duc et M. Lamolle: Data integration over NoSQL StoresUsing Access Path Based Mappings. Dexa 2011

Olivier Cure



Conclusion

Les requetes sur le schema virtuel (SQL ou SPARQL) sonttraduites dans un langage intermediaire (BQL) pour permettreune traduction vers chaque NoSQL store.

Olivier Cure



Conclusion

Merci de votre attention

Olivier Cure

data liftjan2012

Technology