TimescaleDB比拼InfluxDB：如何选择合适的时序数据库？

https://www.itcodemonkey.com/article/9339.html

时序数据已用于越来越多的应用中，包括物联 、DevOps、金融、零售、物流、石油天然气、制造业、汽车、太空、SaaS，乃至机器学习和人工智能。虽然当前时序数据库仅局限于采集度量和监控，但是软件开发人员已经逐渐明白，他们的确需要一款时序数据库，真正设计用于运行多种工作负载。

如果我们考虑采用一款时序数据库产品，这可能意味着我们正面对大量时序数据的快速堆积。我们需要一个地方对这些时序数据进行存储和分析。人们此时可能已经认识到，业务的存活严重地依赖于所选取的数据库。

如何选取时序数据库

在评估工作负载所使用的时序数据库时，需考虑多个因素：

• 数据模型；

• 查询语言；

• 可靠性；

• 性能；

• 生态系统；

• 运维管理；

• 企业 / 区的支持情况.

数据库对比测试通常聚焦于性能基准测试。性能只是整体测试的一部分，如果数据库的数据模型或查询语言不匹配，或者因为数据库缺乏可靠性，导致数据库不能用于生产环境中，那么无论基准测试的结果多么好，都毫无意义。考虑到这一点，在深入开展性能基准测试之前，我们着手从数据模型、查询语言和可靠性这三个定量维度对比 TimescaleDB 和 InfluxDB。然后，我们对整个数据库生态系统范围、运维管理以及企业 / 区支持情况做出对比。

当然，我们本身就是 TimescaleDB 的开发人员。读者可能会认为我们的比较会有偏颇。从分析本身看，我们力图保持客观。事实上，我们也 告了 InfluxDB 优于 TimescaleDB 的一些场景。

为什么没有考虑“可扩展性”因素/p>

数据模型

数据库天性顽固。数据的建模和存储方式将会影响对数据库的使用。

关系数据模型

关系数据模型至今已使用了数十年。TimescaleDB 使用关系模型 ，每个时序测量值记录为单独一行数据，其中记录时间的字段后跟随任意数量的其它字段，字段类型可以是 float、int、string、boolean、数组和 JSON BLOB 等，甚至是更复杂的数据类型 。用户可在任一字段上创建索引（标准索引），也可对多个字段创建索引（即复合索引），甚至可以对函数等表达式创建索引，并可限定对部分行创建索引（即部分索引）。任何建了索引的字段都可作为指向另一个表的外键，进而用于存储更多的元数据。

下面给出一个例子：

该方法的优点在于，如果用户的数据天然适合 Tagset 数据模型，那么实现起来非常容易，因为用户不需要操心如何建立模式和索引的问题。另一方面，该方法的缺点在于不支持创建额外的索引、不能对连续型字段（例如，数值）创建索引、元数据更新滞后、强制数据验证等。这些不足之处导致该方法的适应性受限。特别是，该模型虽然看上去是“无模式”的，但事实上它会根据输入数据自动创建底层模式，这种底层模式可能会与所需模式存在差异。

数据模型小结

如果用户的数据完全适合 Tagset 数据模型，并且在未来不会发生更改，那么可以考虑使用 InfluxDB，它易于上手使用。另一方面，关系模型更加多样化，并提供了更多的功能、更加灵活和具有更好的操控性。对于不断改进的应用，关系模型尤其适用。在规划一个系统时，应该考虑当前需求和未来的需求。

查询语言

在数据库查询语言方面，通常存在两个极端：完全支持 SQL 和完全定制语言（也称为“NoSQL”）。

对于插入操作，结果十分清楚：对于数据规模很小的工作负载，InfluxDB 性能超出 TimescaleDB 两倍。但是，随着数据规模的增加，由于 InfluxDB 使用了时间结构归并树（类似于日志结构归并树，在数据规模增加时性能下降），其性能迅速下降。这当然是合理的，因为数据规模问题正是 InfluxDB 的痛点。与之相对比，TimescaleDB 在数据规模增长时性能下降平缓，很快在插入性能上超过了 InfluxDB。

这就是说，用户需要仔细考虑对数据插入的需求。如果插入性能严重低于基准测试情况（例如，达到每秒 2000 行），那么插入性能并非应用的瓶颈所在，这种比较毫无意义。

注意：所用的度量数据是按每秒一行数据测量的（对于 InfluxDB，定义为一组在同一时间记录的度量）。如果用户需要每行采集多种度量，那么每秒的度量总数会更高。例如，在我们的“4000 台设备的 10 种度量”测试中，可以直接使用“每秒行数”10 种度量的方式计算，得到 TimescaleDB 每秒 144 万度量值，InfluxDB 每秒 56 万度量值。

 基本上卷（SIMPLE ROLLUP）操作

