GreptimeDB v0.9.1 已经发布，本次小版本修复了全文索引中部分行遗漏和数据摄取因通知无故停止的问题，欢迎具有测试日志需求的用户升级。

随着网络科技的进步，计算资源变得更加强大且便宜，助力了物联网生态系统的蓬勃发展。从家用测温仪到个人心率探测设备，家用物联网设备和服务正渗透到人们日常生活的方方面面。与支持云基础设施的强大服务器相比，这类物联网设备仅被设计用于完成单一任务，通常运行在相对受限的环境中。

测量数据本身并不能提供有效价值，基于这些数据帮助我们进行行为决策才更有意义。例如，当你的心率变异性超过某个阈值时，手机会收到呼吸提醒；当房间过热时会自动启动中央冷却系统；当传感器检测到生产线速度变化时会自动调整工厂车间的机械设置，以保持最佳效率并防止停机。

要点：这些联网设备通常需要一个重要的基础设施来存储应用程序的状态，并为处理这些 Metric 提供一个共同的中转站，即数据库。

简单的家庭自动化场景

例如：智能照明，自动植物浇灌

家居自动化已经成为物联网设备最常见的落地场景之一，相关产品络绎不绝，帮助用户管理家庭照明、暖通空调、安全系统等。技术爱好者也可以选择购买一套智能开关或传感器，将它们连接到 Pi 开启的物联网网关上，根据自己的具体使用需求进行定制。

要点：在简单的家庭自动化案例中，因为设备数量多且每个设备的写入数据量少，物联网网关通常需要一个统一的数据库来存储网络上所有不同设备的配置信息。

在该场景下选择数据库需考虑以下因素：

• 轻量级且资源利用效率高：数据库应该是轻量级的，以确保不会过多消耗物联网网关的有限资源（CPU、内存、存储）。

• 持久性和可靠性：数据库必须可靠，确保即使在断电或意外关闭的情况下也能确保数据的完整性。

• 低维护需求：数据库应要求最少的维护和管理，适合没有技术专业知识的家庭用户。

• 低性能要求：鉴于网络规模小和传感器输入有限，可以在性能上做出妥协（不用大材小用）。

SQLite：无处不在的嵌入式数据库

使用范围最广的通用关系数据库之一

👉 成立于 2000 年

🌝 开源

SQLite 通过零依赖的 C 语言实现了简洁性。它不运行自己的数据库服务器，而是直接嵌入应用程序的运行过程中，将所有应用数据读写到单个文件中。凭借全面的 ACID 合规性和事务支持，SQLite 具有数据库管理系统所需的所有功能，而且无需配置，只需运行即可。

要点：SQLite 的占用空间小于 1MB，并且在 Raspberry Pi 硬件[1] 上的 tsbs 测试结果为 600-700 TPS，使这个轻量级、久经考验的数据库几乎能够处理所有简单的家庭自动化使用场景。

经过 20 多年的发展，SQLite 在开源社区中拥有大量可用的资源和集成。以集成了 SQLite 的 Home-Assistant 框架[2] 为例，该框架与许多流行的物联网设备集成，以满足大多数家庭自动化需求。虽然 SQLite 在其预期用途上表现出色，但作者在设计时还没有考虑到越来越多的前沿应用越来越高的需求。

要点：对于需要亚秒级粒度并能够同时捕获多个传感器事件的高性能物联网应用，SQLite 可能无法胜任。

这些资源需求通常超出了简单的家庭自动化场景，进入了更高级的商业应用，如智能制造、远程患者监护和自动驾驶系统。这些系统要求每几毫秒捕获几个数据流，且会迅速扩展到每秒数千或数百万个事务的数据量。那么，对于这些高性能物联网应用，有哪些好的数据库选项呢？

高吞吐的工业物联网应用

华为 ADS 2.0 系统采用了 27 个传感器（1 个激光雷达、3 个毫米波雷达、12 个超声波雷达和多个摄像头）[2]，以满足在最少人工干预的情况下运行汽车中高度资源密集型任务的要求。

