HBASE+PHOENIX效能優化註解
hbase環境配置優化：
幾個配置引數：
hbase.hregion.max.filesize:
1)當hbase.hregion.max.filesize比較小時，觸發split的機率更大，而split的時候會將regionoffline，因此在split結束的時間前，訪問該region的請求將被block住，客戶端自我block的時間預設為1s。當大量的region同時發生split時，系統的整體訪問服務將大受影響。因此容易出現吞吐量及響應時間的不穩定現象
2)當hbase.hregion.max.filesize比較大時，單個region中觸發split的機率較小，大量region同時觸發split
hbase.hregion.memstore.flush.size
hbase.hregion.memstore.flush.size意思一個region下面的所有store裡面的memstore
hfile.block.cache.size
是整個堆記憶體的多少比例作為regionserver的cache，調大該值會提升查詢效能，當然也不能過大，如果你的hbase都大量的查詢，寫入不是很多的話，調到0.5
hbase.regionserver.global.memstore.upperLimit
配置一臺regionserver所有memstore
程式有關注意配置：
autoflush=false
提高hbase的寫入速度應用程式碼中設定autoflush=false；但是機器崩潰可能丟資料；
table中family和qualifier
從讀的方面考慮： family越多，那麼獲取每一個cell資料的優勢越明顯
從寫的角度考慮：
首先，記憶體方面來說，對於一個Region，會為每一個表的每一個Family分配一個Store，而每一個Store，都會分配一個MemStore，所以更多的family會消耗更多的記憶體。
第三，從split方面考慮，由於hfile是以family為單位的，因此對於多個family來說，資料被分散到了更多的hfile中，減小了split發生的機率。這是把雙刃劍。更少的split會導致該region的體積比較大，由於balance是以region的數目而不是大小為單位來進行的，因此可能會導致balance失效。而從好的方面來說，更少的split會讓系統提供更加穩定的線上服務。
Phoenix
二級索引：hbase-site.xml需要增加才行:
<property>
<name>hbase.regionserver.wal.codec</name>
<value>org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec</value>
</property>
還要注意本地索引和全域性索引的應用；以及索引的有效性規則；
SALT_BUCKETS是全域性索引分桶，主要是解決region熱點問題，由於rowkey設計不當，很可能絕大部分的row都會落入一個region中，那麼其對應index通過設定SALT_BUCKETS［1~255］來將這些index分桶儲存。如果主表添加了properties，那麼它的index會繼承這些properties。不過，index的MAX_FILESIZE相對主表的值被降低了。
例子
CREATETABLEexample1 (k VARCHAR PRIMARY KEY, m.c0 VARCHAR, m.c1 VARCHAR,m.c2 VARCHAR)
create index idx on example(m.c0, m.c1,m.c2)
注意為多個column建立索引，在查詢時要按照索引列的順序來查詢。例如，為M.C0、M.C1和M.C2建立索引：該例子會隱式的建立(m.c0),(m.c0,
m.c1),(m.c0, m.c1,m.c2)三個索引，如果在where中用這三個條件會用到索引，其他組合則無法使用索引（FULLSCAN）。
在查詢時，可以同時根據將這3列作為條件，且順序不限。但是，第一列必須是M.C0。這是因為：當為多列建立索引時，rowkey實際上是這些column的組合，並且是按照它們的先後順序的組合。如果查詢時第一列不是M.C0，那麼就要進行fullscan，速度會很慢。而如果查詢的第一列是M.C0，就可以直接將滿足關於M.C0的資料記錄找出來。即使後面還有沒有被索引的列，也可以很快得到結果，因為滿足關於M.C0的結果集已經不大了（如果是這種情況的話），對其再進行一次查詢不會是fullscan。
查詢條件中主鍵索引+二級索引同時存在的話，Phoenix會自己選擇最優索引。
例子建立表：
CREATETABLE TEST(pk1 char(1) not null, pk2 char(1) not null, pk3 char(1)not null, nonpkvarchar CONSTRAINT PK PRIMARY KEY(pk1, pk2,pk3));
不會使用到索引的檢索：
select* from testwhere pk2='x' andpk3='y'
會使用到索引的檢索：
select* from testwhere pk1='x' and pk2='y'
select* from testwhere pk3='x' and pk1='y'
select* from testwhere pk1='x' and pk3='y'
在hbase-site.xml裡還可以配置以下引數
1. index.builder.threads.max
o 為主表更新操作建立索引的最大執行緒數
o Default:10
2. index.builder.threads.keepalivetime
o 上面執行緒的超時時間
o Default:60
3. index.writer.threads.max
o 將索引寫到索引表的最大執行緒數
o Default:10
4. index.writer.threads.keepalivetime
o 上面執行緒的超時時間
o Default:60
5. hbase.htable.threads.max
o 同時最多有這麼多執行緒往索引表寫入資料
o Default:2,147,483,647
6. hbase.htable.threads.keepalivetime
o 上面執行緒的超時時間
o Default:60
7. index.tablefactory.cache.size
o 快取10個往索引表寫資料的執行緒
o Default:10