对于按时间的基本上卷（即 GROUPBY）聚合度量，在聚合一台主机 12 小时内的一个度量时，或是多台主机的多个度量时，TimescaleDB 通常在小规模或中等规模数据量上要优于 InfluxDB，但是在大规模数据中情况则相反。唯一特例在于聚合单台主机一小时内的多个度量时，无论度量数量如何，TimescaleDB 的性能要优于 InfluxDB。当聚合多台主机的单个度量时，InfluxDB 的性能要优于 TimescaleDB。两者间的差距随度量数增长而降低。

 双重上卷（DOUBLE ROLLUP）操作

对于按时间或其它维度（例如，GROUPBY time 或 deviceID）的双重上卷聚合度量，当聚合一个度量时，InfluxDB 的性能要优于 TimescaleDB。但是当聚合多个度量时，TimescaleDB 要优于 InfluxDB。

 阈值

在基于阈值选取数据行时，TimescaleDB 性能优于 InfluxDB。一个例外情况是单台设备提供多种度量数据。

 复杂查询

对于比上卷和阈值更复杂的一些复杂查询，结果十分明显：TimescaleDB 性能超出 InfluxDB（一些极端情况下会超出数千倍）。性能上的绝对差异十分明显：即便对于一些单度量上卷，InfluxDB 会快数微秒甚至是几十微秒，但是这种性能上的差异是查询者所无法感知的。

同样对于这些更为复杂的查询，TimescaleDB 可提供实时响应（例如，10 到 100 秒甚至是微秒级），而 InfluxDB 可明显感受到延迟（数十秒）。值得注意的是，InfluxDB 并不支持全部的复杂查询，包括多连接、窗函数、地理空间查询等，因此我们也没有对这些查询进行测试。

 读取性能小结

• 对于简单查询，性能有一定的差异。对于部分查询，一款数据库的性能要明显地优于另外一款。而其它查询的性能则取决于数据集中的度量数。但是性能差异的微秒值不超过一位或两位数。

• 对于复杂查询，TimescaleDB 的性能远优于 InfluxDB，并且支持更广泛的查询类型。这一性能差异可达在数秒乃至数十秒。

• 鉴于此，最好的做法是使用用户计划执行的查询做基准测试。

基准测试中的稳定性考虑

需要注意的是，在对 InfluxDB 做基准测试时，即便启用了 TSI，随着数据规模的增大，数据库出现了一些运行问题。特别是当我们采用更大规模的数据集（超过 10 万个 Tag）测试时，InfluxDB 在插入和查询上都出现了问题（TimescaleDB 则未出现问题）。

在数据量不大的情况下，我们实现了批量插入 1 万 Tag 数据到 InfluxDB。但是当数据集增长到 100 万 Tag 时，数据库出现超时和出错问题。我们不得不将批处理规模降至 1 千到 5 千，并使用客户端代码去处理更大数据量对后台所造成的压力。我们必须强制客户端代码在请求写入批处理出错时休眠等待 20 秒。而使用 TimescaleDB，我们可以对大规模数据做大量批处理写入而不会出现问题。

在使用 InfluxDB 时，从 10 万规模开始，在一些读取查询上出现了问题。InfluxDB 的 HTTP 连接会 “End of File”错误。为此我们检查了 InfluxDB 服务器，发现 InfluxDB 在执行查询时消耗了所有可用内存，因而随后 “Out of Memory”错误并崩溃。鉴于 PostgreSQL 支持通过“shared_buffers”和”work_mem”等参数限制内存使用情况，因此内存通常对于 TimescaleDB 而言并非问题，即便是面对大规模数据时。

 稳定性小结

• 对于大规模数据（超过 10 万 Tag），即便启用了 TSI，InfluxDB 依然存在稳定性和性能上的问题。

生态系统

数据库本身的功能有限，人们通常会寻求第三方生态系统去实现额外的功能。生态系统的规模和范围，对一款产品具有很大的影响。

TimescaleDB 采用 SQL 这一策略使得结果大相径庭。只要是使用 SQL 的工具，都可以用于 TimescaleDB。与此不同，InfluxDB 选定使用非 SQL 的策略使其陷入孤立，并限制了开发人员对其的使用。

具有更宽泛的生态系统，也会简化产品的部署。例如，如果用户已经在使用 Tableau 可视化数据，或是使用 Apache Spark 做数据处理，Timescale 完全可以使用兼容的连接器实现插入到现有架构中。

