## 7 Experimental Analysis and Results  
In this Section, we illustrate our experimental assessment and analysis that we devised in order to demonstrate the feasibility of our approach, and the effectiveness and the efficiency of our algorithms. The experimental environment used for our experiments is depicted in Figure 6. In particular, the target cluster comprises five hosts having the hardware described in Table 1.  
In our experimental campaign, we ran tests on top of our cluster in order to verify its functionality and throughput first. These tests give us a baseline that was helpful to tune the cluster through the various configuration options and the schema of tables themselves. _The Yahoo! Cloud Serving Benchmark_ (YCSB) [77] was used to run comparable workloads against different storage systems. While primarily built to compare various systems, YCSB is also a reasonable tool for performing an HBase cluster burn-in or performance-oriented tests (e.g., [78]). To this end, it is necessary to create some tables and load a bunch of test data (selected by the user or randomly generated) into these tables (generally, \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Core Num.** & **Core Speed (GHz)** & **HDD** & **RAM (GB)** \\ \hline
6 & 2.4 & 1 & 6 \\
8 & 2.4 & 1 & 2 \\
4 & 2.7 & 1 & 4 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Hardware in the cluster of the experimental environment. Figure 6: System environment. at least \(10^{8}\) rows of data should be loaded). In order to load data, we used the YCSB client tool [77] by generating a synthetic dataset that comprises \(10^{12}\) rows. After loading the data, YCSB permits to run tests with the usage of the CRUD operations in a set of \"workloads\". In the YCSB's semantics, workloads are configuration files containing the percentage of operations to do, how many operations, how many threads should be used, and other useful experimental parameters. We ran tests on both the default configuration and other tentative configurations by reaching a throughput of 1300 Op/s for reading-like operations and 3500 Op/s for writing-like operations, thus increasing by 50% the performance obtained with the default configurations. It is worth mentioning that, using both the Snappy compression scheme for reducing the size of data tables and Bloom filters for implementing the membership test in the adjacent lists (which may become very large in real-life RDF graphs) contributed in the performance gain heavily. Table 2 reports the experimental results provided by this experiment, which comprises the impact of communication costs. After the first series of experiments devoted to assess the throughput of the framework, we focused our attention on the data management capabilities of the framework by introducing an efficient schema and an efficient client capable of uploading and retrieving data efficiently, _i.e._, based on the effective schema designed. The first solution contemplated an RDBMS(_Relational DataBase Management System_)-like approach to the schema design while the second one was more akin to NoSQL paradigms. As it will be mentioned later, the second approach is the one that exposes the best during the retrieval phase, lagging behind the first approach for data uploading. Due to the fact that the performance difference, however, was negligible, the second approach was the one to be implemented. To both solutions, all the optimizations about performance increasing discovered during the \"load test\" phase were applied (_i.e._, table data Snappy-based compression and Bloom filters). Therefore, we finally implemented three tables for HBase data storage (see Figure 7).