Presented by Cathrin Weiss, Panagiotis Karras, Abraham Bernstein Department of Informatics, University of Zurich Summarized by: Arpit Gagneja Hexastore: Sextuple Indexing for Semantic Web Data Management

Overview Hexastore – Sextuple Indexing A Triple (S, P, O) can be represented in six ways (3! = 6) SPO, SOP, PSO, POS, OSP, OPS (Takes the idea of vertical partitioning to its full logical conclusion) Every possible indexing scheme can be materialized Allows quick and scalable query processing Up to five times bigger index space is needed In this presentation, Review conventional RDF storage structures Introduction to Hexastore Discussion

Physical Designs for RDF Storage (1/4) Sample triplets SELECT ?title WHERE { ?book ?title. ?book. ?book }  Join! Join! (Will see merge pairwise join in Hexastore!, How merge pairwise join is effective? Will see)  Entire Table Scan!  Redundancy!

Clustered Property Table Contains clusters of properties that tend to be defined together Physical Designs for RDF Storage (2/4)

Physical Designs for RDF Storage (3/4) Property-Class Table Exploits the type property of subjects to cluster similar sets of subjects together in the same table Unlike clustered property table, a property may exist in multiple property-class tables Values of the type property

Physical Designs for RDF Storage (4/4) Vertically Partitioned Table The giant table is rewritten into n two column tables where n is the number of unique properties in the data We don’t have to Maintain null values Have a certain clustering algorithm subject property object

Motivation The problem of having non-property-bound queries

Hexastore: Sextuple Indexing O O P P P P O O S S S S O O P P P P S S S S P P O O S S S S O O P P O O O O P P S S

Five-fold Increase in Index Space Sharing The Same Terminal Lists SPO-PSO, SOP-OSP, POS-OPS The key of each of the three resources in a triple appears in two headers and two vectors, but only in one list

Mapping Dictionary Replacing all literals by unique IDs using a mapping dictionary Removes redundancy and helps in saving a lot of space We can concentrate on a logical index structure rather than the physical storage design SPO object214hasColorblue object214belongsToobject352 ……… SPO ……… IDValue 0object214 1hasColor ……

Clustered B + -Tree (RDF-3X, VLDB 2008) Store everything in a clustered B + -Tree Triples are sorted in lexicographical order Allowing the conversion of SPARQL patterns into range scan We don’t have to do entire table scan 002… SPO ……… Actually, we don’t need this table! IDValue 0object214 1hasColor ……

Argumentation Concise and Efficient Handling of Multi-valued Resources Index can contain multiple items cf. Multi-valued Property Table Avoidance of NULLs Only those RDF elements that are relevant to a particular other element need to be stored in a particular index No ad-hoc Choices Needed Most other RDF data storage schemes require several ad-hoc decisions about their data representation architecture ex. Clustered Property Table (which properties to be stored together)

Argumentation Reduced I/O cost Other RDF storage schemes may need to access multiple tables which are irrelevant to a query Queries that are not bounded by property All First-step Pairwise Joins are Fast Merge-Joins The key of resources in all vectors and lists used in a Hexastore are sorted Reduction of Unions and Joins ex. a list of subjects related to two particular objects through any property Hexastore can use osp index

Treating the Path Expression Problem Select B.subj FROM triples AS A, triples AS B WHERE A.prop = wasBorn AND A.obj = ‘1860’ AND A.subj = B.obj AND B.prop = ‘Author’ A path expression requires (n-1) subject-object self-joins where n is the length of the path Vertical Partitioning Materialized Path Expressions (A.author:wasBorn = ‘1860’) n-1 C 2 = O(n 2 ) possible additional properties Hexastore (n-1) merge-join using pso and pos indices

Experimental Evaluation Setup 2.8GHz dual core, 16GB RAM Competitors Column-oriented Vertical Partitioning Approaches COVP1 – PSO Index COVP2 – PSO Index + POS Index (second copy) Hexastore SPO, SOP, PSO, POS, OSP, OPS Datasets Barton, MIT library data, 61 mil. triples, 258 properties LUBM, A synthetic benchmark data set(10 univ.), 6.8 mil. triples, 18 predicates

Performance (Barton Data)

Performance (LUBM, 10)

Memory Usage In practice, Hexastore requires a four-fold increase in memory in comparison to COVP1, which is an affordable cost for the derived advantages

Conclusion Hexastore: Sextuple-Indexing Scheme Worst-case five-fold storage increase in comparison to a conventional triples table Quick and scalable general-purpose query processing All pairwise joins in a Hexastore can be rendered as merge joins Optimizations: Some indexing patterns never used like Database Cracking suggested in paper

Thank You