scan caching
scanner一次快取多少資料來scan（從服務端一次抓多少資料回來scan）。
預設值是 1，一次只取一條。
scan attribute selection
scan時建議指定需要的column family，減少通訊量，否則scan操作缺省會返回整個row的所有資料（所有coulmn family）。
close resultscanners
通過scan取完資料後，記得要關閉resultscanner，否則regionserver可能會出現問題（對應的server資源無法釋放）。
optimal loading of row keys
當你scan一張表的時候，返回結果只需要row key（不需要cf, qualifier,values,timestaps）時，你可以在scan例項中新增乙個filterlist，並設定 must_pass_all操作，filterlist中add firstkeyonlyfilter或keyonlyfilter。這樣可以減少網路通訊量
turn off wal on puts
當put某些非重要資料時，你可以設定writetowal(false)，來進一步提高寫效能。writetowal(false)會在put時放棄寫wal log。風險是，當regionserver宕機時，可能你剛才put的那些資料會丟失，且無法恢復
啟用bloom filter
bloom filter通過空間換時間，提高讀操作效能
什麼時候需要write buffer？
預設情況下，一次put操作即要與region server執行一次rpc操作，其執行過程可以被拆分為以下三個部分：
t1：rtt(round-trip time)，即網路往返時延，它指從客戶端傳送資料開始，到客戶端收到來自服務端的確認，總共經歷的時延，不包括資料傳輸的時間；
t2：資料傳輸時間，即put所操作的資料在客戶端與服務端之間傳輸所消耗的時間開銷，當資料量大的時候，t2的開銷不容忽略；
t3：服務端處理時間，對於put操作，即寫入wal日誌（如果設定了wal標識為true）、更新memstore等。
其中，t2和t3都是不可避免的時間開銷，那麼能不能減少t1呢？假設我們將多次put操作打包起來一次性提交到服務端，則可以將t1部分的總時間從t1 * n降低為t1，其中t1為一次rtt時間，n為put的記錄條數。
正是出於上述考慮，hbase為使用者提供了客戶端快取批量提交的方式（即write buffer）。假設rtt的時間較長，如1ms，則該種方式能夠顯著提高整個集群的寫入效能。
那麼，什麼場景下適用於該種模式呢？下面簡單分析一下：
如果put提交的是小資料（如kb級別甚至更小）記錄，那麼t2很小，因此，通過該種模式減少t1的開銷，能夠明顯提高寫入效能。
如果put提交的是大資料（如mb級別）記錄，那麼t2可能已經遠大於t1，此時t1與t2相比可以被忽略，因此，使用該種模式並不能得到很好的效能提公升，不建議通過增大write buffer大小來使用該種模式。
如何配置使用write buffer？
如果要啟動write buffer模式，則呼叫htable的以下api將auto flush設定為false：
void setautoflush(boolean autoflush)
預設配置下，write buffer大小為2mb，可以根據應用實際情況，通過以下任意方式進行自定義：
1） 呼叫htable介面設定，僅對該htable物件起作用：
void setwritebuffersize(long writebuffersize) throws ioexception
2） 在hbase-site.xml中配置，所有htable都生效（下面設定為5mb）：
hbase.client.write.buffer
5242880
該種模式下向服務端提交的時機分為顯式和隱式兩種情況：
1） 顯式提交：使用者呼叫flushcommits()進行提交；
2） 隱式提交：當write buffer滿了，客戶端會自動執行提交；或者呼叫了htable的close()方法時無條件執行提交操作。
write buffer有什麼潛在的問題？
首先，write buffer存在於客戶端的本地記憶體中，那麼當客戶端執行出現問題時，會導致在write buffer中未提交的資料丟失；由於hbase服務端還未收到這些資料，因此也無法通過wal日誌等方式進行資料恢復。
其次，write buffer方式本身會占用客戶端和hbase服務端的記憶體開銷，具體見下節的詳細分析。
如何預估write buffer占用的記憶體？
客戶端通過write buffer方式提交的話，會導致客戶端和服務端均有一定的額外記憶體開銷，write buffer size越大，則占用的記憶體越大。客戶端占用的記憶體開銷可以粗略地使用以下公式預估：
hbase.client.write.buffer * number of htable object for writing
而對於服務端來說，可以使用以下公式預估占用的region server總記憶體開銷：
hbase.client.write.buffer hbase.regionserver.handler.count number of region server
其中，hbase.regionserver.handler.count為每個region server上配置的rpc handler執行緒數。
客戶端優化
from 輪迴mm 1.討厭的ie的濾鏡和css expressions少用，小心把瀏覽器搞掛，cup 100 宕機。2.css放到前面，js能放到後面的放在 後面。將頁面盡早展示給使用者。3.減少iframe的使用，避免cpu扛不住。4.減少dom個數，減低瀏覽器解析壓力。5.使用 而不是 imp...
客戶端優化經驗
從專案中積累了一些客戶端效能優化經驗 1.目前專案的在手機上跑，記憶體占用最大的是ui。在profile下看，一張2048的大圖集占用的記憶體比一張1024的圖集占用的記憶體要多出一倍，大概8m。所以優化方案是拆分圖集，把大圖集按功能分割成若干小圖集 做成1024 1024 把單獨的大圖獨自拉出來用...
HBase讀寫原理剖析以及客戶端優化策略
1 hbase客戶端若想將資料寫進habse集群的regionserver上，首先需要獲取要寫入資料的目標表所在的regionserver服務資訊，而服務資訊是儲存在系統元資料meta表中，即首先需要獲取meta表所在位置，而meta表節點位置資訊儲存在zookeeper中，此時hbase的客戶端的...