穿越分界线：时间序列数据与关系数据的区别

我在职业生涯中编写了许多应用程序，包括客户端和Web应用程序，并且我深知从头开始构建一个开发良好的应用程序的重要性。因此，我认为基于我对时间序列数据和关系数据的独特理解，编写一篇关于它们之间区别的文章非常重要。

关系数据 

关系数据的主要目标是根据对象及其之间的关系，准确地维护世界当前状态的表示。这意味着关系数据库必须通过允许用户更改对象来维护该当前状态的准确表示，从而改变它们之间的关系。

用户是关系数据的典型例子。用户具有重要信息，例如姓名和电子邮件地址，需要保持更新，而且用户对象与系统中的其他对象之间存在关系，例如他们创建的内容。

时间序列数据 

时间序列数据在性质上与关系数据非常不同。时间序列是一系列离散观测的流。尽管这些观测看起来可能像是关系数据，并且可以适应关系数据库，但是这些数据点彼此之间没有关联。每个单独的观测是一个时间点，并且与其他观测并不特别相关，它们也是自己的时间点。时间序列数据不是事务性数据 - 它很少或几乎不会被编辑或更新。收集时间序列数据的主要目标是进行总结和分析。

时间序列数据包括事件（创建了一个用户）、指标（在特定时间的传感器读数）和日志（系统遇到了意外的状态，开发人员编写了一些调试信息）。

在关系数据库中使用时间序列数据会导致问题 

把时间序列数据存储到熟悉的Postgres或MySQL数据库中可能很诱人，但这是一个坏主意，原因有很多。

关系数据库不具备可扩展性 

关系数据库在测试、原型设计或生产的早期阶段可能不会暴露出与时间序列数据一起扩展的问题。在构建和早期增长阶段，随着用户数量的增长，时间序列数据会呈指数增长。例如，第一个用户将需要存储十倍的时间序列数据。添加第二个用户将需要存储100倍的时间序列数据。到第三个用户加入站点时，你将需要空间来存储1000倍的时间序列数据。

关系数据库可以支持这种增长一段时间。然而，有一天，你的成功、规模适中的生产应用程序遇到了一个工作量大小，在这个大小下，存储的数据量加上用户数量或观测数量达到了可扩展性的临界点。

时间变得可读的时间（TTBR）是数据写入后到可读的延迟时间。TTBR是你知道数据库无法跟上写入速度的指标，当你看到它时，就意味着出现了问题。对于时间序列数据，你需要快速的TTBR，因为你希望在异常出现时立即采取行动，无论是通过自动化还是通知进行手动操作。

当关系数据库的存储容量过满时，备份过程会导致数据库变慢，数据写入时间大大延长，TTBR可能增加到一分钟或更长。这对于任何即时行动都是不利的。相比之下，时间序列数据库的写入速度为毫秒级，使得在出现异常时可以立即采取行动。

当然，比慢速的数据写入更糟糕的问题是，关系数据库可能由于高负载而发生故障。

在我们的内部基准测试中，InfluxDB每秒能够处理数量级更多的数据，而且使用的CPU和内存明显少于其他数据库，甚至那些声称经过时间序列优化的数据库。

迁移的困扰 

时间序列数据的结构可以迅速变化。一个典型的例子是添加一个维度。假设一个应用程序正在跟踪URL的健康状况，并且开发人员决定在监控这些URL一段时间后开始跟踪响应对象的大小。

关系数据库需要明确的模式，因此添加一个新的数据维度需要对模式的每一次更改进行完整的数据迁移。至少，现有的生产数据库表需要进行迁移，以匹配新的模式，包括新的列。每当进行迁移时，与耗时的过程相关联的数据损坏或丢失风险都存在，即使使用迁移工具如Alemic或Rake。这些冒险的迁移是由于任何需要明确模式的数据库的一般缺乏灵活性。

InfluxDB采用了“写入时模式”，这意味着可以通过简单地将它们添加到新的写入中来添加新的维度和字段。无需对我的开发或生产数据库进行任何更改。

基于Apache Arrow的时间序列数据库提供了一个有趣的解决方案 

在使用关系数据库处理时间序列数据时，扩展性和模式不是唯一的挑战。在许多情况下，您的代码需要检索大量的观测数据以进行有趣的计算，而关系数据库不支持这种操作。如果您不使用Apache Arrow，那么您将以较困难的方式处理大型数据集。Arrow专门用于传输大量的列式数据，并允许工具有效地对数据进行操作。

即使是检索大量数据并在客户端代码中将其转换为Arrow格式的基本任务也无法实现，因为它缺乏Arrow在传输过程中和您自己的代码中提供的压缩功能。如果您不使用返回Arrow格式数据的数据库，那么您的生产应用程序将难以确保有足够的内存来处理大型数据集。通过网络传输大量压缩不良的字节会增加数据库与代码之间的延迟。

还有实际的编程模型。Apache Arrow项目中的上游库允许用户查询大量数据，高效地将其传输到客户端并对数据进行操作。一旦您使用了Arrow库和类似Pandas的工具来操作大型数据集，您就不会再回到通过游标循环遍历和转换数据或将其交给其他库的方式了。

使用SQL查询时间序列数据 

Apache生态系统的整合也为在InfluxDB中构建SQL支持提供了机会。该数据库使用DataFusion作为其查询引擎，并且DataFusion使用SQL作为查询语言，这意味着任何了解SQL的人都可以查询时间序列数据。

我们还在DataFusion中创建了三个针对时间序列的特定函数，以便Apache Arrow社区的任何人都可以从中受益或做出贡献。

date_bin() - 一个函数，用于创建具有聚合的时间窗口数据行。selector_first(), selector_last() - 提供满足特定条件的表中的第一行或最后一行的函数。time_bucket_gapfill() - 返回窗口化的数据。如果存在缺少数据的窗口，它将填充这些间隙。

最重要的是 

关系数据和时间序列数据是非常不同的数据类型，每种数据类型都有其自己的存储需求、功能和工作负载。表面上，关系数据和时间序列数据看起来很相似，这对于不熟悉的人来说可能是一个隐蔽的问题。这就是为什么在过程的早期阶段就了解这些差异非常重要。如果您等到在生产环境中出现问题时才解决，那么问题将变得更加具有挑战性。

时间序列数据需要一个时间序列数据库，比如InfluxDB，以应对高摄入速率下的低TTBR、写入时模式数据收集的灵活性以及高级数据分析。InfluxDB中的原生SQL支持使时间序列数据的工作负载对SQL用户更加可访问。

InfluxDB专为时间序列数据及其独特的工作负载而构建。将这项技术添加到您的技术堆栈中将有助于修复或完全避免上述的问题。

作者：Rick Spencer

更多技术干货请关注公号“云原生数据库”

squids.cn，基于公有云基础资源，提供云上 RDS，云备份，云迁移，SQL 窗口门户企业功能，

帮助企业快速构建云上数据库融合生态。

​