An Experimental Comparison of RDF Data Management Approaches in a SPARQL Benchmark Scenario

Abstract

Abstract. Efficient RDF data management is one of the cornerstones in realizing the Semantic Web vision. In the past, different RDF storage strategies have been proposed, ranging from simple triple stores to more advanced techniques like clustering or vertical partitioning on the predicates. We present an experimental comparison of existing storage strategies on top of the SP 2 Bench SPARQL performance benchmark suite and put the results into context by comparing them to a purely relational model of the benchmark scenario. We observe that (1) in terms of performance and scalability, a simple triple store built on top of a column-store DBMS is competitive to the vertically partitioned approach when choosing a physical (predicate, subject, object) sort order, (2) in our scenario with real-world queries, none of the approaches scales to documents containing tens of millions of RDF triples, and (3) none of the approaches can compete with a purely relational model. We conclude that future research is necessary to further bring forward RDF data management.

Ultrawrap: SPARQL execution on relational data

“…In 2009, Schmidt et al compared Sesame triplestore with the triple table, vertical partitioned storage scheme and the native relational scheme on MonetDB, a column-store relational database. This study concluded that none of the RDF schemes was competitive to the native relational scheme [39]. In 2010, MahmoudiNasab and Sakr also compared the triple table, property table and vertical partitioned storage scheme with the native relational scheme on IBM DB2.…”

SW-Store: a vertically partitioned DBMS for Semantic Web data management

“…In this situation, all vertical partitions need to be accessed and unioned together or merged: this class of queries is also problematic for property tables; however, since there are fewer total property tables than vertical partitions, the relative performance overhead of unioning or merging everything together is more significant for the vertical partitioning approach. Although queries that do not restrict on property value are common in synthetic SPARQL benchmarks [42], we have found that, in practice, for the RDF applications we have worked with, such queries are rare. However, should an application contain queries that do not restrict on property value, the vertical partitions can be supplemented with auxiliary data structures that store data in a way that can accelerate this class of queries.…”

RDFPath: Path Query Processing on Large RDF Graphs with MapReduce

“…Executing path queries on very large RDF data sets like social network graphs with billions of entries is a non-trivial task that typically requires many resources and computational power [1,8,9,21,30]. RDFPath is a declarative RDF path query language, inspired by XPath and designed especially with regard to the MapReduce model.…”

“…However, management of large RDF graphs is a non-trivial task and single machine approaches are often challenged with processing queries on such graphs [30]. One solution is to use high performance clusters or to develop custom distributed systems that are commonly not very cost-efficient and also do not scale with respect to additional hardware [1,8,9].…”