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

时间 2019-11-13

标签 timescaledb 比拼 influxdb 如何选择合适时序数据库栏目 SQL 繁體版

原文原文链接

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

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

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

如何选取时序数据库算法

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

数据模型；数据库
查询语言；后端
可靠性；设计模式
性能；数组
生态系统；安全
运维管理；
企业 / 社区的支持状况.

本文中，咱们将对比两款业界领先的时序数据库，TimescaleDB（https://www.timescale.com/?utm_source=timescale-blog&utm_medium=referral&utm_campaign=influx-benchmark-post&utm_content=firstlink）和 InfluxDB（https://www.influxdata.com/），意在为软件开发人员正确选取所需的时序数据库提供参考。

数据库对比测试一般聚焦于性能基准测试。性能只是总体测试的一部分，若是数据库的数据模型或查询语言不匹配，或者由于数据库缺少可靠性，致使数据库不能用于生产环境中，那么不管基准测试的结果多么好，都毫无心义。考虑到这一点，在深刻开展性能基准测试以前，咱们着手从数据模型、查询语言和可靠性这三个定量维度对比 TimescaleDB 和 InfluxDB。而后，咱们对整个数据库生态系统范围、运维管理以及企业 / 社区支持状况作出对比。

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

此外，此次比较并不是彻底理论上的。咱们的企业最初是一家物联网平台。在该平台上，咱们最初选用 InfluxDB 存储传感器数据。可是考虑到本文下面将列出的一些差别之处，咱们发现 InfuxDB 并不能知足咱们的需求。基于此，咱们构建了首个知足需求的时序数据库 TimescaleDB，并发现了对该数据库具备需求的其它一些客户，所以咱们决定将数据库开源。当前在不到一年半的时间中，TimescaleDB 已经被下载数十万次，并在全球范围内的生产环境中使用（更多信息，参见咱们介绍 TimescaleDB 的起源一文 https://blog.timescale.com/when-boring-is-awesome-building-a-scalable-time-series-database-on-postgresql-2900ea453ee2）。

最后，本文意在帮助读者面对须要使用时序数据库的状况时作出最后的判断。

为何没有考虑“可扩展性”因素？

若是读者仔细查看上面列出的考虑因素清单，就会发现其中缺乏“可扩展性”和“集群”因素。咱们发现，开发人员在请求任何二者之一时，其实他们真正须要的是性能度量、高可用性和存储能力的某种组合。咱们认为，单独给出上述三方面因素将更具意义，而不是以某个一应俱全的数据一言蔽之。所以在本文中咱们也正是这么作的。

数据模型

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

在数据模型方面，TimescaleDB 和 InfluxDB 存在两种彻底不一样的观点。TimescaleDB 是一种关系型数据，而 InfluxDB 更多的则是一种定制的、NoSQL 的非关系型数据库。这意味着 TimescaleDB 是基于关系数据库模型的，而关系模型在 PostgreSQL、MySQL、SQL Server、Oracle 等数据库中获得了广泛的应用。另外一方面，InfluxDB 提出了本身的数据模型。在本文的对比中，咱们将该数据模型称为“Tagset 数据模型”。

关系数据模型

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

下面给出一个例子：

该方法的优势在于很是灵活。用户能够选择：

根据每次读取中的数据量和元数据规模，考虑使用宽表仍是窄表。
使用多个索引加速查询，仍是减小索引的数量以下降磁盘的使用。
在测量数据行中使用非规范化元数据，或是使用独立的表存储规范化的元数据。两种方式均支持在任意时间作更新，虽而后一种方式更易于实现更新。
使用对输入格式作验证的严格模式，仍是使用无模式的 JSON BLOB 以加快迭代速度。
检查那些验证输入的约束。例如，检查惟一性、非空值的约束。

该方法的缺点在于，用户一般须要一开始就肯定模式，并明确地给出是否须要实现索引。

注意：在过去数十年间，关系模型由于其不可扩展性而饱受批评。可是正如咱们曾指出的，此批评并不正确。事实上，关系型数据库对时序数据的扩展性很好。

Tagset 数据模型

