# MHBase: A Distributed Real-Time Query Scheme for Meteorological Data Based on HBase
## 4 Experiments and Analyses
\begin{table}
\begin{tabular}{c c} \hline
**Column** & **Data model** \\ \hline Rowkey & ”StationNumber\_year\_month\_day\_hour\_dataType” \\  & \multicolumn{2}{c}{**Examples:**} \\  & \multicolumn{2}{c}{“210044001\_02010\_01\_02\_2\_001”} \\ Family1: w\_meta & \multicolumn{2}{c}{**Qualifiers:**} \\  & country number (c\_Number), longitude (LON), latitude (LAT), station style (style) \\  & \multicolumn{2}{c}{**Examples:**} \\  & \multicolumn{2}{c}{“w\_metac\_Number = + 086”, “w\_meta: LON = 118”46”40.0”E”,} \\  & \multicolumn{2}{c}{“w\_meta: LAT = 32°03°42.0”N”, “w\_meta:style = GROUND”} \\ Family2: w\_info & \multicolumn{2}{c}{**Qualifiers:**} \\  & maxTEMP, minTEMP, stationPRES, clouds, windDirection, windSpeed, \\  & relativeHumidity, rainfall, observeYear, \\  & observeMonth, observeDay, observeHour, imgURL \\ \hline \end{tabular}
\end{table} 
Table 3: HBase table structure of meteorological data. Figure 6: Query time in weather dataset. Figure 7: The time of data import. We already know that HBase would trade off read efficiency on fields other than the primary key. Thus, the only way to search columns without rowkey is to take up a full table scan by a filter. As a consequence, we also make a comparison between MHBase and HBase with filters within 150,000 rows and the result in Figure 8 shows that filters cost more time because filters scan a full HBase table, while the time of MHBase can be thought as constant. An optimized query-by-filter method is more efficient at creating a scanner with a prefix-match first, and then filter data on other columns in the range of a start key and a stop key. For example, if we want all records generated from a station with number \"210044001\", we can set \"210044001\" as start key and \"210044001\" + \"/0 xff\" as the stop key and then use filters to retrieve columns other than rowkey because our rowkey starts with the station number and observed time. However, this scenario is impractical and lacks credibility, so we just use this special query case to illustrate the performance of MHBase. Figure 9 shows the time of same query case between MHBase and HBase (query by prefix). As shown in Figure 10, prefix matched queries can locate the range of target region directly and accurately, and afterwards filters work in the specific range. But MHBase use coprocessors to get records in a parallel approach; that is, the essence of an indexed query is one prefix-match and one rowkey-get operation, so it will be slower than retrieving directly by rowkey. The reason for the raised interval between two million and three million in the picture is that the region splitting causes I/O load to rise. The query's response time for both methods are close to each other using millions of data but the diversity of retrieval by MHBase is increased. Figure 8: Performance in different data size. Figure 9: Time of indices query and prefix query. We also use YCSB (Yahoo! Cloud Serving Benchmark) [30] to conduct stress tests on both MHBase and HBase. We test the performance with different pressure. As shown in the Figure 10a, it is observed that the throughput of MHBase will reduce and is lower than native HBase when inserting data using ten threads concurrently and its write operation is not so excellent because MHBase needs to write to the index table synchronously. In Figure 10b, there is almost no difference in 100% read circumstance. Generally, both throughputs are improved with the increase of pressure (threads). As our experimental results show, with the benefit of indexes, MHBase can greatly improve the querying speed, even if there is a slight performance penalty in write operation, and provide multiplicity and high performance of data accesses on non-primary keys. That is to say, MHBase achieves a balance in read and write performance because data import in our meteorological system is offline.