這裡只準備介紹我實際操作中遇到的一些使用優化或解決辦法，想大致了解hbase優化的同學可以參考我之前轉載的幾篇博文。
1.第乙個我想說的是hbase的寫操作，api層面上的優化（比如批量寫，關閉wal之類的）我這裡就不囉嗦了，我想要說的是rowkey的設計，這個問題一般會跟io的大小息息相關，io越大，rowkey的設計就必須更謹慎，避免出現資料熱點，往往乙個不好的設計會導致某些regionserver的負載非常大，而某些regionserver則非常空閒，嚴重影響讀寫效能及可用性。比如乙個以時間戳作為rowkey的表設計，往往新產生的日誌寫入都是在最後的region，這樣的話不管該錶的regions怎麼分布，所有的寫入壓力都只在管理最後region的regionserver上。如果存在多個這樣的表，極有可能使某個regionserver的負載過大而導致regionserver宕掉，所以我們最好不要用時間戳作為rowkey字首。我以前管理過這麼乙個hbase集群，規模不大，但每天的寫入量不小，它的表基本都是以時間戳作為字首，然後呢每次監控都會有某幾台機器各種飄紅，然後宕掉，最後整個集群癱瘓，無奈之下只能手動的均衡當前被寫入的region，盡量把當前活躍的region平分到各個regionserver上，這樣才穩定了集群。同時隨著當前活躍region的變換，得定期做移動操作（hbase shell move命令），所以這不是乙個有效的解決辦法，另外還有乙個解決的辦法就是自定義hbase的loadbanlance，通過改變region的分布策略來均衡hbase集群的負載，這個功能在0.92及以後的版本中實現。可參考**技術博的一遍文章《hbase中如何開發loadbalance外掛程式》
2.第二個我想說的是hbase的讀操作，往往我們批量分析hbase資料的時候會用到scan，用提供的api，不得不說，效能不怎麼樣，拿count操作來舉例，往往count乙個表得等到你大眼瞪小眼，但這你怨不得它，單執行緒麼，所以我們在批量讀的時候可以把rowkey分段，通過多執行緒來讀，這有點類似於hive的思路，但比hive簡單，這樣讀起來效能會快很多。至於怎麼分段，就看你的表設計和資料量了，提供乙個簡單的分段方法，就是按region的起始rowkey來分。
3.……
SQL 優化筆記，持續更新
sql var x number sql exec x 90 pl sql procedure successfully completed.sql set autot exp usage set autot race exp lain stat istics sql set autot trace...
hive join優化點 持續更新
select m.from 大表1 m where m.id in select l.id from 小表2 l 效能非常差，使用left semi join代替select m.from 大表1 m left semi join 小表2 l on m.id l.id limit 10 但是 小表2...
Oracle優化相關（持續更新）
create index index name on tablename columnname online direct insert也可以成批插入資料，不過這個插入跟insert插入有區別。前者在插入資料的時候，不會寫重做日誌。而後者常規插入的話，則會寫入重做日誌中 nologging引數使用比...