使用 InfluxDB 的 Tagset 数据模型，每一个测量数据中具备一个时间戳，以及一组相关的标签（称为“Tagset”）和一组字段（称为“Fieldset”）。Fieldset 表示了实际的测量读取值，而 Tagset 表示了描述测量数据的元数据。字段数据类型局限于 float、int、String 和 Boolean，在不重写数据的状况下是不能更改的。Tagset 值是作了索引的，而 Fieldset 值并未作索引。Tageset 值老是以字符串表示，不能更新。

下面给出一个例子：

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

数据模型小结

若是用户的数据彻底适合 Tagset 数据模型，而且在将来不会发生更改，那么能够考虑使用 InfluxDB，它易于上手使用。另外一方面，关系模型更加多样化，并提供了更多的功能、更加灵活和具备更好的操控性。对于不断改进的应用，关系模型尤为适用。在规划一个系统时，应该考虑当前需求和将来的需求。

查询语言

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

更多细节，可参阅咱们近期发布的 SQL 和 Flux 的对比文章（https://blog.timescale.com/sql-vs-flux-influxdb-query-language-time-series-database-290977a01a8a）。

TimescaleDB 自一开始就坚决地支持 SQL 查询，以后进一步扩展 SQL 实现简化的时序分析功能。这使得 TimescaleDB 对用户学习曲线平滑，并可传承整个 SQL 生态系统的第三方工具、链接器和可视化工具。由此，TimescaleDB 相比其它任什么时候序数据库都提供了更为丰富的功能。

InfluxDB 则不一样，它采起了介于 SQL 和 NoSQL 之间的作法，使用了一种称为“InfluxQL”的类 SQL 查询语言。近期，它进一步作了定制，提供了新的 Flux 查询语言。所以，InfluxDB 建立了一种新的查询语言。据其建立者宣称，Flux 解决了他们碰到的 SQL 中存在的一些问题（具体细节，参阅 Flux 发行说明（https://www.influxdata.com/blog/why-were-building-flux-a-new-data-scripting-and-query-language/）、Hacker News 讨论帖（https://news.ycombinator.com/item?id=17567554），以及咱们的 SQL 和 Flux 的对比文章）。

下面咱们从高层语言上对比两种语言的语法。以计算指数移动平均为例：

TimescaleDB（SQL）

SELECT time,
exponential_moving_average(value, 0.5) OVER (ORDER BY time)
FROM metrics
WHERE measurement = 'foo' and time > now() - '1 hour';

InfluxDB（Flux）

from(db:"metrics")
|> range(start:-1h)
|> filter(fn: (r) => r._measurement == "foo")
|> exponentialMovingAverage(size:-10s)

更多细节，可参阅咱们近期发布的 SQL 和 Flux 的对比文章（https://blog.timescale.com/sql-vs-flux-influxdb-query-language-time-series-database-290977a01a8a）。

总而言之，咱们认为在不少状况下，SQL 都是时序数据库的正确查询语言（https://blog.timescale.com/why-sql-beating-nosql-what-this-means-for-future-of-data-time-series-database-348b777b847a）。

虽然 Flux 简化了一些任务，但使用一种定制查询语言时存在着一些明显的权衡考虑。事实上，一种新的查询语言不可避免地会引入大量开销，并下降可读性。这会迫使新用户的学习曲线变陡峭，并缺乏适用的工具。

在不少状况下，定制查询语言并不适用。对于企业而言，使用一种新的查询语言须要从新构建系统，并从头培训企业去编写和阅读。这在实际中并不可行，尤为是企业已经在数据库上使用着一些兼容 SQL 的工具，例如使用 Tableau 作可视化。

这正是数据架构中查询语言回归 SQL 的缘由所在。

可靠性

数据库的另外一个基本规则是，它不该丢失或损坏数据。从这个维度看，TimescaleDB 和 InfluxDB 所采用的方法存在着明显的差别，进而对可靠性有着不一样的影响。

InfluxDB 从一开始曾试图使用 Go 完整地重写整个数据库。事实上在 0.9 版发布后，InfluxDB 更加坚决了这一决策方向，进而彻底重写了后端存储引擎（Influx 的早期版本意图发展为可插拔使用 LevelDB，RocksDB 等后端）。该决策的确提供了一些切实的优势。例如，开发人员能够构建特定于问题域的压缩算法，以更适合特定用例。InfluxDB 就使用了 Facebook 的 Gorilla 编码。

