hbase的cache與batch的理解

cache：
     在默認狀況下，若是你須要從hbase中查詢數據，在獲取結果ResultScanner時，hbase會在你每次調用ResultScanner.next（）操做時對返回的每一個Row執行一次RPC操做。即便你使用ResultScanner.next(int nbRows)時也只是在客戶端循環調用RsultScanner.next()操做，你能夠理解爲hbase將執行查詢請求以迭代器的模式設計，在執行next（）操做時纔會真正的執行查詢操做，而對每一個Row都會執行一次RPC操做。
 
     所以顯而易見的就會想若是我對多個Row返回查詢結果才執行一次RPC調用，那麼就會減小實際的通信開銷。這個就是hbase配置屬性「hbase.client.scanner.caching」的由來，設置cache能夠在hbase配置文件中顯示靜態的配置，也能夠在程序動態的設置。
 
     cache值得設置並非越大越好，須要作一個平衡。cache的值越大，則查詢的性能就越高，可是與此同時，每一次調用next（）操做都須要花費更長的時間，由於獲取的數據更多而且數據量大了傳輸到客戶端須要的時間就越長，一旦你超過了maximum heap the client process 擁有的值，就會報outofmemoryException異常。當傳輸rows數據到客戶端的時候，若是花費時間過長，則會拋出ScannerTimeOutException異常。
 
batch：
     在cache的狀況下，咱們通常討論的是相對比較小的row，那麼若是一個Row特別大的時候應該怎麼處理呢？要知道cache的值增長，那麼在client process 佔用的內存就會隨着row的增大而增大。在hbase中一樣爲解決這種狀況提供了相似的操做：Batch。能夠這麼理解，cache是面向行的優化處理，batch是面向列的優化處理。它用來控制每次調用next（）操做時會返回多少列，好比你設置setBatch（5），那麼每個Result實例就會返回5列，若是你的列數爲17的話，那麼就會得到四個Result實例，分別含有5,5,5,2個列。

RPCs=(Rows* Cols per Row) / Min(Cols per Row, Batch size) / Scanner caching