比较了InfluxDB、TimescaleDB和QuestDB这三种时序数据库）类型的数据库市场竞争，也注意到了Snowflake、MongoDB、CockroachLabs、Neo4j等新型数据库的出现和发展。根据DB-Engines对数据库管理系统的调查（如下图），时序数据库（timeseriesdatabase，TSDB）是2020年以来增长最快的数据库类型之一。为什么要使用时序数据库？时间序列数据库是为摄取、处理和存储时间戳数据而优化的数据库。此类数据可能包括来自服务器和应用程序的参数指标、来自物联网传感器的读数、用户在网站或应用程序上的交互，以及金融市场中的各种交易活动。这里的时间序列数据通常具有以下属性：每个数据点都包含一个时间戳，用于索引、聚合和采样。此类数据往往是多维且相关的。他们主要使用高速写入（或：摄取）来捕获高频数据。数据的聚合视图（例如：下采样、聚合视图或趋势线）可以提供比单个数据点更多的洞察力。例如，鉴于网络不稳定，或传感器读数可能出现异常，我们需要为一段时间内超过预定阈值的某些平均值设置警报，而不是仅针对单个数据点。通常需要获取一段时间内访问的某些类型的数据（例如获取过去一周内的点击率数据）进行深入分析。虽然其他类型的数据库也可以在一定程度上处理时间序列数据，但TSDB可以设计为更有效地处理各种数据摄取、压缩和聚合活动。如今，随着云计算、物联网、机器学习对时序数据的持续爆发式增长，软件架构师应该如何选择TSDB？本文将全面比较市场上最流行的三种TSDB——InfluxDB、TimescaleDB和QuestDB，帮助您做出明智的选择。InfluxDB于2013年首次发布，是TSDB领域的领导者。如下图所示，甚至超越了之前的Graphite和OpenTSDB。与许多开源（OSS）数据库类似，InfluxDB不仅提供单节点MIT许可证，还提供InfluxDBCloud付费计划，以及面向企业用户的集群和生产就绪功能。图片来源：DB-engines如下图所示，在2019年InfluxDB2.x发布之前，InfluxDB平台由TICK技术栈组成，即：Telegraf（收集并上报参数指标的agent）、InfluxDB、Chronograf（来自用于查询数据的InfluxDB接口）和Kapacitor（用于实时数据流的处理引擎）。InfluxDB1.x主要通过社区和集成从服务器和Web应用程序收集、存储和查看时间序列数据指标。图片来源：InfluxdataInfluxDB2.x从本质上简化了整体架构。它将TICK堆栈捆绑到一个二进制文件中，并引入了新功能来执行收集（例如本机Prometheus插件）、组织（例如各种组织和存储桶）、可视化（例如数据浏览器）数据及其Flux语言。在介绍InfluxDB的工作原理之前，我们先来了解以下三个关键概念：数据模型（标签集模型）：除了时间戳字段，每个数据元素实际上都会包含各种标签（如：可选的，已经索引的元数据字段）、字段（例如键和值）和指标（标签、字段和时间戳的容器）。下图显示了科学家安德森和马伦在克拉马斯和波特兰收集的蜜蜂和蚂蚁的普查数据示例。这里的位置和科学家标签被视为蜜蜂和蚂蚁普查范围内的“字段/值”对。蜜蜂和蚂蚁普查数据示例DataSchema(TSM&TSI)：这些数据元素存储在时间结构合并树(TSM)和时间序列索引(TSI)文件中。其中，TSM可以认为是一个LSM树，带有一个预写日志（WAL）和一个类似于SSTable的只读文件。这些文件通常经过排序和压缩。TSI是一个磁盘文件索引，可以被InfluxDB进行内存映射。它允许操作系统以使用最近最少使用(LRU)内存的方式帮助处理具有高基数的数据集（例如集合中的那些大元素）。Flux脚本语言：是InfluxDB开发的一种领域特定语言，可用于辅助查询数据。同时，Flux还自带了一个SQL包，可以辅助从SQL数据源进行查询。值得注意的是，InfluxDB在摄取数据之前不会强制执行某种结构模式。相反，它的结构模式是根据输入数据自动创建的，并从标签和字段中推断出来。这种类似NoSQL的体验对InfluxDB有利也有弊。InfluxDB非常易于用于可以自动适应此类标记模型基数的数据集（例如：各种物联网数据、财务数据以及大多数基础设施和应用程序的参数指标）。用户也无需担心设计模式或索引（如下图所示）。对于目标是创建物理资产的数字模型的用例，它也非常实用。例如，在物联网中，人们可能需要创建一个代表一组传感器并摄取各种有组织的数据的数字孪生体。图片来源：Influxdata另一方面，当数据集需要在连续字段上建立索引（InfluxDB毕竟不支持数字，标签必须是字符串）或验证数据时，这种“无模式”是一个缺点。此外，由于标签已编入索引，如果标签经常更改（例如，元数据可能在初始摄取后已更改），仅依靠InfluxDB来推断模式可能会很昂贵。此外，由InfluxDB决定创建自己的自定义功能数据脚本语言，如Flux，为整个生态系统增加一层复杂性。对此，InfluxDB团队特别强调了从类SQLInfluxQL到Flux转换的两个驱动场景：时间序列数据符合基于流的函数处理模型。其中，数据流从一个输出转化为下一个输出。然而，SQL支持的关系代数模型无法处理这种操作和函数的链接。InfluxDB为不属于SQL标准的时间序列数据（例如，指数移动平均数）的常见操作提供一流的支持。当然，用户需要花时间熟悉Flux的语法，尤其是追求简单的SQL查询方式，不打算再学习一门新语言的用户。幸运的是，InfluxDB已经拥有庞大的社区和集成，Flux可以与内置的仪表板结合使用。图片来源：Influxdata一般来说，InfluxDB可以与各种数据源无缝集成，以满足基础设施和应用程序监控需求。如果时间序列数据与标签集模型吻合得很好，那么InfluxDB是一个不错的选择。可以看出，InfluxDB的优缺点可以总结如下：优点：无模式摄取、庞大的社区、与流行工具的集成。缺点：具有高基数的数据集、自定义查询/处理语言。虽然TimescaleDBInfluxDB需要从头开始构建新的数据库和自定义语言，但TimescaleDB是在PostgreSQL之上构建的，并添加了一个称为超表的中间层。该层将数据分块到多个底层数据表中，并将它们抽象成一个可用于数据交互的大表。与PostgreSQL的兼容性是TimescaleDB的最大卖点。TimescaleDB完全支持所有SQL功能（例如：连接、二级索引和部分索引），以及流行的扩展，例如PostGIS。作为PostgreSQL的扩展，TimescaleDB不仅提供了AzureDatabaseforPostgreSQL和Aiven等云托管选项，还为虚拟机或容器提供了各种自我管理选项。图片来源：StackOverflowTimescaleDB最初针对物联网平台，使用InfluxDB来存储其传感器数据。由于网络的不稳定性，物联网的时间序列数据经常出现拥塞和乱序。因此，TimescaleDB在高基数方面具有以下三个特点：块。用户可以配置这些块将最新数据保存在内存中，根据时间列（而非摄取时间）异步压缩和重新排序数据到磁盘，并以事务方式在节点之间复制和迁移。持续聚合：一般来说，物联网数据在聚合时更有用，所以我们不需要在每次聚合查询时都扫描大量数据。由于支持数据的连续聚合，TimescaleDB可以快速计算关键指标如：小时平均值、最小值和最大值（例如，计算下午3点到4点的平均温度，或者下午3点的时间）温度）。这将有助于创建高性能仪表板和分析结果。数据保留：在传统的关系数据库中，大量的删除操作往往代价高昂。但是，由于TimescaleDB以chunk的形式存储数据，它提供了一个drop_chunks函数，可以用同样的开销快速删除旧数据。因为旧数据的相关性会随着时间的推移而降低，TimescaleDB可以与长期存储（如OLAP或Blob存储）一起使用，以去除旧数据，节省磁盘空间，然后为新数据提供新数据。提供卓越的性能。在性能方面，TimeSeriesBenchmarkSuite(TTSBS)在插入和读取延迟方面详细比较了TimescaleDB1.7.1和InfluxDB1.8.0（均为OSS版本）的性能指标。然而，由于今天两者都有2.x版本，分析有点过时了。从下图的对比结果可以看出，随着数据库的增长（3.5倍的速度），TimescaleDB会提供出色的性能。InfluxDB与TimescaleDB的摄取速度对比TimescaleDB团队指出，InfluxDB的日志结构合并树系统（tree-basedsystem，TSI）和TimescaleDB的B树索引方式是性能的法宝。当然，我并不是武断地认为TimescaleDB在性能上一定比InfluxDB好。毕竟，性能基准受数据模型、硬件和配置的影响很大。这种比较的结果仅表明TimescaleDB可能更适合具有高数据库的物联网用例（例如，了解1000万台设备中设备X的平均功耗）。两个数据库的深入对比，请看Timescale自己提供的《TimescaleDB与InfluxDB的比较》。总的来说，TimescaleDB非常适合寻求显着性能提升而无需大量重构以迁移现有SQL数据库的团队。尽管TimescaleDB相对较新（于2017年首次发布），但许多物联网初创公司已经将其用作中间数据存储，以快速提取跨越数月的聚合参数指标，并将较旧的数据移动到长期存储位置。如果您的Kubernetes集群上已经运行了PostgreSQL，那么安装TimescaleDB和迁移数据的任务将相对容易。总的来说，TimescaleDB的优缺点可以总结如下：优点：兼容PostgreSQL，可以很好的扩展数据库，提供多种部署模型。缺点：结构模式固定，增加了复杂度和摄取前的数据转换工作。QuestDB对于那些想利用InfluxDB内联协议的灵活性和熟悉PostgreSQL的人来说，QuestDB（YCS20）作为一个较新的时序数据库，可以满足开发者的这两个需求。它是一个用Java和C++编写的开源TSDB，尽管刚刚推出一年多，但它已跻身前15名。原则上，QuestDB在数据提交到磁盘之前，使用内存映射文件实现快速读写。图片来源：QuestDBQuestDB使用Java和C++从头开始??构建数据库。其主要特点是：性能：解决摄取过程中的瓶颈，尤其是在处理高基数数据集的过程中。同时，它还支持时分数据顺序存储（即在内存中混洗）的快速数据检索，只分析请求的列/分区，而不是整个表。此外，QuestDB还将使用SIMD指令来实现并行操作。兼容性：QuestDB支持InfluxDB的内联协议、PostgreSQLwire、RESTAPI和CSV上传方法来摄取数据。习惯于其他TSDB的用户可以轻松地移植他们现有的应用程序，而无需进行大量的重写工作。通过SQL查询：虽然可以支持多种摄取机制，但QuestDB也使用SQL作为查询语言，因此用户无需额外学习Flux等领域特定语言。在性能方面，QuestDB最近发布了一篇博客文章，其基准测试结果显示其写入速度为每秒140万行。QuestDB团队将TSBS基准用于仅cpu用例。其中，m5.8xlarge在AWS上的实例中使用了多达14个works（注：140万行数来源于使用AMDRyzen5处理器）。对于具有高基数（超过1000万）的数据集，QuestDB优于其他TSDB。使用IntelXeonCPU，其峰值摄取吞吐量为904k行/秒，能够在1000万台设备上使用四个线程，并在m5.8xlarge实例上保持约640k行/秒的性能。当QuestDB在AMDRyzen3970X上运行相同的基准测试时，它的摄取吞吐量超过100万行/秒。各种TSDB在摄取吞吐量和设备数量方面的比较同样，上述基于数据模型和DB调整的性能基准可能不够客观，但它们在一定程度上反映了QuestDB的性能优势。QuestDB的另一个有趣的特性是支持InfluxDB内联协议和PostgreSQL的摄取线。对于现有的InfluxDB用户，您可以将Telegraf配置为指向QuestDB的地址和端口。同样，PostgreSQL用户使用现有的客户端库或JDBC将数据写入QuestDB。当然，无论采用何种摄取方式，我们都可以使用标准的SQL来查询数据。值得注意的是，在其API参考页面上突出列出了一些例外情况。作为该领域的新手，QuestDB最明显的缺点是缺乏生产就绪的功能（例如，复制、备份和恢复等）。同时，虽然可以与PostgreSQL、Grafana、Kafka、Telegraf、Tableau等流行工具集成，但要达到上述其他TSDB的水平还需要时间调试和适配。总的来说，QuestDB的优缺点可以总结如下：优点：摄取速度快（特别是对于高基数的数据集），支持InfluxDB内联协议和PostgreSQLwire，可以通过标准SQL查询数据。缺点：在用户社区、可用集成和生产准备方面留有改进空间。总结随着行业对时序数据的需求不断增长，专门处理此类数据的TSDB将被大规模采用，并引发激烈的竞争。除了上面介绍的三个开源TSDB，市面上还有AWS（AWSTimestream）、Azure（AzureSeriesInsights）等公有云产品。与传统数据库类似，选择TSDB主要取决于您的业务需求、数据模型和数据用例。如果您的数据适用于具有丰富的集成生态系统的标签集模型，请选择InfluxDB。TimescaleDB是现有PostgreSQL用户的理想选择。如果性能是您的首要考虑因素，请考虑选择QuestDB。原标题：ComparingInfluxDB,TimescaleDB,andQuestDBTimeSeriesDatabases，作者：YitaekHwang