然而，这些设计决策对可靠性形成了很严重的影响。首先，InfluxDB 必须本身实现全套的容错机制，包括复制，高可用性和备份 / 恢复等。其次，InfluxDB 必须负责其磁盘可靠性。例如，确保其全部数据结构都是持久的，可以抵御出现故障时的数据损坏问题（甚至抵御在故障恢复期间出现故障）。

另外一方面，TimescaleDB 的架构决策使得其能够利用过去 25 年多艰苦、细致的工程成果。整个 PostgreSQL 社区已经构建了坚如磐石的数据库，可真正支持关键任务应用。

事实上，这是 TimescaleDB 联合创始人曾发帖“变无趣为有趣”（https://blog.timescale.com/when-boring-is-awesome-building-a-scalable-time-series-database-on-postgresql-2900ea453ee2）所阐述的一个核心理念。无状态微服务可能会崩溃并重启，或是易于向上和向下扩展。事实上，这正是整个“面向可恢复的计算”（recovery-oriented computing）的理念，也是新的“无服务器”设计模式背后的理念。一个数据库须要实际去保存数据，而且不该因处于某种被破坏的状态而在凌晨 3 点叫醒用户。

回头对比这两种可靠性

首先，程序可能崩溃，服务器可能会碰上硬件或电源故障，磁盘可能出现故障或遭受损坏。咱们能够缓解这些风险，例如采用强大的软件工程实践、不间断的电源、磁盘 RAID 等。可是风险是不可能完全消除的，这正是系统运行的真实状况。为此，数据库已构建了一系列机制以进一步下降此类风险，包括：流复制为副本、完整的快照备份和恢复、流备份、强大的数据导出工具等。

TimescaleDB 在设计上考虑了利用 Postgres 生态系统提供的全套工具，它们通过了严格的测试，而且都可用于开源系统中。其中包括：流复制实现高可用性和只读副本、pg_dump 和 pg_recovery 实现完整的数据库快照、pg_basebackup 和日志传送 / 流传输实现增量备份和任意时间点恢复，WAL-E 实现连续存档到云存储，以及强大的 COPY FROM 和 COPY TO 工具实现快速导入 / 导出各类格式的数据。

另外一方面，InfluxDB 则必须从零开始构建全部这些工具。事实上，时至今日 InfluxDB 依然没有提供全部这些功能。虽然它一开始在其开源版本中提供了复制和高可用性，但随后将此从开源版本中抽取出来，置于企业版产品中。它的备份工具可以执行完整快照和基于时间点的恢复，最近才增长了对手动增量备份的一些支持（也就是说，基于数据库时间范围执行增量备份的方法风险更大，由于时间戳数据可能会无序到达，所以从某一时间段开始的增量备份可能并未反映出晚到的数据）。InfluxDB 在易于安全输出大量数据上的能力也很是有限。咱们听过许多用户（包括一些曾有此经历的 Timescale 工程师）必须编写自定义脚本才能安全地导出数据。若是请求超过数万个数据点，就会致使数据库出现内存不足错误和崩溃。

其次，数据库须要提供基于磁盘的强大可靠性和持久性。一旦数据库提交写入存储，那么数据就会安全地保存到磁盘上。实际上，对于数据量很是大的数据，同一观点也适用于索引结构，不然索引可能须要数小时乃至很多天才能恢复。鉴于此，文件系统从使人痛苦的 fsck 恢复转向日志机制，这是有十分充分的理由的。

在 TimescaleDB 中，咱们决定不从最底层更改 PostgreSQL 的存储，也不干涉其预写日志的正常功能（WAL 确保了一旦写入被接受，就会被写入到磁盘日志，以确保安全性和持久性，甚至在数据写入到最终位置而且全部索引均安全更新以前）。这些数据结构对确保一致性和原子性相当重要，它们能够防止数据丢失或损坏，并确保可安全恢复。这正是数据库社区（和 PostgreSQL）的努力结果。想象一下，若是数据库正处于崩溃中恢复的过程当中，再次发生了崩溃（随后尝试恢复），那么这时会发生什么？

