In recent years, the increased need to house and process large volumes of data has prompted the need for distributed storage and querying systems. The growth of machine-readable RDF triples has prompted both industry and academia to develop new database systems, called NoSQL, with characteristics that differ from classical databases. Many of these systems compromise ACID properties for increased horizontal scalability and data availability. This thesis concerns the development and evaluation of a NoSQL triplestore. Triplestores are database management systems central to emerging technologies such as the Semantic Web and linked data. The evaluation spans several benchmarks, including the two most commonly used in triplestore evaluation, the Berlin SPARQL Benchmark, and the DBpedia benchmark, a query workload that operates an RDF representation of Wikipedia. Results reveal that the join algorithm used by the system plays a critical role in dictating query runtimes. Distributed graph databases must carefully optimize queries before generating MapReduce query plans as network traffic for large datasets can become prohibitive if the query is executed naively.
Several cloud triple stores exist today and have vast differences among one another. Among these systems are 4store @cite_35 , CumulusRDF (Cassandra) @cite_20 , HBase @cite_31 , and Couchbase http: www.couchbase.com . In a comparative study of all of these triple-stores (including our HBase-Hive implementation), systems using MapReduce introduced significant query overhead while strictly in-memory stores were unable to accommodate large datasets @cite_15 . It was discovered that queries involving complex filters generally performed poorly on NoSQL systems. However, traditional relational database query optimization techniques work well in NoSQL environments.
@cite_35 @cite_31 @cite_20 @cite_15
163708704 2339861584 1906114547
A common approach to providing persistent storage for RDF is to store statements in a three-column table in a relational database system. This is commonly referred to as a triple store. Each table row represents one RDF statement. For RDF graphs with frequent patterns, an alternative storage scheme is a property table. A property table comprises one column containing a statement subject plus one or more columns containing property values for that subject. In this approach, a single table row may store many RDF statements. This paper describes a property table design and implementation for Jena, an RDF Semantic Web toolkit. A design goal is to make Jena property tables look like normal relational database tables. This enables relational database tools such as loaders, report writers and query optimizers to work well with Jena property tables. This paper includes a basic performance analysis comparing a triple store with property tables for dataset load time and query response time. Depending on the application and data characteristics, Jena property tables may provide a performance advantage compared to a triple store for large RDF graphs with frequent patterns. The disadvantage is some loss in flexibility. Publishers of Linked Data require scalable storage and retrieval infras- tructure due to the size of datasets and potentially high rate of lookups on popular sites. In this paper we investigate the feasibility of using a distributed nested key- value store as an underlying storage component for a Linked Data server which provides functionality for serving Linked Data via HTTP lookups and in addi- tion offers single triple pattern lookups. We devise two storage schemes for our CumulusRDF system implemented on Apache Cassandra, an open-source nested key-value store. We compare the schemes on a subset of DBpedia and both syn- thetic workloads and workloads obtained from DBpedia's access logs. Results on a cluster of up to 8 machines indicate that CumulusRDF is competitive to state-of-the-art distributed RDF stores. Processing large volumes of RDF data requires sophisticated tools. In recent years, much effort was spent on optimizing native RDF stores and on repurposing relational query engines for large-scale RDF processing. Concurrently, a number of new data management systemsregrouped under the NoSQL (for "not only SQL") umbrellarapidly rose to prominence and represent today a popular alternative to classical databases. Though NoSQL systems are increasingly used to manage RDF data, it is still difficult to grasp their key advantages and drawbacks in this context. This work is, to the best of our knowledge, the first systematic attempt at characterizing and comparing NoSQL stores for RDF processing. In the following, we describe four different NoSQL stores and compare their key characteristics when running standard RDF benchmarks on a popular cloud infrastructure using both single-machine and distributed deployments.