Accelerating SPARQL queries by exploiting hash-based locality and adaptive partitioning

Combining Vertex-Centric Graph Processing with SPARQL for Large-Scale RDF Data Analytics

“…up to 1.36B triples (corresponds to simulated data from 10,240 universities). We use the same YAGO2 and Bio2RDF queries used by AdPart [9], which span a wide range of structures and complexity classes. For LUBM, we use the queries defined by Atre et al [25] and used by most RDF engines [8], [9], [10], [11], [12]; additionally, we define two more complex queries (see Appendix B).…”

“…We call this version Spartex-Native. We compare Spartex-Native against the following systems: (i) AdPart [9] is the current state-of-the-art distributed in-memory RDF system. It uses workload adaptive graph partitioning and implements locality-aware query optimizations.…”

“…While the underlying framework is capable of performing graph analytics, these systems are optimized for solving SPARQL only. Even for SPARQL query evaluation and due to the expensive overhead of MapReduce-based joins, these systems perform poorly compared to the specialized ones [8], [9], [12]. Furthermore, MapReduce is not suitable for iterative graph algorithms as it requires passing the entire graph state from one iteration to the next [16].…”

“…Furthermore, MapReduce is not suitable for iterative graph algorithms as it requires passing the entire graph state from one iteration to the next [16]. All specialized RDF engines [5], [6], [7], [8], [9], [12], [25] are designed and optimized for SPARQL query evaluation. Unlike Spartex, they are incapable of performing generic graph processing over RDF data.…”

“…The state-of-the-art centralized [5], [6], [7] and distributed [8], [9], [10], [11], [12] RDF data management systems fail to support generic graph processing as they focus only on SPARQL, which lacks procedural capabilities. Expressing graph algorithms using SPARQL results in verbose and complex queries that are hard to formulate and expensive to evaluate [13], [14], [15].…”