而 InfluxDB 必须从零开始设计和实现全部这些功能。这在数据库领域中是一个众所周知的难题，一般须要几年甚至几十年时间才能获得正确的解决方案。一些度量存储尽管会偶尔丢失数据，但这彻底是能够接受的。咱们已经看到在一些不能接受度量存储丢失数据的环境中使用了 TimescaleDB。事实上，在咱们全部的用户和部署中只有一份数据被破坏的报告，而调查结果代表这是由用户所使用的商业 SAN 存储致使的错误，而非 TimescaleDB 自己，而且用户继而从备份中成功恢复。而 InfluxDB 论坛则充斥着大量抱怨，例如“数据库在重启后丢失”，“高吞吐率期间发生数据丢失”，“InfluxDB 数据库发生数据丢失”，“因磁盘损坏发生崩溃后，数据库无响应”，“恢复多个数据库后，发生数据混乱”，不胜枚举。

这些挑战和问题并不是 InfluxDB 所独有的，每一个可靠的有状态服务开发人员都必须努力去解决这些问题。每一个数据库都会经历不时丢失数据的时期，的确很是难以让系统的各个边缘均正确运行。最终，全部这些边缘状况都会对运营商形成困扰。但 PostgreSQL 已在 20 世纪 90 年代经历过这一时期，而 InfluxDB 则仍然须要去解决这些问题。

所以，这些架构决策使得 TimescaleDB 可以站在众所周知的“巨人肩膀”上，于是提供了远超当前水平的可靠性。实际上，就在咱们于 2017 年 4 月首次发布 TimescaleDB 的一个月后，它就被部署用于欧洲和拉丁美洲的 47 家发电厂的仪表盘显示，直接面对操做人员。所以，虽然 InfluxDB（2013 年发布）先于 TimescaleDB（2017 年发布）数年发布，但咱们相信它仍然须要多年的专一工程才能遇上，尤为是考虑到它是从零开始构建的。

性能

下面，咱们经过对两个数据库作一系列插入和读取操做，以定量分析的方式提供确切的数值对比。

注意：咱们近期以开源时序数据基准测试集（TSBS，Time Series Benchmark Suite）的方式，发布了下面基准测试中全部使用的全部代码和数据（参见 Github 声明 https://github.com/timescale/tsbs）。

咱们对每一个数据库作了以下步骤的操做：

