在这篇文章中，我们分析了受欢迎的开源时序数据库引擎的时序数据保存和计算能力。

周肇峰是作者。

KairosDB是InfluxDB的一种开源数据库。

KairosDB最初是OpenTSDB 1.x版本的一个分支，旨在基于OpenTSDB代码实施二次开发，以满足新的功能需求。其中一个改进点是支持可插拔的存储引擎。例如，与OpenTSDB不同，H2的支持使得在本地进行开发和测试更加容易。在早期版本中，HBase是主要的存储引擎之一。然而，随着存储的优化，HBase逐渐被Cassandra所取代，并成为基于Cassandra开发的第一个时序数据库。在最新版本中，由于Cassandra具有HBase不可用的特定属性，这些属性被应用于存储优化，因此不再支持HBase。

整体架构与OpenTSDB相似，都将成熟的数据库作为底层存储引擎使用。主要逻辑仅存在于存储引擎层之上的薄逻辑层。这个逻辑层的部署架构是一种可水平扩展的无状态组件。

在功能上的差异中，我们在OpenTSDB 1.x上进行二次开发，对OpenTSDB的功能进行了优化，并开发了OpenTSDB不具备的功能。在这里，我们将重点介绍主要的功能差异。

1、可插拔的存储引擎：OpenTSDB的初始版本与HBase紧密结合。为了追求最佳性能，还开发了异步的HBase客户端（现已作为独立的开源项目输出：AsyncHBase）。结果，整个代码都是以异步驱动模式编写的，导致代码复杂度增加，可读性降低，同时增加了支持多个存储引擎的难度。KairosDB严格定义了存储层的API接口。由于整体逻辑与存储层的耦合较少，因此多个存储引擎的扩展变得容易。最新版的OpenTSDB已支持Cassandra和BigTable，但作为整体架构来说，并不能称之为支持可插拔的存储引擎的架构。

2、对各种数据类型和自定义类型的支持：OpenTSDB仅支持数字类型，而KairosDB支持数字类型、字符串类型和自定义数字类型的值。在某些情况下，指标值并不是简单的值。例如，如果想要计算当前时间点的TopN，则相应的指标值可能是字符串值的集合。可扩展的类型会更容易满足未来的新需求。KairosDB基于OpenTSDB进行了第一次重大改进，表明了它更灵活的功能模型和代码架构。
3、自动聚合支持：目前，大多数TSDB都朝着支持预先聚合和自动聚合的方向发展。OpenTSDB是为数不多不支持此功能的TSDB之一。在最新版本的OpenTSDB中，甚至不支持多精度数据的存储。然而，KairosDB支持的自动聚合功能的实现方法仍相对原始，将在下一节中详细说明。

4、在存储模型方面存在差异：对于TSDB，存储是“核心中的核心”。OpenTSDB的存储模型采用UID压缩优化以优化查询和存储。而KairosDB则采用了基于Cassandra宽表的另一种思路。这也是HBase被Cassandra取代的最主要原因。我们将在下一节详细解释这一点。

存储模型

设计上的主要特点是使用UID编码。通过使用UID编码，可以大幅节省存储空间，并且基于UID编码的固定字节属性使用HBase过滤器，优化了许多查询。然而，UID编码也有许多缺陷。首先，需要维护度量标准/标签键/标签值和UID的映射表。所有数据点的写入和读取都需要通过映射表进行转换。映射表通常会被保存在TSD或客户端的缓存中，增加了额外的内存消耗。其次，由于UID编码，度量标准/标签键/标签值的数量存在限制，取决于UID使用的字节数，可能会导致UID分配冲突，影响写入操作。

从本质上讲，OpenTSDB存储模型所采用的UID编码优化主要解决了两个问题。

1、优化存储空间。通过UID编码解决存储空间冗余问题，该问题是由行键重复保存导致的。
2、基于使用UID编码的标签键和标签值具有固定字节长度属性的查询优化，使用HBase FuzzyRowFilter在特定场景下进行查询优化。
为解决这两个问题，KairosDB采用了不需要UID编码的另一种方法，并且成功避免了这些问题。首先，让我们来看一下KairosDB的存储模型。它主要由以下三个表组成。