下表是对第一方软件（例如，InfluxData TICK 堆栈组件）和连接任一数据库的第三方工具的不完全列表。该表显示了两款数据库在生态系统上存在的相对差异。

对于表中列出的开源项目，为显示项目的受欢迎程度，我们在表中以括 中数值形式给出了项目的 GitHub 加星数量。例如，“Apache Kafka (9k+)”。我们看到，InfluxDB 的一些非官方项目或者是很早推出的（加星很少），或者是不活跃项目（多个月或数年没有更新）。

注意：两款数据库在插入同样规模的数据上使用了不同的时间。因此上图中绘制的线并未同时终止。

但是，随着数据量的增长（10 万台设备发生 10 种度量），InfluxDB 占用的内存远超过 TimescaleDB（波动也更剧烈）：

 通用工具

在运维 TimescaleDB 时，可以使用 PostgreSQL 生态系统中所有经实战检验的工具。例如，使用 pg_dump 和 pg_restore 做备份和恢复，使用 Patroni 实现高可用和故障转移，使用 Pgpool 实现集群读取的负载均衡。由于 TimescaleDB 的操作类似于 PostgreSQL，用户的学习曲线很低。TimescaleDB 可以按 PostgreSQL 的方式“完全工作”。

在运维 InfluxDB 时，用户局限于使用 Influx 团队构建的工具，包括备份、恢复、内部监控等。

企业 / 区支持

最后，在选用由某家企业主要开发的开源技术时，用户也默认地选取了企业提供服务的能力。

鉴于此，我们比较 Timescale 和 InfluxData 两家企业在企业规模、成熟度、融资等方面存在的差异。它们分别是 TimescaleDB 和 InfluxDB 的支持企业。

今年一月，Timescale 宣布融资 1600 万美元（组合了 A 轮和种子融资）。同时在今年二月，InfluxData 宣布完成 3500 万美元的 C 轮融资，融资总额达 5990 万美元。

这些融资情况是与每家企业各自的历史发展密切相关的。TimescaleDB 正式发布于 2017 年 4 月 4 日（本帖发布的 1 年 4 个月前）。InfluxDB 的最早发布可回溯至 2013 年 9 月 （本贴发布近五年前）。

不同的融资规模和发展历史，也导致了两家企业在技术和产品策略上的巨大差异。

InfluxDdata 需要大量融资，构建大规模团队去实现所有内部需求，并交付可用于生产的数据库产品。与此不同，TimescaleDB 是基于 PostgreSQL 开发的，其工程团队只需在数据库基本构建模块上花费很少精力。因此，尽管 TimescaleDB 的工程团队规模更小，但是它可以更多地聚焦于一些与时序工作负载直接相关的高级特性，并提供用户支持。

TimescaleDB 用更少时间交付比 InfluxDB 更成熟（可能从一些度量上看更为可靠）的生产级别产品。从这一点上，我们可进一步感觉到差异。

此外，有时数据库支持并非来自于企业，而是来自于 区。InfluxData 是从零开始构建 区的，而 Timescale 可以从 PostgreSQL 区继承资源，并用于构建自身的 区。

PostgreSQL 具有非常大的 区。在 StackOverflow 文章中，“PostgreSQL”文章数（截至本贴发表时为 88245）要比“InfluxDB”文章数（1141）多 77 倍。由于 TimescaleDB 的运维非常类似于 PostgreSQL，所以很多 PostgreSQL 问题是与 PostgreSQL 密切相关的 。即便是一位 TimescaleDB（PostgreSQL）的新用户，在上手时也会有大量可参考资源。如果用户已经是 PostgreSQL 专家，当然也会熟悉 TimescaleDB 的使用。

目前对用户来说，Timescale 和 InfluxData 这两家公司均运作良好。

总   结

选择了一种会限制企业未来发展的技术，这是我们在业务中可能犯的最坏错误，更不用说技术在当前就不适用。这就是为什么我们要鼓励读者在发现数据库基础架构崩溃之前，应退后一步并分析所使用的技术栈。

我们知道，TimescaleDB 并非唯一的时序解决方案，在一些情况下它也并非最适用的。在承认一些替代解决方案可能更可取之前，我们会努力改进自己的产品。但我们一直有兴趣对 TimescaleDB 解决方案做整体评估，并将继续与 区分享。

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8689 人正在系统学习中 相关资源：Veneer:文件屏蔽软件-开源-其它代码类资源-CSDN文库