關于近期HBase系統設計開發和性能調優的一些小結
- 全局查詢策略
應該一邊倒地依賴索引進行查詢，保證絕大多數的查詢是秒級返回。盡量避免動用全表掃描，讓全表掃描僅服務于非常有限的“生僻”查詢！實現這種格局需要盡可能地保證索引輕量短小(盡量縮短字節)，然后創建多倍于主數據的索引數據（我們基于配置創建索引的機制保證了增加一條索引的工作量是可以忽略不計的），讓索引能覆蓋絕大多數的查詢。之所以這樣做可行且高效是基于這樣兩點：一、在基于rowkey檢索時HBase的性能是非常高的，完全不受數據條數的影響，我們基于索引的查詢本質上是基于rowkey的查詢，因此無論創建多少倍于主數據的索引數據都不會對性能產生明顯影響。二、保持索引輕量短小是為了節約存儲空間，降低全部數據的體量，同時也利于建立更多的索引。
- 關于排序和結果集上限
類似于淘寶上的商品檢索，可供排序的字段（人氣，銷量，信用，價格）和結果集上限（100頁）是嚴格控制的，我們對排序和結果集上限也是有嚴格要求的，從實質上講這些是所有分布式系統在進行全集計算時都會面臨的問題（還有一個常見的問題就是join，join也是基于數據全集進行的計算)。對于我們系統的排序：由于一種索引只能指定一個排序字段，因此，可以查詢的排序字段應該嚴格控制，盡量貼近實際需要選擇最少的字段。體現到上層應用的UI上，就應像淘寶一樣，將支持的排序字段以單選框方式列出供用戶選擇。對于結果集上限，過大的結果集在返回客戶端后會導致OOME，為此我們提供了一個可配置的參數 core.query.maxResultLimit，任何查詢要求的上限如果超出了該值在執行前會拋出異常終止查詢。
- 數據體量和BlockCache
通過前一段時間的性能測試，關于BlockCache有如下結論：
當數據體量<BlockCache時，全部數據被加載到內存中，cache的命中率是100%，任何查詢都將達到性能最優！
當數據體量>>(遠大于)BlockCache時，在進行全表掃描時（默認情況下，scan時，scan到的數據會被加載到cache!），所有的數據都將遍歷一邊，它們依次被加載到cache里，然后在cache滿時被后面加入的新數據替換出去，由于是全表掃描，超過cache數倍的數據會加載到內存然后再被替換出去，整個查詢過程中cache在持續地顛簸，性能非常差，遠遠超過了關閉BlockCache時的全表掃描。為此我們提供了一個重要的配置參數：server.search.enableBlockCacheForSearch
部署時，若數據體量<BlockCache，設為true，若數據體量>>(遠大于)BlockCache時，設為false
4. 為什么不在索引數據上冗余多余的列？
在索引數據上冗多余列的初衷大概有這么兩個方面：一是寄希望于冗余出的列支持更多條件的查詢，二是過去添加索引需要建立一張單獨的索引表，建立索引的成本（工作量）是很高的，為了能充分利用這張索引表都會冗余一些字段，基于這樣一種慣性思維，也希望在新的索引機制下冗余字段。但實際上在新的索引機制下是完全不需要也應該再冗余多余列的，這是原為：首先，建立索引已經變得非常簡單，建立索引的成本（工作量)是非常低的，所以不再需要在水平方向上“拉伸”索引，而是應該在垂直方向上“擴展”所引，也就是建立更多包含不同字段的索引。第二點，重復第一點的理由，通過冗余的列所支持到的查詢不但可以完全使用新的索引來支持，且速度只會比這種方式更快，因為該方式在定位了索引之后還需要取出各個qualifier進行比對，性能比更長包含更多字段的索引而言差距是顯而易見的。第三點：在使用索引檢索時是先通過scan索引找到目標數據的rowkey然后發起一個二次的Get（HRegion不支持批量put）請求得到目標數據。如果寄希望通過多冗余幾個字段，只scan索引數據而不去二次get主數據是不現實的，因為絕大部分的查詢需要的是整條記錄而不是一條記錄中的某幾個字段，除非索引冗余了全部列。
- 一個小技巧
如果節點數量為N，N是一個比較小的數值，而單個節點可以冗余N倍的數據話，就將hdf.replication設為N，這是保證本地化讀取的最簡單方法，可以有效地提升系統的性能。遠期目標應該實現一個基于block進行本地化分配的LoadBalancer，特別是在region re-online的時候，這貌似是一個很基礎的需求，不知hbase何會加入？
來自：http://blog.csdn.net/bluishglc/article/details/18811129
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！