# MHBase: A Distributed Real-Time Query Scheme for Meteorological Data Based on HBase
## 4 Experiments and Analyses  
In this section, we conduct a comprehensive assessment through the experiments on the MHBase. Our experiments are conducted on a four-machine cluster, in which each machine uses default configurations in order to reduce influences on performance caused by various configuration settings. We deploy MHBase based on Hadoop-1.0.4 with an embedded ZooKeeper, the cluster-management component. One machine contains a master node and three _Regioservers_ (the other three machines), all of which are connected together via a gigabit Ethernet. Specific machine parameters and configuration settings are listed in Table 2.  
We take weather data from 1949 to 2014 and chose the most commonly used seventeen attributes from 120 fields included in observed site information. They are classified into two categories: identity fields and observed fields. In our experiments, we design rowkey with the combination of \"station number\", \"observation time (including year, month, day and hour)\" and \"data type\". The length of each column in rowkey should be fixed to identify the meaning of each digit conveniently. Other identity fields such as \"country number\", \"longitude\", \"latitude\" and \"station style\" are stored in one column family. We use another column family to store observed fields. The table structure is described in Table 3. Indexes have been built on top of 14 attributes among 17 columns. Our goal is to transfer a business platform from RDBMS to a cloud environment in order to improve price/performance ratio; therefore, we compare the different dataset sizes (records) between MHBase and MySQL. We have selected ten common queries, including querying by \"observation time\", \"country number\", _etc._ and the test performance for each case is the average of five times. Figure 6 shows the average time consumed by MySQL and MHBase. We discontinue testing MySQL without indexes because the query time had already reached more than seven seconds in five million rows. \begin{table}
\begin{tabular}{c c} \hline \hline
**Number of Nodes** & **4** \\ \hline OS & Ubuntu 12.04 (32-bit) \\  & CPU: Intel Core2 Duo, 2.66 GHz \\ Parameters & Memory: 2 GB RAM \\  & Hard Disk: WDCWD2500 (250 G / 7200 / p / min) \\  & HBase version: Based on HBase-0.94.8 \\  & **HBase configurations** \\ Configurations & hbase.hregion.max.filesize: 10 G \\  & hbase.hregion.memstore.flush.size: 128 MB \\  & hbase.client.write.buffer: 2 M \\  & hbase.client.scanner.caching: 10 \\  & **MySQL configurations** \\  & MySQL version: 5.6.28 (64-bit) \\  & Cluster mode: Standalone \\  & Default storage engine: INNODB \\  & innodb\_buffer\_pool\_size: 1230 M \\  & Transaction isolation: READ-COMITTED \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Configurations of the cluster Just as Figure 7 shows, the execution time of importing dataset into HBase and MHbase is stable. Although the performance of MySQL with indexes is excellent in small datasets, it began to decline with the increasing data scales. In addition, the speed of data import goes down significantly. Nevertheless, MHBase retrieves records via coprocessors in region-level, and the rowkey of the table in HBase is in lexicographical (alphabetical) order, so time consumption can be considered as a linear trend of growth. Note that the performance of MHBase is also better than MySQL with indexes from 18 million rows. It implies that MHBase will be more efficient in dealing with large-scale data.