缺點

1 不能支持條件查詢，只支持按照Row key來查詢.

2 暫時不能支持Master server的故障切換,當Master宕機後,整個存儲系統就會掛掉.

1.數據類型，Hbase只有簡單的字符類型，所有的類型都是交由用戶自己處理，它只保存字符串。而關係數據庫有豐富的類型和存儲方式。在使用過程中，創建表的時候只感知到了創建列簇，指定過期時間等等，沒有感知到指定數據類型等操作。
2.數據操作：HBase只有很簡單的插入、查詢、刪除、清空等操作，表和表之間是分離的，沒有複雜的表和表之間的關係。
3.存儲模式：HBase是基於列存儲的，每個列族都由幾個文件保存，不同的列族的文件時分離的。而傳統的關係型數據庫是基於表格結構和行模式保存的。
4.數據維護，HBase的更新操作不應該叫更新，它實際上是插入了新的數據，而傳統數據庫是替換修改。這裏理解是一個rowkey實際對應多份數據，按照插入數據的時間倒序，查詢時返回最後插入的一份數據。

pre-split

split負載均衡。hbase會將數據split到一定數量的region中來實現負載均衡。一個table會被分到一個或者多個region中。這些region會被分配到一個或者多個regionServer中。在自動split策略中，每個region達到一定大小就會被自動split。split根據rowkey，同一個rowkey對應的行只會在一個region中。

如果沒有presplit，table剛剛創建的時候，所有的讀寫操作都會訪問到同一個regionServer的同一個region中。無法達到負載均衡的目的。同時，好像region自動split也是需要更多的性能和時間的（待確認，需要詳細看下split的過程）。通過預測rowkey，確定需要pre-split的節點。

RowKey

目前讀寫操作都需要通過rowkey，rowkey也決定了split的節點。

rowkey是一個二進制碼流，可以是任意字符串，最大長度64kb，實際應用中一般爲10-100bytes，以byte[]形式保存，一般設計成定長。建議越短越好，不要超過16個字節，原因如下：

數據的持久化文件HFile中是按照KeyValue存儲的，如果rowkey過長，比如超過100字節，1000w行數據，光rowkey就要佔用100*1000w=10億個字節，將近1G數據，這樣會極大影響HFile的存儲效率；
MemStore將緩存部分數據到內存，如果rowkey字段過長，內存的有效利用率就會降低，系統不能緩存更多的數據，這樣會降低檢索效率。

目前操作系統都是64位系統，內存8字節對齊，控制在16個字節，8字節的整數倍利用了操作系統的最佳特性。