比较 InfluxDB、TimescaleDB 和 QuestDB 时间序列数据库 _时间序列数据库比较

开源时间序列数据库的高级概述，以比较它们的特性、功能、成熟度和性能，这里主要围绕InfluxDB、TimescaleDB 和 QuestDB比较和区别。
时间序列数据库比较：我们生活在数据库的黄金时代，资金以历史速度流入该行业（例如，Snowflake、MongoDB、Cockroach Labs、Neo4j）。如果关系与非关系或在线分析处理 (OLAP) 与在线事务处理 (OLTP) 之间的争论统治了过去十年，那么新型数据库一直在稳步增长。根据DB-Engines一项收集和呈现数据库管理系统信息的倡议，时间序列数据库是自 2020 年以来增长最快的领域：

文章图片
为什么要使用时间序列数据库？
时间序列数据库 (TSDB) 是优化用于摄取、处理和存储时间戳数据的数据库。此类数据可能包括来自服务器和应用程序的指标、来自物联网传感器的读数、网站或应用程序上的用户交互或金融市场上的交易活动。
以下属性通常表征时间序列工作负载：

每个数据点都包含用于索引、聚合和采样的时间戳。该数据也可以是多维的和相关的。
首选高写入速度（摄取）以捕获高频数据。
数据的汇总视图（例如，下采样或聚合视图、趋势线）可以提供比单个数据点更多的洞察力。例如，考虑到网络不可靠性或传感器读数异常，我们可能会在一段时间内的某个平均值超过阈值时设置警报，而不是在单个数据点上这样做。
分析数据通常需要在一段时间内访问它（例如，给我过去一周的点击率数据）。

虽然其他数据库也可以在一定程度上处理时间序列数据，但 TSDB 的设计具有上述特性，可以更有效地处理随时间推移的数据摄取、压缩和聚合。因此，随着云计算、物联网和机器学习的出现，对时间序列数据的需求持续爆炸式增长，架构师应该如何选择 TSDB？本文将比较市场上流行的 TSDB 和新玩家，以帮助你做出决定。
InfluxDB 详细信息时间序列数据库比较：InfluxDB 于 2013 年首次发布，是 TSDB 领域的市场领导者，超越了之前的 Graphite 和 OpenTSDB。与许多 OSS 数据库公司一样，InfluxDB获得了单个节点的 MIT 许可，并为提供集群和其他生产就绪功能的 InfluxDB Cloud 和 InfluxDB 企业提供付费计划。

文章图片

图片来源：数据库引擎

InfluxDB、TimescaleDB 和 QuestDB比较：在 2019 年 InfluxDB 2.x 发布之前，InfluxDB 平台由 TICK 堆栈组成：Telegraf（收集和报告指标的代理）、InfluxDB、Chronograf（从 InfluxDB 查询数据的接口）和 Kapacitor（实时流数据处理）引擎）。如下图所示，InfluxDB 1.x 主要关注来自服务器和 Web 应用程序的时间序列数据。在 Prometheus 在这个领域占据市场份额之前，InfluxDB 拥有最重要的社区和集成来收集、存储和查看应用程序指标。

文章图片
图片来源：Influxdata
InfluxDB、TimescaleDB 和 QuestDB有什么区别？InfluxDB 2.x 从本质上简化了架构，将 TICK 堆栈绑定到单个二进制文件，并引入了新功能来进行收集（例如原生 Prometheus 插件）、组织（例如，组织和存储桶）和可视化（例如，数据浏览器）数据及其 Flux 语言。
要了解 InfluxDB 的工作原理，我们需要掌握以下关键概念：

数据模型（标签集模型）：除了时间戳字段之外，每个数据元素还包括各种标签（可选的、索引的元数据字段）、字段（键和值）和度量（标签、字段和时间戳的容器）。下面的示例采用蜜蜂和蚂蚁的人口普查数据，由科学家安德森和马伦在克拉马斯和波特兰收集。这里的位置和科学家是标签，属于蜜蜂和蚂蚁的字段/值对的人口普查测量范围。

文章图片
数据模式（TSM & TSI）：是存储在时间结构合并树（TSM）和时间序列索引（TSI）文件中的数据元素。TSM 可以被认为是带有预写日志 (WAL) 和类似于 SSTable 的只读文件的LSM 树，这些文件经过排序和压缩。TSI 是磁盘上文件的索引，InfluxDB 内存映射它以利用操作系统的最近最少使用 (LRU)内存来帮助处理具有高基数的数据集（即集合中的大元素）。
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、TimescaleDB 和 QuestDB比较：总的来说，如果时间序列数据与标签集模型非常吻合，InfluxDB 是一个不错的选择。主要用例似乎面向基础设施/应用程序监控，但作为该领域明显的市场领导者，InfluxDB 还与流行数据源无缝集成。