要点：捕获工业物联网（IIoT）数据流可能具有高度的时间敏感性，而且成本高昂。在采集大量数据的过程中，延迟可能会导致本该在车流中平稳行驶的 5,000 磅重的车辆出现事故，最终面临昂贵的保险理赔。

当比较执行这些工作流程的所使用的不同芯片时，简单家庭自动化项目和工业物联网项目对性能的需求有着更显著的差异。例如，Google Nest 智能家居中心与用于自动驾驶的 Tesla FSD 硬件 3.0 的差异如下：

Tesla 硬件芯片的内存是前者（普通芯片）的 4 倍，CPU 并行化能力是前者的 6 倍，功耗超过前者的 5 倍[3][4]。很显然，用于自动驾驶汽车的芯片比用于开灯和播放音乐的芯片需要更高的性能。那么，随着物联网行业对数据存储处理的性能需求越来越高，数据库又有哪些演变呢？

时序数据库（TSDB）

在所有的这些高吞吐量应用场景中，一个共同特征直接决定了这一类数据库的设计决策。当平台或者设备开始围绕时间轴收集信息时，时序数据库就产生了。

要点：通过强制记录包含时间戳的组件，TSDB 系统可以稳定可靠地沿着这个维度进行索引和分区，从而提高基于时间尺度存储和查询数据的效率和速度。

如上所述，物联网应用的现代商业需求与蓬勃发展的云基础设施行业相结合后，促进了这些时序数据库的普及。以下是行业中的一些大玩家：

InfluxDB：市场领导者

最知名的 TSDB，但有限的支持和不断变化的 API 引发了开发者的挫败感。

👉 成立于 2012 年

🌟 GitHub Star：28.1k

🌗 部分开源

要点：InfluxDB 是迄今为止 TSDB 领域中最知名和最成熟的厂商[5]。

InfluxDB 是第一个提供每秒写入数百万记录数据库服务的厂商，也因此在市场上具有深厚的积淀和主导地位。不幸的是，InfluxDB 的产品状态跟它的名字如出一辙——Influx。去年 4 月开始，InfluxDB 在努力把用户迁移到全新的 3.0 版本中遇到了困难，该版本重构了 API。

尽管其全新架构在存储成本和查询性能方面取得了巨大进步，但有一个问题的存在严重阻碍了许多工程师在新的物联网项目中使用 InfluxDB ——缺乏可以部署到物联网设备上的独立二进制文件。

要点：如果你想使用最新、最好的 InfluxDB 版本，则需要通过其托管实例来实现[6]。

网上可以找到 InfluxDB 团队成员一直推迟开源版发布日期的讨论，原因是许多内部开发者在时间紧迫的情况下一直摇摆不定：是投资 EOL（End of Life） 产品 1.8，还是寻找该领域中能够满足相同需求的其他数据库。

TimescaleDB：冉冉升起的新星

通过不断改进其产品更新路线图将 PostgreSQL 扩展到了新的高度，虽然目前还缺乏分布式架构支持可能会限制横向扩展。

👉 成立于 2015 年

🌟 GitHub Star：16.8k

🌝 开源

TimescaleDB 的诞生实际上源于公司在使用 InfluxDB 时遇到了路线图频繁变更以及缺乏产品核心关注点等问题[7]。因此 TimescaleDB 的设计中更关注简化性和契合度。

要点：TimescaleDB 作为 PostgreSQL 扩展运行，利用了 PostgreSQL 成熟技术为基础。

与所有的 TSDB 一样，TimescaleDB 要求在所有插入记录都包含时间戳，然后自动将数据组织并存储为时间间隔块。TimescaleDB 使用一种巧妙、透明的技术，将数据行自动压缩成列格式，从而大幅提高查询性能并降低存储成本[8]。TimescaleDB 的查询性能非常强：在我的 M1 Mac 上运行 tsbs 时，从 100 万行数据集中返回行的时间不到 1 毫秒（准确来说约为 0.3 毫秒）[9]。这就是业内人士通常所说的“快到飞起”。

要点：虽然 TimescaleDB 实例明显体现了其强大的性能，但我很好奇 TimescaleDB 在真正大规模操作中能扩展到什么程度。2023 年底，为了降低复杂性并优化单节点功能的开发能力，TimescaleDB 弃用了多节点分布式功能。

