https://www.itcodemonkey.com/article/9339.html
时序数据已用于越来越多的应用中，包括物联网、DevOps、金融、零售、物流、石油天然气、制造业、汽车、太空、SaaS，乃至机器学习和人工智能。虽然当前时序数据库仅局限于采集度量和监控，但是软件开发人员已经逐渐明白，他们的确需要一款时序数据库，真正设计用于运行多种工作负载。
如果我们考虑采用一款时序数据库产品，这可能意味着我们正面对大量时序数据的快速堆积。我们需要一个地方对这些时序数据进行存储和分析。人们此时可能已经认识到，业务的存活严重地依赖于所选取的数据库。
如何选取时序数据库
在评估工作负载所使用的时序数据库时，需考虑多个因素：
-
数据模型；
-
查询语言；
-
可靠性；
-
性能；
-
生态系统；
-
运维管理；
-
企业 / 社区的支持情况.
本文中，我们将对比两款业界领先的时序数据库，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 解决方案做整体评估，并将继续与社区分享。