A survey on self‐organized semantic storage <s> The clustered tuple database <s> Parallel database machine architectures have evolved from the use of exotic hardware to a software parallel dataflow architecture based on conventional shared-nothing hardware. These new designs provide impressive speedup and scaleup when processing relational database queries. This paper reviews the techniques used by such systems, and surveys current commercial and research systems. <s> BIB001 </s> A survey on self‐organized semantic storage <s> The clustered tuple database <s> This paper describes the design of Clustered TDB, a clustered triple store designed to store and query very large quantities of Resource Description Framework (RDF) data. It presents an evaluation of an initial prototype, showing that Clustered TDB offers excellent scaling characteristics with respect to load times and query throughput. Design decisions are justified in the context of a literature review on Database Management System (DBMS) and RDF store clustering, and it is shown that many techniques created during the course of DBMS research are applicable to the problem of storing RDF data. <s> BIB002
The clustered tuple database (TDB) BIB002 is based on the highly successful stand-alone on-disk RDF store TDB. Like many RDF stores, TDB first maps RDF nodes to so-called NodeIDs using their literal representation. Using these NodeIDs as key, three index structures are created for each triple component, each containing a copy of all triples. To be able to perform queries on the indices, a fourth index maps each node's literal representation towards a NodeID. Large literal values are stored inside an additional table, however, the system always tries to store fitting literals directly inside the index ("inlining"). Extending TDB in order to create a clustered storage system hence required to distribute all five data structures. In general, data structures are distributed using horizontal hash partitioning BIB001 . Two groups of storage nodes are defined: a small group of control nodes ("query coordinators") handles queries, thus they each store a part of literal-NodeID mapping table as determined by hashing. Storage nodes store the triple indices as well as literal tables. The three triple indices are distributed onto the second group using a hash function to map the index keys from the triple component to a node identifier from the set of data nodes. Literal values can be resolved from NodeIDs, since this ID also includes the identifier of the node where the value is stored. Since every node can be located using the data present on the control nodes, any BGP with at least one fixed value can be resolved efficiently, with large possibilities of one-step query optimization. While being able to deliver an impressive access performance, clustered TDB has several weaknesses: the system's query capability depends entirely on the mapping table on the query coordinators. Failures here affect the entire system, not only those nodes. Also, the issue of hot spots within the network has not been handled sufficiently: first, NodeIDs have the identifier of the storing node hard-coded inside them, which inhibits cheap reorganization. Second, the method to handle excessively used URIs (such as rdfs:label or rdf:type) with a replicated list of exceptions represents a global state, which is both likely to be inconsistent as well as dependent on manual interaction.