使用 TimescaleDB 版本 0.10.1(https://github.com/timescale/timescaledb/releases/tag/0.10.1) 和 InfluxDB 版本 1.5.2(https://github.com/influxdata/influxdb/releases/tag/v1.5.2)；
一台远程客户端机器，一台数据库服务器，位于同一云数据中心；
Azure 实例：标准（Standard）DS4 v2，其中 8 个 vCPU，28 GB 的内存；
4 个 1 TB 磁盘，配置为 raid0，使用 EXT4 文件系统；
两个数据库都可使用了所有的可用内存；
数据集：100 至 4000 个模拟设备中 1 到 10 个 CPU 在 3 天中每 10 秒生成的的度量数据。约 1 亿个读取时间点，约 10 亿个度量值；
对于插入操做，均使用 1 万批处理规模；
对于 TimescaleDB，设置块（Chunk）大小为 12 小时，合计 6 个块（具体细节参阅此处）。
对于 InfluxDB，咱们启用了时序索引（TSI，Time Series Index）。
插入性能

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

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

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

插入性能小结

对于插入操做，在数据量不大的工做负载上（例如，100 台设备发送一种度量），InfluxDB 的性能优于 TimescaleDB。
随着数据类的增长，InfluxDB 的插入性能要比 TimescaleDB 降低迅速。
对于必定数据规模乃至更大数据规模的工做负载（例如，100 台设备发送 10 种度量），TimescaleDB 的性能要优于 InfluxDB。
用户应了解自身的需求。这些局限可能并不是应用的瓶颈所在。

读取延迟状况

对于读取（即查询）延迟，测试结果略微复杂。这是由于不一样于测试主要与数据规模有关（可能也包括批处理规模），查询的种类繁多，尤为是对于 SQL 这样强大的查询语言。鉴于此，咱们发现测试读取延迟的最好方法是采用用户所要使用的实际查询。

这就是说，咱们使用大范围的查询以实现通用查询模式的最小化。下面给出的测试结果，是使用在插入测试中使用的同一工做赋值获得的。图表中的延迟单位均为微秒，多出的一行显示了 TimescaleDB 对比 InfluxDB 的相对性能（橙色显示 TimescaleDB 更快，而蓝色显示 InfluxDB 更快）。

基本上卷（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 的一些非官方项目或者是很早推出的（加星不多），或者是不活跃项目（多个月或数年没有更新）。

查看完整列表

https://docs.google.com/spreadsheets/d/1v4rLgph1LemuJBfh4rZxYTuektWvVF7XQphHi87oSxA/edit#gid=0

运维管理

即使一款数据库能知足上述全部要求，它仍须要运行起来。这样，必须有人去作运维。

从咱们的经验看，运维管理需求一般可归结为高可用性、资源（内存、磁盘、CPU）使用状况和通用工具这三个方面。

高可用性

不管数据库多么可靠，节点总会因为硬件故障、磁盘故障以及其它一些不可恢复的问题而宕机。这时，应确保具备用于故障切换的备用数据库，以避免发生数据丢失。

TimescaleDB 使用 PostgreSQL 的流备份技术支持高可用。从某种意义上讲，开源的 InfluxDB 也经过 InfluxDB-relay 实现高可用，可是该项目看上去已经止步不前（最近更新是在 2016 年 11 月）。当前 InfluxDB 仅在企业版中提供高可用。

资源使用状况内存使用

对于内存使用，数据规模依然起决定性影响。在下面给出的图中，咱们使用了测试插入性能的同一工做负载。

当数据规模不大时（100 台设备发送一种度量），InfluxDB 所需的内存要小于 TimescaleDB。

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

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

尤为是正如咱们所说起的，没有任何方法可限制 InfluxDB TSI 的内存占用。所以对于更大规模的数据，InfluxDB 会在插入时耗尽内存，这将致使数据库崩溃并重启。

磁盘使用

与使用面向列存储方式的大部分数据库同样，InfluxDB 相比起 PostgreSQL 和 TimescaleDB 提供了显著更优的磁盘压缩。

对于在基准测试中使用的数据集，下面列出了两款数据库对不一样规模数据的磁盘使用状况：

100 台设备 1 种度量 30 天： InfluxDB（12MB） vs. TimescaleDB（700MB） = 59 倍
100 台设备 10 种度量 30 天： InfluxDB（113MB） vs. TimescaleDB（1400MB） = 12 倍
4000 台设备 10 种度量 3 天： InfluxDB（769MB） vs. TimescaleDB（5900MB） = 8 倍

注意：磁盘规模的基准测试中使用了 ZFS 文件系统。测试数值中并未包括 WAL 大小，该大小是用户可配置的。

若是用户工做负载中的首要需求是磁盘占用最小化，那么两款数据库的差异很大，应该选用 InfluxDB。

可是正如咱们在前面看到的，根据工做负载不一样，InfluxDB 可能须要占用更多的内存。考虑到内存一般比磁盘贵成百上千倍，对于一些工做负载，须要考虑高磁盘占用和低内存使用的权衡。

TimescaleDB 还支持用户弹性地扩展一个超表（Hypertable）所关联的磁盘数量，无需任何数据迁移。该功能可解决高磁盘占用问题，尤为是在 SAN 和云环境中。有一位用户使用该方法，将单个 TimescaleDB 节点扩展到了 10TB 级。

InfluxDB 磁盘压缩的另外一个代价是它须要开发人员从头开始重写后台存储引擎，这对数据库的可靠性是一个挑战。

CPU 使用

根据 DNSFilter 所作的对比实验 (https://blog.dnsfilter.com/3-billion-time-series-data-points-dnsfilter-replaced-influxdb-with-timescaledb-d9f827702f8b) ，TimescaleDB 在资源使用上优于 InfluxDB 达 10 倍（虽然 TimescaleDB 的请求量要高 30%）。

图片来源：DNSFilter Comparison（2018年3月）

通用工具

在运维 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 和 InfluxDB 作了详细的比较。咱们并未宣称本身是 InfluxDB 专家，所以咱们欢迎你们对这里所作的比较提出建议。总而言之，咱们的目标是尽量透明地了解数据模型、方法和分析，并欢迎提供反馈。咱们也鼓励读者对本文提供的信息提出疑虑，帮助咱们在将来更好地开展基准测试。

咱们知道，TimescaleDB 并不是惟一的时序解决方案，在一些状况下它也并不是最适用的。在认可一些替代解决方案可能更可取以前，咱们会努力改进本身的产品。但咱们一直有兴趣对 TimescaleDB 解决方案作总体评估，并将继续与社区分享。