1、数据点：存储所有原始数据点。每个数据点包含度量、标签、时间戳和值。数据行的时间范围为3周。这意味着在3周内的所有数据点都存储在同一行中，而OpenTSDB的行时间范围只有1小时。行键的结构与OpenTSDB相同，结构为<度量><时间戳><标签键1><标签值1><标签键2><标签值2>…<标签键n><标签值n>。区别在于，所有的度量、标签键和标签值都存储原始值,而不是UID的替代值。

2、行键索引：此表存储每个度量在DataPoints表中所有行键的映射。即，同一度量写入的所有行键存储在同一行中，并按照时间顺序排序。该表主要用于查询。如果需要按照标签键或标签值进行过滤，则首先从该表中过滤查询期间内的所有目标行键，然后再查询DataPoints表中的数据。

3、字符串索引：此表包含3行数据，每行分别存储所有的度量、标签键和标签值。

KairosDB的存储模型利用了Cassandra的宽表功能。在HBase的底层文件存储格式中，每一列都与键值对应，其中键即为该行的行键。因此，HBase行的每一列都会重复存储相同的行键。这就是UID编码能够大大节省存储容量的主要原因，而为了进一步压缩UID编码后的存储容量，可以采用合并策略（将行内的所有列合并为一个列）。Cassandra的底层文件存储格式与HBase不同。Cassandra行的每一列并不会重复存储行键，因此不需要UID编码。减少行数是降低Cassandra存储容量的一种优化策略，即不是每行存储1小时的数据，而是保存3周的数据。关于这两种解决方案的原因，请参考”Hbase文件格式”和”Cassandra文件格式”。

当使用Cassandra的宽表时，即使不使用UID编码，其存储容量也不比使用UID编码的OpenTSDB差太多。官方解释如下：

首先，一个选项是不要在字符串中使用ID。字符串数据（度量名称和标签）将被写入行键和适当的索引。由于Cassandra的行非常宽，所以写入到数据库的键的数量要少得多。使用ID也无法节省太多空间。此外，不使用ID还可以避免在整个集群中使用某种锁定。

正如前面所提到的，Cassandra具有更大的行大小。OpenTSDB HBase的默认行大小为1小时，而Cassandra设定为3周。

在KairosDB中，查询的整体流程与OpenTSDB采用的优化方法不同。

1、根据查询条件，搜索所有DataPoints表的行键。
1、如果有自定义插件，可以从插件中获取所有行键。(通过使用插件，可以创建行键索引并使用外部索引创建系统进行扩展，例如使用ElasticSearch等)
2、如果没有自定义插件，可以根据指标和时间范围在RowKeyIndex表中搜索所有行键。(可以根据列名范围(metric+startTime, metric+endTime)来缩小查询范围)

2、根据行键在DataPoints表中搜索所有数据。

KairosDB利用索引表直接掃描數據表格，以篩選行鍵。相較於OpenTSDB，KairosDB能夠利用索引表絕對減少掃描數據的量。當該指標下有限定的標籤鍵與標籤值組合時，查詢效率會大幅提升。此外，KairosDB提供了QueryPlugin方法，可以擴展外部組件來將行鍵建立索引。例如，可以使用ElasticSearch或其他索引系統，因為建立索引最終是最佳查詢解決方案。這也是Heroic對KairosDB最大的改進之一。

自动卷起

在KairosDB的官方文档中，有一个关于自动卷起设置的章节。然而，在讨论组中，关于自动卷起的描述如下。

首先，Kairos不会在摘要中进行聚合。摘要会直接发送到存储以提高性能。

Kairos的聚合是在执行查询后进行的。卷取是指执行查询并将结果保存为新的指标。目前，所有的卷取都是在每个Kairos节点上进行设置的。未来计划对此进行更改。

目前，Kairos不会与其他Kairos节点共享状态。节点上除了卷取之外几乎没有其他状态。

至于一致性，需要多少数据以及需要多重要的数据完全由您决定。

总结一下，KairosDB提供的自动汇总解决方案相对较容易实现。这是一个可配置的独立组件，可以在预定的时间启动，读取写入的数据，并在聚合后重新写入数据。尽管相当原始，可用性和性能确实较低。

但是，有比什么都没有要好。自动滚动更新已成为所有时序数据库的趋势，它是扩大功能差异并提升核心竞争力的重要功能之一。

蓝洪水

由于上次的分析主要集中在基于Cassandra构建的第一个TSDB，即KairosDB，所以下面我想继续分析其他基于Cassandra构建的TSDB。

