时间序列数据的存储和计算 - 开源时序数据库解析（二）

阅读全文

 

KairosDB

  KairosDB最初是从OpenTSDB 1.x版本fork出来的一个分支，目的是在OpenTSDB的代码基础上进行二次开发来满足新的功能需求。其改造之一就是支持可插拔式的存储引擎，例如支持H2可以方便本地开发和测试，而不是像OpenTSDB一样与HBase强耦合。在其最初的几个版本中，HBase也是作为其主要的存储引擎。但是在之后的存储优化中，慢慢使用Cassandra替换了HBase，它也是第一个基于Cassandra开发的时序数据库。在最新的几个版本中，已不再支持HBase，因为其存储优化使用了Cassandra所特有而HBase没有的一些特性。

  在整体架构上，和OpenTSDB比较类似，都是采用了一个比较成熟的数据库来作为底层存储引擎。自己的主要逻辑仅仅是在存储引擎层之上很薄的一个逻辑层，这层逻辑层的部署架构是一个无状态的组件，可以很容易的水平扩展。

  在功能差异性上，它在OpenTSDB 1.x上做二次开发，也是为了对OpenTSDB的一些功能做优化，或做出一些OpenTSDB所没有的功能。我大概罗列下我看到的主要的功能差异：
1. 可插拔式的存储引擎：OpenTSDB在早期与HBase强耦合，为了追求极致的性能，甚至自研了一个异步的HBase Client（现在作为独立的一个开源项目输出：AsyncHBase）。这样也导致其整个代码都是采用异步驱动的模式编写，不光增加了代码的复杂度和降低可阅读性，也加大了支持多种存储引擎的难度。KairosDB严格定义了存储层的API Interface，整体逻辑与存储层耦合度较低，能比较容易的扩展多种存储引擎。当然现在最新版的OpenTSDB也能够额外支持Cassandra和BigTable，但是从整体的架构上，还不能说是一个支持可插拔式存储引擎的架构。
2. 支持多种数据类型及自定义类型的值：OpenTSDB只支持numeric的值，而KairosDB支持numeric、string类型的值，也支持自定义数值类型。在某些场景下，metric value不是一个简单的数值，例如你要统计这个时间点的TopN，对应的metric value可能是一组string值。可扩展的类型，让未来的需求扩展会变得容易。从第一第二点差异可以看出，KairosDB基于OpenTSDB的第一大改造就是将OpenTSDB的功能模型和代码架构变得更加灵活。
3. 支持Auto-rollup：目前大部分TSDB都在朝着支持pre-aggregation和auto-rollup的方向发展，OpenTSDB是少数的不支持该feature的TSDB，在最新发布的OpenTSDB版本中，甚至都不支持多精度数据的存储。不过现在KairosDB支持的auto-rollup功能，采取的还是一个比较原始的实现方式，在下面的章节会详细讲解。
4. 不同的存储模型：存储是TSDB核心中的核心，OpenTSDB在存储模型上使用了UID的压缩优化，来优化查询和存储。KairosDB采取了一个不同的思路，利用了Cassandra宽表的特性，这也是它从HBase转向Cassandra的一个最重要的原因，在下面的章节会详细讲解。

存储模型

  OpenTSDB的存储模型细节，可以参考这篇文章。其主要设计特点是采用了UID编码，大大节省了存储空间，并且利用UID编码的固定字节数的特性，利用HBase的Filter做了很多查询的优化。但是采用UID编码后也带来了很多的缺陷，一是需要维护metric/tagKey/tagValue到UID的映射表，所有data point的写入和读取都需要经过映射表的转换，映射表通常会缓存在TSD或者client，增加了额外的内存消耗；二是由于采用了UID编码，导致metric/tagKey/tagValue的基数是有上限的，取决于UID使用的字节数，并且在UID的分配上会有冲突，会影响写入。

  本质上，OpenTSDB存储模型采用的UID编码优化，主要解决的就两个问题：
1. 存储空间优化：UID编码解决重复的row key存储造成的冗余的存储空间问题。
2. 查询优化：利用UID编码后TagKey和TagValue固定字节长度的特性，利用HBase的FuzzyRowFilter做特定场景的查询优化。

 

阅读全文

转载于:https://my.oschina.net/u/3471671/blog/993779