- HBase
1.1 存储
-
Phoenix
Schema qualifier管理方便、偶尔的SQL查数方便
用不到二级索引实际不必要，会有一定的性能损耗 -
列族划分
粗粒度划分对于schema管理及上层取数十分方便
列划分过大容易频繁触发flush，且对于部分不需要全列数据影响查询性能 -
预分区
极大缓解在业务读写中Split和数据倾斜带来的开销
有些业务场景的rowkey需要hash做适配预分区，要求不高的比如md5等 -
压缩与编码
压缩可能采用Snappy，冷备集群可以考虑Gzip
编码慎用所谓推荐的prefixTree，1.x版本有bug。ref: HBASE-12959 -
多版本存储
利用timestamp可以做版本冗余、一致性问题缓解等事情
注意磁盘压力，尤其是还有定期做snapshot的，archive有可能回收会比较慢
1.2 写入
-
注意List
批次大小
适当聚合请求会加速同样数量的请求速度，减少请求IO次数
批次太大会造成slow multi request，这类慢请求过多会影响吞吐率，后来的请求只能在客户端轮询wait -
写请求较多的场景注意控制compaction
如有必要可以手动关闭major compact，在闲时手动触发
删改请求较多的，可以适当缩小major compact的间隔，以免读性能影响
1.3 读取
-
注意List
批次大小
适当聚合请求会加速同样数量的请求速度，减少请求IO次数
批次太大会造成slow multi request，这类慢请求过多会影响吞吐率，后来的请求只能在客户端轮询wait
Get所请求的字节数过大(超过数组上限)的话会无法返回，1.2.0之前的版本甚至会导致RegionServer OOM 宕机。 -
注意Version、ttl的特殊性，区分数据的逻辑删除与物理删除
用户视角的HBase自身一致性问题80%都是搞不清楚逻辑删除。
逻辑删除：HBase会读到这个数据，但是在RS层根据策略不返回给用户
物理删除：真的从HDFS删除此数据，发生于compact阶段 -
Scan的Filter
善用Filter做下推减少返回的数据数量
Filter也不要嵌套太复杂，使得RegionServer处理负载较重
注意设置到Filter的qualifier首先要能取出来，因此scan如果显示设置了addColumn/addFamily，需要记得包括filter的qualifier
注意指定qualifier是否为null，有可能导致想拿的数据没拿到；结合 filter.setFilterIfMissing 使用。 -
Scan优化
适当设置caching，一般为100
blockCache设为false
只取自己关注的列
考虑设置 hbase.mapreduce.input.autobalance = true 以解决预期Region取数不太均衡或数据倾斜的scan问题 -
BlockCache缓存配置
强烈建议用BucketCache的offheap模式，配置计算方式参考：http://hbasefly.com/2016/04/08/hbase-blockcache-1/
1.4 GC优化
-
JDK 1.7+ && CMS优化 (netease) :
-Xmx20g -Xms20g -Xmn512m -Xss256k
-XX:MaxPermSize=256m -XX:SurvivorRatio=2
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+CMSParallelRemarkEnabled -XX:MaxTenuringThreshold=15
-XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=75 -XX:-DisableExplicitGC -
JDK 1.8+ && G1GC (XIaomi):
-Xmx20g -Xms20g -XX:MaxDirectMemorySize=20g
-XX:+UseG1GC
-XX:+UnlockExperimentalVMOptions
-XX:MaxGCPauseMillis=90
-XX:G1NewSizePercent=2
-XX:InitiatingHeapOccupancyPercent=65
-XX:+ParallelRefProcEnabled
-XX:ConcGCThreads=4 -XX:ParallelGCThreads=16 -XX:MaxTenuringThreshold=1
-XX:G1HeapRegionSize=32m -XX:G1MixedGCCountTarget=64 -XX:G1OldCSetRegionThresholdPercent=5
-verbose:gc -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime
-XX:+PrintHeapAtGC -XX:+PrintGCDateStamps -XX:+PrintAdaptiveSizePolicy
-XX:+PrintTenuringDistribution -XX:+PrintSafepointS
GC情况最后依然还需根据实际自己的情况进行调整。
1.5 监控
方案：ELK、Grafana + 时序数据库(Opentsdb)/监控系统(OpenFalcon)等
指标：JVM (GC、Heap、OffHeap等)、Compact、Split、缓存命中数、各类请求count、slow request count、集群基础监控。（注：以上监控除了JVM和集群基础，有条件的表级别和RegionServer级别都做一份）
另：记得对RegionServer做自动拉起的守护进程。
1.6 Linux
- 关闭大页 Tuning transparent huge pages (THP) off
- 禁止swap Set vm.swappiness = 0
- 关闭NUMA vm.zone_reclaim_mode = 0
以上操作系统配置基本适用于持续服务的高读性能数据存储集群，包括但不仅限于HBase、ES等。
1.7 备份与容灾
数据层面目前官方版本只支持异步式的冷备。
- Snapshot/Export 机制
每次都是全量备份
自行维护WAL回放（或业务重放） - HBase 2.0 增量备份
利用WAL做增量备份
不支持对备份做compact，增量太多时恢复速度需要关注 - 主从一致性（备份本身也可能因为网络等原因失败）
1.8 部署
- Master HA
- Region预留足够offheap内存给BucketCache读缓存，2.x会更多的利用offheap以缓解GC