Hbase案例分析（一）

Hbase应用场景：
1 随机读或者写
2 大数据上的高并发操作，比如每秒对PB级数据进行上千次操作。（查询，删除等操作）
3 读写均是非常简单的操作，比如没有join操作

Hbase Schema设计
rowkey是设计关键

OpenTSDB：
基于Hbase构建
分布式，可伸缩的时间序列数据库。  名词解释：时间序列数据，随着时间是连续分布的，比如每个时刻的气温，一台机器的cpu利用率，内存利用率。
秒级数据采集所有metrics（度量），支持永久存储，可以做容量规划。
可以从大规模的集群（包括集群中的网络设备，操作系统，应用程序）中获取相应的metrics并进行存储，索引及服务。


x轴是时间序列，y轴是mysql的各种counter--------------每隔两秒采集一次。

Lessons Learned from OpenTSDB

1 把行弄的宽一些，行就变少了，扫描就快，但是行业变大了
2 每行数据要有一些独立性。
3 在每一个keyvalue中存尽可能多的数据。=====》 rowkey对应好多咧，存储的时候每一列是单独存储的。要把这个key加到每一列去。事实上每一列都带key，这样就会很昂贵。

1 不要再应用程序服务中，使用HTable 和 HTablePool,因为这两个都是同步的。同步 在高并发情况下，性能是非常低的。推荐使用asynchbase + Netty（高并发的一个开源server，java写的，hadoop2.0也用到了netty） or Finagle = performance ++
2 不要把变长的key放进来，会导致scan非常低效。 key一定要是等长的，或者长度差不多的。
3 每一个regionserver中不要放太多的region，比如上千，上万，上10万。 比如某个regionsrver挂掉，从这里恢复数据成本会非常高。

高并发下，异步库 优于 同步库


OpenTSDB能做什么？
1 高效的存储时间序列数据
2 如何处理一些高并发的写操作
3 在hbase中存储数据的时候我们怎么节省磁盘空间或者内存空间。