OpenTSDB在HBase上的优化
OpenTSDB时间序列数据库架构如图所示，它的存储基于HBase，HBase具有高性能，可以线性扩展。TSD被设计为无状态节点，任何一个节点可以随时替换另一个节点进行服务，对外提供的RPC协议是HTTP/Json接口，很方便使用。TSD依赖HBase解决一致性，当TSD产生写时，它一定会将写及时更新到HBase， 而产生读不命中时候，也会从HBase中将数据读回来。
OpenTSDB 存储格式如图所示，它的存储上做了很多针对时序的考虑和优化。
- 最核心的点是将Tags压缩，将tags分成两个级别，第一个级别有一个表将tags转换成 id，所有的tags id和指标的名称以及时间一起被组合成row key，row key实际上是OpenTSDB保存的行键，每一行中重复存储只有row key，row key 实际上是每一个tags都被转换成了整型，row key 相对来说比较短。
- 每个row key对应时间序列+一个时间戳，时间序列上的数据一直存在时间序列之上，理论上row key 不需要重复保存，所以一个小时的数据保存在同一行里，OpenTSDB的存储格式中每一行有3600个列，每个列对应一个小时内的点，而这一小时的时间边界、指标名称、id一起构成了row key。row key重复存储的空间就变成了按行设计的1/3600，大大地压缩了row key。
- Row key的构建也经过了很好的设计，时间位于metric和tags之间，不需要预先定义数据格式，保证了灵活性;tags扫描时候，我们经常遇到的场景是聚合，需要找到某个tags的一系列时间线，OpenTSDB场景中，在tags和搜索条件正好满足前缀规则时可以很好的优化，如果共有三个标签园区、楼、楼层构建row key，如果搜索园区，扫过的数据就是我们要的数据，别的园区数据就会排出掉，HBase常见的问题是产生热点，OpenTSDB用salt机制保证热点。
OpenTSDB的缺点
OpenTSDB也有很多缺点，具体如下：
- 时间序列的Meta Data以缓存的方式在所有的TSD节点中存在，时间序列太多的时候内存压力很大
- 以RowScan的方式做多维度查询，当查询条件不满足RowKey的前缀时，会扫过很多无用的RowKey
- 在固定的Column中保存一小时内的时间点，Qualifier存在额外的开销
- 单点聚合，容易出现聚合性能瓶颈(cpu&memory)
- 通用压缩算法，压缩率依然不理想(每个数据点大约消耗20字节，包括了RowKey的开销)
- HiTSDB的优化和提高
倒排索引
参考搜索引擎的倒排索引实现，每个时间序列作为一个文档，通过tags的倒排索引到时间序列ID，把timestamp + 时间序列ID作为RowKey，取代由timestamp + metric ID + tag IDs拼接成的RowKey。
