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

2017/06/20 16:05
阅读数 540

阅读全文

 

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做特定场景的查询优化。

 

阅读全文

展开阅读全文
打赏
0
1 收藏
分享
加载中
更多评论
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部