优点：无模式摄取、庞大的社区、与流行工具的集成。
缺点：具有高基数、自定义查询/处理语言的数据集。

TimescaleDB 详细信息InfluxDB 选择从头开始构建新的数据库和自定义语言，而另一方面是TimescaleDB。TimescaleDB 建立在 PostgreSQL 之上，并添加了一个称为hypertables的中间层，该层将数据分块到多个底层表中，同时将其抽象为单个大表以与数据交互。

文章图片
PostgreSQL 兼容性是 TimescaleDB 最大的卖点。TimescaleDB 完全支持所有 SQL 功能（例如，连接、二级和部分索引）以及流行的扩展，如PostGIS。更重要的是，TimescaleDB 继承了运行 SQL 查询的开发人员以及大规模运行 PostgreSQL 的数据库和系统管理员数十年的知识。由于 TimescaleDB 可以被视为 PostgreSQL 扩展，因此除了TimescaleDB自己的托管产品之外，云托管选项（例如Azure Database for PostgreSQL、Aiven）也很容易获得，更不用说虚拟机或容器上的无数自我管理选项了。

文章图片
图片来源：堆栈溢出
因为 TimescaleDB 是作为一个物联网平台开始的，他们最初使用 InfluxDB 来存储他们的传感器数据，它的特性预示着物联网时间序列数据经常“突发”，由于网络不可靠性而经常失序，并且具有高基数：

Hypertables： TimescaleDB划分其hypertables成块基于时间列以及其他“空间”值，例如一个设备UID，位置标识符，或一个股票符号。用户可以配置这些块以将最新数据保存在内存中，按时间列将数据异步压缩和重新排序到磁盘（而不是摄取时间），以及跨节点以事务方式复制或迁移。
连续聚合： TimescaleDB 还支持数据的连续聚合，可以快速计算小时平均值、最小值和最大值等关键指标。物联网数据在聚合时通常更有用（例如，给我下午 3 点到 4 点之间的平均温度与下午 3 点的确切温度），因此不需要在每个聚合查询中扫描大量数据会有所帮助创建高性能仪表板或分析。
数据保留：在传统关系型数据库中，大量删除是一项代价高昂的操作。但是，由于 TimescaleDB 以块的形式存储数据，因此它提供了一种drop_chunks功能，可以在没有相同开销的情况下快速删除旧数据。由于旧数据的相关性会随着时间的推移而降低，因此 TimescaleDB 可以与长期存储（例如，OLAP 或 Blob 存储）一起使用来移动旧数据以节省磁盘空间并在新数据上保持高性能。

InfluxDB、TimescaleDB 和 QuestDB有什么区别？至于性能，TimescaleDB 有一个全面的文章，详细说明了使用时间序列基准套件(TSBS)比较 TimescaleDB 1.7.1 版和 InfluxDB 1.8.0（两个 OSS 版本）的插入和读取延迟指标。这两个数据库现在都有 2.x 版本，所以这个分析可能有点过时，但结果显示 TimescaleDB 随着数据基数的增长（~3.5x 性能）具有卓越的性能。

文章图片
TimescaleDB 团队指出 InfluxDB 的基于日志结构合并树的系统 (TSI) 与 TimescaleDB 的 B 树索引方法是根本原因。然而，这里的结论并不一定是 TimescaleDB 在性能方面优于 InfluxDB。性能基准测试受数据模型、硬件和配置的影响很大。相反，这个结果表明 TimescaleDB 可能更适合数据基数较高的 IoT 用例（例如，给我 1000 万台设备中设备 X 的平均功耗）。
对于两个 DB 之间的深入比较，请查看 Timescale 自己的TimescaleDB 与 InfluxDB 比较。
总体而言，TimescaleDB 非常适合寻求显着性能提升而无需大量重构以迁移现有 SQL 数据库的团队。尽管 TimescaleDB 仍然相对较新（2017 年首次发布），但在 PostgreSQL 之上构建的决定已经推动其采用数量达到前 5 名。有趣的是，我之前的物联网初创公司也使用 TimescaleDB 作为中间数据存储，以快速提取跨越几个月的聚合指标并将旧数据移至长期存储。由于我们已经在 Kubernetes 集群上运行 PostgreSQL，因此安装 TimescaleDB 和迁移我们的工作负载是一项简单的任务。

优点： PostgreSQL 兼容性，可以很好地扩展数据基数，提供各种部署模型。
缺点：固定模式（在摄取之前增加了一些复杂性和数据转换工作）。

