一、client-side write buffer 客戶端快取請求
描述：可以快取客戶端的請求，以此來減少rpc的次數，但是快取只是被存在乙個arraylist中，所以多執行緒訪問時不安全的。
可以使用
getwritebuffer()方法來取得客戶端快取中的資料。 預設關閉。
二、scan的caching
描述： next( )方法請求一行就要使用一次r
pc,即使你指定了next(int nbrows)也一樣，很明顯這在效能上會存在一些問題，特別是每次都是請求乙個很小的cell的時候。這時候，我們可以考慮在每次rpc的時候，取出更多的row， 這就被稱為 scanner caching。這個cache可以在作用在兩個層面上:table與scan. 在table層面上， 所有對這table的scan都會啟用cache，你也可以只針對某乙個scan進行cache。
但是你需要權衡rpc次數與記憶體使用，假設你把快取數設定的太高了，就會適得其反。因為每次rpc需要取更多的資料，然後從伺服器傳到客戶端，假設超過了客戶端設定的heap最大值，那麼就會發生oom異常。不僅如此，就算沒有發生oom異常，但是由於傳輸時間長或者客戶端處理的時候過長，沒有在lease規定的時間內完成，那麼就會丟擲
scannertimeoutexception。
三、scan的batching
描述：之前說到了scan的caching，是針對行級別的，但是有時候row特別長，那cache起來就很有壓力了，這個時候，hbase給我們的另一種解決方案是batching， batching是針對列的。它可以控制每次請求next()要取出多少列。當然，就如之前所說，不要batch太多列，會有oom與
scannertimeoutexception的風險。
顯然2和3可以結合起來使用，在減少rpc次數的情況下，也能控制row和column的獲取。
四、rowlock
描述：mutate操作，put delete checkandput，等等，都會排它的執行，即它們肯定是序列操作的，不會發生並行操作。而get操作是不加鎖的，而是使用multiversion concurrency control style
來處理，說白了就是讀已經存在的最新的記錄。
， 但是要注意一點，假如lease過期了，那麼你回來再想使用這個rowlock的時候，就會丟擲unknownrowlockexception。
五、preflushing on stop
描述：當某台rs接收到被關閉的要求時，注意這裡，是正常的被通知下線，而不是由於什麼自身的異常導致的下線，rs會檢查所有的memstore，任何大小超過hbase.hregion.preclose.seize配置的memstore會被強制重新整理到硬碟（這裡指hdfs). 在這個階段的時候，rs包括region還是正常可以服務的，等到preflush完後，memstore裡面剩下的基本上都不多了，只要再執行一次flush就完成了，注意，到後面的那次flush的時候，rs已經不再接收請求了。preflush與其說是提高了region的可用性，不如說是使得rs的關閉更加平滑。
六、region split
描述： 這個是最最基礎的問題了，當然，hbase大多數的bug就是出現在這裡。當region中的storefile的總大小大於hbase.hregion.max.filesize設定的大小時，這個region就要split，在這個region一分為二的過程中，進行的非常快，因為hbase只需要為兩個新的region（在hbase中也成為daughters）建兩個reference file而已.當兩個daughters準備上可以上線的時候，後台執行緒會把父region的store files寫到兩個子region中，同時也會替換掉reference file。最後master會看看到底需不需要做load balance。
七、compactions
描述：當region內的storefile的數量大於hbase.hstore.compaction.min(hbase.hstore.compactionthreshold)時，就會觸發minor compaction，而每次minor ompaction所包含的最大檔案數由hbase.hstore.compaction.max指定。並且，hbase.hstore.compaction.min.size(通常設定成和memstore flush的值一樣)與hbase.hstore.compaction.max.size(通常設定為long.max_value)會進一步限制參與compact的檔案。與minor compaction不同， major compact會把所有的store裡面的檔案合成乙個大檔案，compact的型別在檢查階段就已經確定好了。以下幾種情況會觸發檢查compaction，1、shell中的compact或者major_compact請求 2、memstore flush後 3、請求相應的api中的majorcompact( ) 4、後台執行緒輪詢，時間由hbase.server.thread.wakefrequency和hbase.server.thread.wakefrequency,multiplier相乘所得。假如你在shell中請求了major_compact，或者請求了api中的majorcompact，都會強制執行majorcompact，在其它情況下，rs會依據hbase.hregion.majorcompaction來判斷是否應該執行major。
split和compact相對來說複雜點，我找時間再把原始碼拉出來分析下吧。說到原始碼，我把原始碼中compact執行緒中比較重要的一段注釋提一下：
合併storefiles，這可能需要一點時間。在這段時間時間中store還是能夠正常提供服務的，它還是能從storefile中取值，也能從memstore中寫入新的storefile。直到新的合併完的storefile已經全部寫到硬碟了，原來的storefiles才會刪掉。
Hbase簡單操作
hbase是我接觸的新東西。專案組也準備使用它開發乙個大的服務平台。我也趁機學習學習，先看看hbase的簡單操作方法吧 雖然hbase與傳統的關係型資料庫有很大的不同，但首先建張表還是必須的 定義幾個常量 public static hbaseconfiguration conf new hbase...
Hbase簡單使用
hbase main 003 0 create test first second 建立乙個名為test的表，裡面有兩個列族first second hbase main 007 0 put test row1 first a 1 往test表中新增資料，row1是標識 相當主鍵 first a 代...
hbase簡單操作
hbase shell 進入hbase list 給出所有表 count table name 檢視表的記錄數 scan table name 查詢多條記錄 scan table name limit 1 查詢一條記錄 truncate table name 清空表的記錄數 查詢含有 3091062...