TimescaleDB 声称，他们已将单节点部署扩展到每秒 200 万次插入，他们认为这对单个节点来说已经足够了[10]。大概在同一时间，TimescaleDB 开始提供分层存储，将较新的、访问频率较高的数据保存在 “热 ”高性能存储中，将访问频率较低的较旧数据保存在冷对象存储中。该团队声称，这种自动的数据分类为开发人员提供了两全其美的方法，即把较旧的数据存储在较便宜的对象存储中以降低成本，同时在其他需要的地方优先考虑性能。

但是，如果部署需要横向扩展节点，或者控制器与代理之间存在自然的分级关系，控制器必须使用代理的所有 Metric 才能做出决策，这种情况又该如何处理呢？要支持城市交通基础设施、车队或能源网管理等领域常见的大规模实施，需要进行大量的定制开发，以可靠和可用的方式将所有代理集中起来。这些场景自然符合集群部署的分级关系，但 TimescaleDB 不再支持这种关系。

GreptimeDB：提供统一的可扩展性

通过解耦但统一的能力开发具有创新性的高性能架构

👉 成立于 2022 年

🌟 Stars on Github： 4k

🌝 开源

GreptimeDB 为 TSDB 领域带来了全新的视角和设计。尽管这是一个相对较新的代码库，但它已经吸引了众多业内人士的关注，GitHub 上 4k Star 就是很好的证明。GreptimeDB 的 tsbs 结果显示能够跻身性能最高的 TSDB 之列。

要点：GreptimeDB 的突出特点之一是写入性能，我个人进行的 tsbs 结果显示，它的写入性能甚至比 TimescaleDB 高出约 20%[9:1]。

该性能优势使 GreptimeDB 成为物联网环境中高吞吐量场景需求用户的一个有力方案，尤其是它的创新架构还能够将三种不同的节点类型集成到同一个模型中。

这个由 MetaSrv、Frontend 和 DataNode 组成的三节点系统通过解耦不同基础设施组件的扩展，解决了 TimescaleDB 的一些关键缺陷[11]。

