在过去的十年间，我们亲历了关系型、非关系型、在线分析处理(OLAP)型、以及在线事务处理(OLTP)型数据库的市场之争，也注意到了诸如：Snowflake、MongoDB、Cockroach Labs、以及Neo4j等新型数据库的产生和发展。而根据DB-Engines的一项针对数据库管理系统调查的统计(如下图所示)，时序型数据库(time series database，TSDB)是自2020年以来，增长快的数据库类型之一。
为什么要使用时序数据库?
时序数据库是针对摄取、处理和存储带有时间戳数据进行优化过的数据库。此类数据可能包括来自服务器和应用程序的参数指标、来自物联网传感器的读数、网站或应用程序上的用户交互、以及金融市场上的各种交易活动。
此处的时序数据通常具有如下属性特征：
- 每个数据点都包含了用于索引、聚合、以及采样的时间戳。此类数据往往是多维的、且相关的。
- 它们主要以高速写入(或称：摄取)的方式，来捕获高频的数据。
- 数据的汇总视图(例如：降采样、聚合视图或趋势线)可以提供比单个数据点更多的洞见。例如，考虑到网络的不稳定性、或传感器读数可能出现的异常，我们需要为在一段时间内，针对超过预定阈值的某些平均值设置警报，而并非仅针对单个数据点。
- 通常需要获取在一段时间内访问某类数据(例如，获取过去一周内的点击率数据)，以供深入分析。
虽然其他类型的数据库，也可以在一定程度上处理时序数据，但是TSDB可以在设计上，针对上述数据特性，更有效地处理那些随着时间的推移，而开展的各类数据摄取、压缩、以及聚合活动。
如今随着云计算、物联网、以及机器学习对于时序数据需求的持续爆炸式增长，软件架构师们应该如何选择TSDB呢?本文将综合比较市场上为流行的三种TSDB--InfluxDB，TimescaleDB和QuestDB，以帮助您做出明智的选择。
InfluxDB
于2013年被发布的InfluxDB，是TSDB领域的。如下图所示，它甚至超越了之前的Graphite和OpenTSDB。与许多开源(OSS)数据库类似，InfluxDB不但能够为单个节点提供MIT许可，而且提供了InfluxDB Cloud付费计划，以及为企业级用户提供了集群、以及生产环境就绪(production-ready)等功能。
图片来源：DB-engines
如下图所示，在2019年发布InfluxDB 2.x之前，InfluxDB平台是由TICK技术栈所组成，即：Telegraf(收集和报告参数指标的代理)、InfluxDB、Chronograf(从InfluxDB处查询数据的接口)、以及Kapacitor(实时数据流的处理引擎)。InfluxDB 1.x主要通过社区和集成，收集、存储和查看来自服务器和Web应用的时序数据指标。
图片来源：Influxdata
InfluxDB 2.x从本质上简化了整体架构。它将TICK栈捆绑到了单个二进制文件中，并且引入了一些新的功能，来执行收集(如：原生的Prometheus插件)、组织(如：各种组织和存储桶)、可视化(如：数据浏览器)数据、及其Flux语言。
在介绍InfluxDB的工作原理之前，让我们先了解如下三个关键概念：
- 数据模型(标签集模型)：除了时间戳字段，其实每个数据元素还会包含各种标签(如：可选的、已被索引的元数据字段)、字段(如：键和值)、以及指标(标签、字段和时间戳的容器)。下图示例展示了由科学家Anderson和Mullen在Klamath和Portland两地采集到的、蜜蜂和蚂蚁的数量普查数据。此处的位置(location)和科学家(scientist)标签，被当作蜜蜂和蚂蚁普查范围内的“字段/值(field/value)”对。
- 数据模式(TSM & TSI)：是一些存储在时间结构合并树(time-structured merge tree，TSM)和时序索引(time series index，TSI)文件中的数据元素。其中，TSM可以被认为是具有预写日志(write-ahead log，WAL)和类似于SSTable只读文件的LSM树。这些文件通常是经过排序和压缩的。而TSI则是可供InfluxDB内存映射的磁盘文件索引。它可以让操作系统以少近使用(Least Recently Used，LRU)内存的方式，来帮助处理具有高基数(high cardinality)的数据集(如，集合中的那些大型元素)。
- Flux脚本语言：是由InfluxDB开发的一种，可用于协助查询数据的特定域语言。同时，Flux也带有一个可协助从SQL数据源进行查询的SQL包。
值得注意的是，InfluxDB在摄取数据之前，不会强制执行某种结构模式。相反，它的结构模式是根据输入的数据被自动创建，以及从标签和字段中推断出来的。这种类似NoSQL的体验，对于InfluxDB来说有利也有弊。对于那些能够自动适合此类标记集模型基数的数据集(如：各种物联网数据、财务数据、以及大多数基础设施和应用程序的参数指标)而言，InfluxDB非常容易上手。用户也无需担心设计模式或索引(如下图所示)。同时，对于那些目标是创建物理资产数字模型的用例而言，它也是非常实用的。例如，在物联网中，人们可能需要创建一个数字孪生，来表示一组传感器，并摄取各种有组织的数据。
图片来源：Influxdata
另一方面，当数据集需要在连续的字段上建立索引(毕竟InfluxDB不支持数字，而且标签必须是字符串)或验证数据时，这种“无模式”就是一种缺陷。此外，由于标签会被索引，因此如果标签会经常变化(如，元数据可能在初次摄取后，就发生了变化)的话，仅依赖InfluxDB来推断模式，就可能会产生昂贵的开销。
再者，由InfluxDB决定创建其自定义的功能性数据脚本语言(如Flux)，会给整个生态系统增加一层复杂性。对此，InfluxDB的团队特别强调了如下两个从类SQL的InfluxQL转换为Flux 的驱动场景：
- 时序数据符合基于流的功能处理模型。其中，数据流是从一个输出转换为下一个输出。而由SQL支持的关系代数模型，则不能处理这种操作和函数的链接。
- 通过InfluxDB为时序数据(如，指数级的移动平均)的常见操作，提供的支持，而这并非SQL标准的一部分。
当然，用户需要花时间去熟悉Flux的语法，特别是那些追求简单的SQL查询方式，以及不打算学习另一种新语言的用户，尤为如此。好在InfluxDB已拥有大型的社区与集成，而且Flux能够与内置的仪表板相结合。
图片来源：Influxdata
总的来说，在面向基础设施和应用监控的需求时，InfluxDB能够与各种数据源无缝地集成。如果时序数据能够与标签集模型非常吻合的话，那么InfluxDB是一个不错的选择。可见，InfluxDB的优缺点可以被归结为：
- 优点：无模式摄取、庞大的社区、与流行工具相集成。
- 缺点：具有高基数、自定义查询/处理语言的数据集。
TimescaleDB
InfluxDB需要从头开始构建新的数据库和自定义语言，而TimescaleDB则建立在PostgreSQL之上，并添加了一个被称为超级表(hypertables)的中间层。该层将数据分块到多个底层数据表中，并将其抽象为一个可用于数据交互的单个大表。
与PostgreSQL的兼容性是TimescaleDB的大卖点。TimescaleDB能够完全支持所有的SQL功能(如：连接、二级和部分索引)，以及诸如PostGIS之类流行的扩展。作为PostgreSQL的扩展，TimescaleDB不但提供诸如Azure Database for PostgreSQL与Aiven之类的云托管选项，也提供了针对虚拟机或容器的各种自管理选项。
图片来源：Stack Overflow
TimescaleDB初是针对物联网平台，使用InfluxDB来存储它们的传感器数据。由于网络不稳定性，导致了物联网时序数据经常会出现拥堵和失序，因此TimescaleDB在高基数方面具有如下三个特点：
- 超级表(Hypertables)：TimescaleDB基于时间列、以及其他“空间”值(如：设备的UID、位置标识符、或股票代号)，来将其超级表划分成块。用户可以通过配置这些块，将新的数据保存到内存中，并按照时间列，将数据异步压缩和重新排序至磁盘(并非摄取时间)，以及在节点之间，以事务的方式进行复制和迁移。
- 持续聚合(Continuous Aggregation)：通常，物联网数据在汇总时更为实用，因此我们无需在每个汇总查询中去扫描大量的数据。由于支持数据的持续聚合，TimescaleDB能够快速地计算出诸如：小时平均值、小值和大值等关键指标(如，计算出下午3点到4点之间的平均温度，或是下午3点时刻的确切温度)。这将有助于创建高性能的仪表板与分析结果。
- 数据保留(Data Retention)：在传统关系型数据库中，大量的删除操作往往代价高昂。然而，由于TimescaleDB是以块的形式存储数据的，因此它提供了一种drop_chunks的功能，可以在同等开销下，快速地删除旧的数据。由于旧数据的相关性会随着时间的推移而降低，因此TimescaleDB可以通过与长期存储(如，OLAP或Blob存储)一起使用，来移走旧的数据，节省磁盘空间，进而为新的数据上提供优异的性能。
就性能而言，时序基准套件(Time Series Benchmark Suite，TTSBS，)详细比较了TimescaleDB 1.7.1和InfluxDB 1.8.0(两者都是OSS版本)在插入和读取延迟方面的性能指标。不过，由于如今两者都已经拥有了2.x版本，因此该分析略显过时。从下图比较结果可知，TimescaleDB会随着数据基数的增长(以3.5倍速)，提供卓越的性能。
InfluxDB与TimescaleDB的摄取速度比较
TimescaleDB团队指出，InfluxDB的基于日志结构合并树系统(tree-based system，TSI)与TimescaleDB的B树索引方法，是性能制胜的法宝。当然，我在此并未武断地认为TimescaleDB在性能方面就一定优于InfluxDB。毕竟性能基准测试受到数据模型、硬件、以及配置等多方面的影响较大。该比较结果仅表明，TimescaleDB可能更适合数据基数较高的物联网用例(例如，在1000万台设备中，获悉设备X的平均功耗)。具体有关这两个数据库之间的深度比较，请参见由Timescale自行提供的《TimescaleDB与InfluxDB的比较》。
总体而言，TimescaleDB非常适合那些寻求显著性能提升，而不想通过大量重构来迁移现有SQL数据库的团队。尽管TimescaleDB相对较新(于2017年被发布)，但是许多物联网初创公司已在使用它作为中间数据存储，以快速提取横跨数月的聚合参数指标，并将旧的数据移至长期存储处。如果您已经在Kubernetes集群上运行着 PostgreSQL，那么安装TimescaleDB和迁移数据的任务都会相对比较容易。
总的说来，TimescaleDB的优缺点可以被归结为：
- 优点：与PostgreSQL兼容性，可以很好地扩展数据基数，并提供各种部署模型。
- 缺点：结构模式固定，而且在摄取之前增加了复杂性和数据的转换工作。
QuestDB
对于那些既希望利用InfluxDB内联协议的灵活性，又熟悉PostgreSQL的人来说，QuestDB(YC S20)作为一个较新的时序数据库，可以满足开发者的这两个要求。它是一个用Java和C++编写的开源TSDB，虽然被推出仅一年多，但是已排名到了前15。从原理上说，QuestDB是利用内存映射文件，在数据提交到磁盘之前，实现快速读写的。
图片来源：QuestDB
QuestDB通过使用Java和C++，来从头开始构建数据库，其主要特征体现在：
- 性能：解决摄取过程中，特别是在处置高基数的数据集过程中的瓶颈。同时，它还通过顺次存储的时分数据(即，在内存中的混洗)，以及仅分析请求的列/分区，而并非以整张表的方式，来支持快速的数据检索。此外，QuestDB还会运用SIMD指令，实现并行化操作。
- 兼容性：QuestDB支持InfluxDB的内联(inline)协议、PostgreSQL wire、REST API、以及CSV上传的方式，来摄取数据。那些习惯了其他TSDB的用户，可以轻松地移植他们的现有应用程序，而无需进行大量的重写工作。
- 通过SQL进行查询：虽然能够支持多种摄取机制，但是QuestDB也会使用SQL作为查询语言，因此用户无需额外地学习Flux之类的特定域语言。
在性能方面，QuestDB近发布了一篇包含基准测试结果的博文，展示了其每秒140万行的写入速度。QuestDB团队在cpu-only的用例中，使用了TSBS基准测试。其中m5.8xlarge在AWS上的实例中，使用了多达14个work(注意：该140万行的数字，源于使用了AMD Ryzen5的处理器)。
对于具有高基数(超过1000万)的数据集，QuestDB的性能优于其他TSDB。凭借着Intel Xeon CPU，其峰值的摄取吞吐量为904k行/秒，并能够在1000万台设备上使用四个线程，且在m5.8xlarge实例上维持约640k行/秒的性能。而当QuestDB在AMD Ryzen 3970X上运行相同的基准测试时，它具有超过1百万行/秒的摄取吞吐量。
各种TSDB在摄取吞吐量与设备数量上的比较
同样，上述基于数据模型和DB调整的性能基准测试也可能不够客观，不过它们在一定程度上体现了QuestDB的性能优势。
QuestDB的另一个有趣的特性是，在摄取中支持InfluxDB内联协议和PostgreSQL的wire。对于现有的InfluxDB用户，您可以将Telegraf配置为指向QuestDB的地址和端口。同理，PostgreSQL用户使用现有的客户端库、或JDBC，将数据写入QuestDB。当然，无论采用何种摄取方法，我们都可以使用标准的SQL去查询数据。值得注意的是，其API参考页面上，显著地列出了一些例外的情况。
作为该领域的新玩家，QuestDB明显的缺点是，缺乏生产环境就绪的功能(如，复制、备份与恢复等)。同时，它虽然能与诸如：PostgreSQL、Grafana、Kafka、Telegraf、以及Tableau等流行工具相集成，但是需要花时间调试与磨合，方可达到上述其他TSDB的水平。
总的说来，QuestDB的优缺点可以被归结为：
- 优点：快速摄取(特别是对于具有高基数的数据集)，支持InfluxDB内联协议和PostgreSQL wire，可以通过标准的SQL查询数据。
- 缺点：在用户社区、可用集成、以及对生产环境就绪等方面，都有待改进。
小结
随着业界对于时序数据需求的不断增长，专门处理此类数据的TSDB将会被大规模地采用，并引发激烈的竞争。除了上面介绍的三大开源TSDB之外，市场上还有AWS(AWS Timestream)和Azure(Azure Series Insights)等公共云产品。
与传统数据库类似，选择TSDB主要仍取决于您的业务需求、数据模型、以及数据用例。如果您的数据适合于具有丰富的、集成生态系统的标签集模型，那么请选择InfluxDB。TimescaleDB则非常适合于现有的PostgreSQL用户。而如果性能是您的首要考虑因素的话，请您考虑选用QuestDB。
