[关闭]
@Rays 2018-09-04T15:47:43.000000Z 字数 12734 阅读 6254

如何选择合适的时序数据库？

架构&设计

摘要： 本文对比了TimescaleDB与InfluxDB这两款业界领先的时序数据库产品，测试了二者在数据模型、查询语言、可靠性、性能、生态系统、运维管理以及公司/社区支持等方面的差异。

作者： Mike Freedman

正文：

TimescaleDB与InfluxDB的对比：构建用于不同时序数据的数据库

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

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

如何选取时序数据库

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

本文中，我们将对比两款业界领先的时序数据库，TimescaleDB和InfluxDB，意在为软件开发人员正确选取所需的时序数据库提供参考。

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

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

此外，这次比较并非完全理论上的。我们的企业最初是一家物联网平台。在该平台上，我们最初选用InfluxDB存储传感器数据。但是考虑到本文下面将列出的一些差异之处，我们发现InfuxDB并不能满足我们的需求。基于此，我们构建了首个满足需求的时序数据库TimescaleDB，并发现了对该数据库具有需求的其它一些客户，因此我们决定将数据库开源。当前在不到一年半的时间中，TimescaleDB已经被下载数十万次，并在全球范围内的生产环境中使用（更多信息，参见我们介绍TimescaleDB的起源一文）。

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

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

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

数据模型

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

在数据模型方面，TimescaleDB和InfluxDB存在两种完全不同的观点。TimescaleDB是一种关系型数据，而InfluxDB更多的则是一种定制的、NoSQL的非关系型数据库。这意味着TimescaleDB是基于关系数据库模型的，而关系模型在PostgreSQL、MySQL、SQL Server、Oracle等数据库中得到了普遍的应用。另一方面，InfluxDB提出了自己的数据模型。在本文的对比中，我们将该数据模型称为“Tagset数据模型”。

关系数据模型

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

下面给出一个例子：

该方法的优点在于非常灵活。用户可以选择：

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

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

Tagset数据模型

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

下面给出一个例子：

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

数据模型小结

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

查询语言

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

更多细节，可参阅我们近期发布的SQL和Flux的对比文章。

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

InfluxDB则不同，它采取了介于SQL和NoSQL之间的做法，使用了一种称为“InfluxQL”的类SQL查询语言。近期，它进一步做了定制，提供了新的Flux查询语言。因此，InfluxDB创建了一种新的查询语言。据其创建者宣称，Flux解决了他们碰到的SQL中存在的一些问题（具体细节，参阅Flux发行说明、Hacker News讨论帖，以及我们的SQL和Flux的对比文章）。

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

TimescaleDB（SQL）

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

InfluxDB（Flux）

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

更多细节，可参阅我们近期发布的SQL和Flux的对比文章。

总而言之，我们认为在很多情况下，SQL都是时序数据库的正确查询语言。

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

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

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

可靠性

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

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

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

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

事实上，这是TimescaleDB联合创始人曾发帖“变无趣为有趣”（When Boring is Awesome: Building a scalable time-series database on PostgreSQL）所阐述的一个核心理念。无状态微服务可能会崩溃并重启，或是易于向上和向下扩展。事实上，这正是整个“面向可恢复的计算”（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声明）。

参考阅读：推荐一款基准测试：对TSBS的介绍

我们对每个数据库做了如下步骤的操作：

插入性能

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

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

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

插入性能小结

读取延迟情况

对于读取（即查询）延迟，测试结果略微复杂。这是因为不同于测试主要与数据规模有关（可能也包括批处理规模），查询的种类繁多，尤其是对于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并不支持全部的复杂查询，包括多连接、窗函数、地理空间查询等，因此我们也没有对这些查询进行测试。

读取性能小结

基准测试中的稳定性考虑

需要注意的是，在对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而言并非问题，即便是面对大规模数据时。

稳定性小结

生态系统

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

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

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

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

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


点击此链接可查看完整列表。

运维管理

即便一款数据库能满足上述所有要求，它仍需要运行起来。这样，必须有人去做运维。

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

高可用性

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

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

资源使用情况

内存使用

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

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

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

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

尤其是正如我们所提及的，没有任何方法可限制InfluxDB TSI的内存占用。因此对于更大规模的数据，InfluxDB会在插入时耗尽内存，这将导致数据库崩溃并重启。

磁盘使用

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

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

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

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

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

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

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

CPU使用

根据DNSFilter所做的对比实验，TimescaleDB在资源使用上优于InfluxDB达10倍（虽然TimescaleDB的请求量要高30%）。

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

通用工具

在运维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解决方案做整体评估，并将继续与社区分享。

查看英文原文： TimescaleDB vs. InfluxDB: purpose built differently for time-series data

添加新批注
在作者公开此批注前，只有你和作者可见。
回复批注