InfluxDB、TimescaleDB 和 QuestDB比较：QuestDB详情对于那些希望利用 InfluxDB 线路协议的灵活性和熟悉的 PostgreSQL 的人来说，较新的时间序列数据库可以在不牺牲性能的情况下满足这两个要求。QuestDB (YC S20) 是一个用 Java 和 C++ 编写的开源 TSDB，虽然它在不到一年前推出，但现在排名前 15 。在幕后，QuestDB 利用内存映射文件在数据提交到磁盘之前支持快速读写。

文章图片
图片来源：QuestDB
通过使用 Java 和 C++ 从头开始??构建数据库，QuestDB 团队专注于三件事：

性能：解决摄取瓶颈，尤其是在高基数数据集周围。它还通过始终按顺序存储时间分区数据（通过内存中的混洗）并仅分析请求的列/分区而不是整个表来支持快速数据检索。最后，QuestDB 应用 SIMD 指令来并行化操作。
兼容性： QuestDB 支持 InfluxDB 线路协议、PostgreSQL 线路、REST API 和 CSV 上传以摄取数据。习惯于其他 TSDB 的用户可以轻松地移植到他们现有的应用程序上，而无需进行大量的重写。
通过 SQL 查询：尽管支持多种摄取机制，但 QuestDB 使用 SQL 作为查询语言，因此无需学习 Flux 之类的特定领域语言。

时间序列数据库比较：在性能方面，QuestDB最近发布了一篇博客文章，展示了实现高达每秒 140 万行的写入速度的基准测试结果。QuestDB 团队在cpu-only用例中使用了TSBS 基准测试，m5.8xlarge在 AWS上的实例上使用了多达 14 个作品（注意： 140 万个数字来自使用 AMD Ryzen5 处理器）。

文章图片
对于具有高基数（> 1000 万）的数据集，QuestDB 的性能也优于其他 TSDB，峰值摄取吞吐量为 904k 行/秒，并在 1000 万台设备上使用四个线程在m5.8xlargeIntel Xeon CPU 实例上维持约 640k 行/秒。当 QuestDB 在 AMD Ryzen 3970X 上运行相同的基准测试时，QuestDB 显示超过一百万行/秒的摄取吞吐量。

文章图片
同样，基于数据模型和 DB 调整的性能基准测试可能是主观的，但它仍然为 QuestDB 描绘了一个引人注目的比较点。看看结果如何在 DevOps 或 IoT 模式下发生变化将会很有趣，因为 InfluxDB 和 TimescaleDB 都支持 TSBS 开箱即用的这些用例。
QuestDB 的另一个有趣的组件是支持 InfluxDB 内联协议和 PostgreSQL 线路以进行摄取。对于现有的 InfluxDB 用户，你可以将 Telegraf 配置为指向 QuestDB 的地址和端口。同样，PostgreSQL 用户使用现有的客户端库或 JDBC 将数据写入 QuestDB。无论采用何种摄取方法，都可以使用标准 SQL 查询数据，但 API 参考页面上列出了显着的例外情况。
InfluxDB、TimescaleDB 和 QuestDB有什么区别？作为这个领域的新进入者，QuestDB 最明显的缺点是缺乏对生产就绪功能的支持（例如，复制、备份/恢复）。它已经与一些最流行的工具（例如 PostgreSQL、Grafana、Kafka、Telegraf、Tableau）集成，但它需要一些时间才能达到上述其他 TSDB 的水平。
尽管如此，QuestDB 是一个很有前途的项目，可以平衡 InfluxDB 和 TimescaleDB 的优点：

优点：快速摄取（特别是对于具有高基数的数据集），支持 InfluxDB 协议和 PostgreSQL 线路，通过标准 SQL 查询。
缺点：较小的社区、可用的集成、生产就绪。

时间序列数据库比较结论随着对时间序列数据的需求不断增长，专门处理这些数据的 TSDB 将被大规模采用和激烈的竞争。除了本文介绍的三个开源 TSDB，还有来自 AWS（AWS Timestream）和 Azure（Azure Series Insights）的公共云产品。
【比较 InfluxDB、TimescaleDB 和 QuestDB 时间序列数据库】InfluxDB、TimescaleDB 和 QuestDB比较：与所有数据库一样，选择“完美”的 TSDB 主要取决于你的业务需求、数据模型和用例。如果你的数据适合具有丰富的集成生态系统的标记集模型，则 InfluxDB 运行良好。TimescaleDB 非常适合现有的 PostgreSQL 用户。最后，如果性能是首要考虑因素，QuestDB 是一个发展迅速的有前途的项目。