BlueFlood是基于Cassandra构建的TSDB。从观看此PPT的角度来看，可以看出整体架构主要包含以下三个核心组件。

• インジェストモジュール:データの書き込み処理を行う。

 

• ロールアップモジュール:自動事前集計や精度の低下を行う。

 

• クエリモジュール:データの問い合わせ処理を行う。

 

• KairosDBと比較すると、そのデータモデルは主に以下の点で他のTSDBとは若干異なります。

 

• テナント次元が導入されている:サービス指向のTSDBを構築する場合、テナントディメンションは必須です。

 

タグがサポートされていない：これはかなり意外です。ほとんどのTSDBは基本的にタグをモデルに欠かせないものとして使用していますが、BlueFloodはモデル上でタグをサポートしていません。これは、タグクエリの最適化がどのように決定されていないため、トレードオフになっているのかもしれません。この場合、BlueFloodは単にタグをサポートしていないだけです。いずれにしても、将来的にタグをスケーリングするための完全な互換性があります。BlueFloodは現在、メトリックインデックスを構築するためにElasticSearchを使用しています。将来的にはタグインデックスを構築するソリューションもElasticSearchをベースにすべきだと思います。この計画が完全にサポートされるまでタグは導入されません。

由于BlueFlood模型的缺陷，不需要考虑标签查询的优化。相反地，所有的努力都被投入到了其他功能的优化，比如自动聚合。在自动聚合支持方面，它远优于KairosDB和OpenTSDB。以下是自动聚合功能的一些示例：

• 固定インターバルのみサポート:5分、20分、60分、4時間、1日。

 

分散ロールアップサービス:ロールアップタスクを分散してスケジューリングし、オフラインのバッチスキャンでロールアップデータを取得することができます。

從2014年的PPT介紹中，我們可以看到一些關於未來計劃的功能要點。

• ElasticSearchのインデクサとディスカバリー:現在はこの機能が実装されていますが、対応しているのはメトリックインデックスのみです。今後タグが導入された後は、タグインデックスにも利用される可能性があります。

 

• ロールアップのためのクラウドファイルエクスポート:この方法は、オフライン計算のためにより最適化されています。ロールアップから大量の履歴データを読んでも、オンラインサービスには影響しません。

 

ロールアップ用の Apache Kafka エクスポート:この方法はオフライン計算よりも高度です。ロールアップはStreamComputeで行うことができ、リアルタイム性が高くなります。

总结起来，如果不需要标签支持，并且对汇总存储有较高需求的话，选择BlueFlood会更好。相反，应选择KairosDB。

英勇的

我认为Cassandra为基础的TSDB中排名第三的是Heroic，在DB-Engines中排名第19。虽然它在BlueFlood和KairosDB之后，但我认为它的设计和实现是最优秀的。关于其背后的故事和经验教训，请参考此篇文章和此份PPT，它们都是非常宝贵的资源。

在决定开发Heroic之前，Spotify选择了KairosDB来取代传统监控系统的底层，例如OpenTSDB，InfluxDB和KairosDB等TSDB。然而，很快就发现了KairosDB查询的问题。最大的问题是KairosDB没有关于度量和标签的索引，因此当度量和标签的重要性达到一定水平时，查询变得非常缓慢。因此，Spotify开发Heroic的最大动机是解决KairosDB的查询问题。他们采用了ElasticSearch作为优化查询引擎的索引解决方案，数据写入和数据表解决方案与KairosDB完全匹配。

将其特点简要总结如下。

1、完全符合Metric2.0规范的完整数据模型。
2、数据存储模型与KairosDB一致，并采用ElasticSearch进行查询引擎的优化（这是KairosDB、OpenTSDB、BlueFlood等除了InfluxDB之外其他TSDB的一个主要问题，也是核心竞争力之一）。
3、缺点之一是不支持自动卷积功能。

如果您需要支持完整的数据模型，并且想要获得高效的索引查询，那么我推荐使用Heroic。

本博客是从英文版翻译而来的。您可以在这里查看原文。我们部分使用了机器翻译技术。如果有翻译错误的地方，请指正，将不胜感激。

阿里巴巴云拥有自己在日本的两个数据中心，并且是亚太地区No.1的云基础设施服务提供商（2019年Gartner数据）。欲了解更多有关阿里巴巴云的详细信息，请查阅阿里巴巴云日本官方网页。