(GreptimeDB 解耦架构）

• MetaSrv（元数据服务）： 该节点负责管理元数据并协调集群。通过将元数据操作隔离开来，GreptimeDB 确保即使在数据量和查询负载增加的情况下，元数据处理也不会成为该数据库中的瓶颈。

• Frontend： 此节点处理客户端请求和查询处理。通过将前端与数据存储解耦，GreptimeDB 允许查询处理能力独立扩展。这种分离确保了即使在高查询负载下，查询性能依然保持高效。

• Datanode： 该组件负责管理从后台对象存储中存储和检索数据。GreptimeDB 可以扩展存储数据所需的存储空间，而不依赖于管理这些数据所需的计算能力。这样资源有限的小型设备就能够存储海量数据集。

GreptimeDB 的架构有助于克服 TimescaleDB 面临的潜在限制，特别是在需要水平扩展和分层部署结构的场景中。

这种解耦设计确保每个组件可以根据其特定需求进行扩展，使其适用于复杂的实现，如城市交通基础设施管理、车队监控和能源网管理。在这些使用案例中，可以有效管理控制器与代理之间的层次关系，从而提供可靠且可扩展的解决方案，无需进行大量的定制开发。然而，作为一个新兴且迅速发展的数据库，GreptimeDB 可能在提供开发者支持渠道方面还是面临挑战。

GreptimeDB 的架构通过解耦这些不同的组件来减轻瓶颈问题，但是其专门设计的架构可以适应目前许多物联网部署过程中面临的通用场景，尤其是：如何 Metric 和 Log 统一到一个数据库中的需求。

（GreptimeDB 的统一性）

GreptimeDB 提供了易于配置的工具，可将 Log 在写入时整理成与 Metric 相同的通用事件接口。GreptimeDB 通过确保所有的事件数据（可以包含时间戳、系统负载和上下文），并依赖引擎将写入的数据转换为所需事件接口来实现这一点。通过 GreptimeDB 的巧妙设计，一切都被视为事件。无论是应用 log 中的非结构化文本，还是系统进程负载的具体数值，用户都可以根据自己的需求轻松配置所有相关事件的写入，并在下游实现无缝查询和数据整理。

要点：GreptimeDB 作为一个统一的泛时序数据库可以直接支持常见的通用物联网使用场景。

总结

为物联网应用选择合适的数据库取决于具体的需求和限制因素。简要概述为：

• SQLite：适用于资源需求较低的简单家庭自动化场景。它轻便、可靠且易于维护，但不适合高性能或大规模应用。

• InfluxDB：在时序数据库市场中占主要地位，具有强大的读取和查询性能。然而，频繁的 API 更改和其最新版本缺乏独立二进制文件可能对某些物联网用户的部署造成困扰。

• TimescaleDB：基于 PostgreSQL 构建，提供出色的查询性能和压缩能力。最近取消了对多节点的支持，限制了其可扩展性，可能使其不太适合大规模的物联网项目。

• GreptimeDB：新兴产品，具有灵活、可扩展的架构，解耦元数据管理、查询处理和数据存储三部分。这种设计使其能够适应复杂、高吞吐量的物联网应用，但可能缺乏成熟数据库所拥有的支持渠道。

要点：每种数据库都有其独特的优势，最佳的选型方案取决于将数据库特性与用户具体的物联网项目需求是否对齐。

Reference

[1] Robust SQLite benchmarks by University of Wisconsin Researchers: https://www.vldb.org/pvldb/vol15/p3535-gaffney.pdf ↩︎

[2] Home-Assistant 框架：https://www.home-assistant.io/

[3] Paul Tan, Trusted Automotive News Source based out of Malaysia: https://paultan.org/2023/12/28/huawei-aito-m9-launched-in-china

[4] Tear Down of Google Nest Hub Hardware: https://electronics360.globalspec.com/article/17053/teardown-google-nest-hub-2nd-gen

[5] DB Engines Interest rankings based on social media mentions, Google Trends, and job postings: https://db-engines.com/en/ranking/time+series+dbms

[6] InfluxDB Pushes back on Fall 2024 launch of Community Edition: https://community.influxdata.com/t/influxdb-3-0-release-timeline/31845/9

[7] TimescaleDB blog on InfluxDB’s failures: https://www.timescale.com/blog/what-influxdb-got-wrong/ ↩︎

[8] TimescaleDB Architecture and design: https://github.com/timescale/docs.timescale.com-content/blob/master/introduction/architecture.md

[9] Repositories used to execute TimescaleDB and GreptimeDB Benchmarks. All benchmarks were run on 2021 Apple M1 Pro 10x 2.06 GHz - 3.22 GHz; 32GB Ram Timescale (v 2.15.2) and GreptimeDB (v0.9). Results as below: (Bench Source https://github.com/timescale/tsbs and https://github.com/GreptimeTeam/tsbs)

[10] Timescale announces the deprecation of multi node support as of 2.13: https://github.com/timescale/timescaledb/blob/main/docs/MultiNodeDeprecation.md

[11] GreptimeDB discussion on scaling multi node support: https://docs.greptime.com/contributor-guide/overview

关于 Greptime

Greptime 格睿科技专注于为可观测、物联网及车联网等领域提供实时、高效的数据存储和分析服务，帮助客户挖掘数据的深层价值。目前基于云原生的时序数据库 GreptimeDB 已经衍生出多款适合不同用户的解决方案，更多信息或 demo 展示请联系下方小助手（微信号：greptime）。 欢迎对开源感兴趣的朋友们参与贡献和讨论，从带有 good first issue 标签的 issue 开始你的开源之旅吧～期待在开源社群里遇见你！添加小助手微信即可加入“技术交流群”与志同道合的朋友们面对面交流哦~Star us on GitHub Now: https://github.com/GreptimeTeam/greptimedb 官网：https://greptime.cn/ 文档：https://docs.greptime.cn/ Twitter: https://twitter.com/Greptime Slack: https://greptime.com/slack LinkedIn: https://www.linkedin.com/company/greptime/