0 序

调研声明

调研日期 ：2026-10-09（GitHub Star 数、版本号均以该时点为准，检索最新公开资料）

调研方式 ：人工（笔者有持续多年使用了多款时序数据库的背景） + AI

证据口径说明：

【已查证】：事实来自官方文档 / 官方 GitHub / 官方发布公告 / 官方 API（如 GitHub REST API、官方 Release Notes），可追溯复核；

【一方称】：厂商官网宣传、厂商博客、厂商自测基准，未经第三方独立验证；

每个 GitHub Star 数均注明抓取日期与信源 URL；闭源产品（kdb+、DolphinDB）标注 "--"（无公开源码仓库）；

所有性能数字（写入吞吐 / 压缩比 / 查询延迟）均标注"官方自测基准 / 第三方评测"口径；无出处的数字一律未收录；

未检索到的信息如实标注"截至 2026-10 未查到公开数据"，不使用模型记忆顶替。

方法说明：本报告按软件调研规范（单项目深度调研 + 多软件横向对比）产出。第 3 章每个数据库独立成节，统一包含：产品介绍 / 发展历程 / 基本信息卡 / 主要功能 / 核心优势 / 主要短板 / 潜在风险与局限性 / 适用场景 / 同类竞品 / 发展趋势 / 工作原理与核心架构（含 mermaid 架构图）/ 写入与查询性能特点 / 支持的部署方式 / 重要依赖 / 生态与集成 / 使用指南 / FAQ / 推荐文献 / 参考文献。

调研思路：#1 主流数据库榜单 & 横向对比总表 → #2 定位图谱 → #3 单库深度调研 → #4 核心问题（时序库与关系型/OLAP 的本质区别与核心优势）。

核心问题：时序数据库与关系型数据库 / OLAP 的本质区别与核心优势

总结

时序数据库与关系型数据库（RDBMS）、OLAP（如 ClickHouse / 传统数仓）都是"围绕特定数据工作负载做专业化设计 "的产物。它们的本质区别不在"谁能存时间戳"，而在于数据模型、写入模式、数据生命周期、查询范式、存储引擎、扩展模型六件事上的系统性取舍：

RDBMS 是"事务与关系完整性"的通用机------面向任意结构化数据的随机读写与强一致；

OLAP 是"大规模多维分析"的扫描机------面向超大数据量的全量聚合扫描；

TSDB 是"按时间追加、按时间老化、按时间查询"的专用机------面向持续高频产生的时序数据流。

三者重叠但不互相替代。

开始逐维度论证（每个结论均附 8 款数据库中的实例与口径标注）。

本质区别：六个维度的对比

数据模型：序列是"一等公民"，而不是"带时间戳的行"

维度	时序数据库（TSDB）	关系型数据库（RDBMS）	OLAP（ClickHouse / 数仓）
组织单位	时间序列（Time Series）（指标 + 标签/维度 + 时间戳 + 值），一条序列 = 一条连续时间线	关系/表（行 × 列），主键/外键约束	宽表 / 星型模型（维度 + 事实）
物理组织	按序列连续存储（列式/时间有序），标签建索引	以行为主（行存），二级索引	按列存储，面向扫描
模式约束	宽松或模板化（无模式 / 超级表 / 树模型）	强 schema + 约束	宽表 schema

实证（8 库）：

TDengine 超级表 + 一设备一子表 ：每个具体设备自动创建一张物理隔离的子表，标签（tags）作为静态元数据建立索引------关系库若要支撑"千万设备 × 高频采样"会在单表上产生灾难性的索引膨胀与写放大，TDengine 在物理层就把时间线分片了。【已查证，TDengine 架构文档】
InfluxDB measurement + tag set ：<measurement>,<tags> <fields> <ts> 唯一确定一条序列；Field 不建索引、Tag 建索引，是"序列(series)优先 "的典型建模。【已查证，InfluxDB 数据模型文档】
kdb+ ：内存中每列就是一个向量（列存），表是一组对齐向量------向量是 q 语言的一等公民，直接支撑金融 tick 分析。【已查证，code.kx.com】
Prometheus ：<metric name>{label1=v1,label2=v2} 唯一确定一条时序，多维标签模型是其查询（PromQL）的基石。【已查证，Prometheus 官方文档】
结论：
- RDBMS 面向"实体及其关系 "，TSDB 面向"一个【测量对象】随时间的变化"。
- 同一份传感器数据，关系库会建 (device_id, ts, value) 单表靠索引查询；时序库则在物理层按序列组织，使连续扫描、时间压缩、窗口聚合天然高效。

写入模式：append-only 顺序写 vs 随机写 / 批量导入

维度	TSDB	RDBMS	OLAP
写入方向	append-only（按时间追加，落盘数据基本不可原地修改）	随机写 + 更新/删除	批量分区导入，不适合高频点写
并发模型	批量写入协议、无事务（或轻事务）	事务 + 行锁 + MVCC	大批量 COPY/分区替换
乱序处理	原生容忍（按时间戳排序，Compaction 归并）	无此概念（按插入顺序生效）	有限支持

实证（8 库）：

InfluxDB Line Protocol ：measurement,tags fields ts 单行文本批量 push，无事务、无索引更新开销，专为高吞吐写入设计。【已查证，官方写入协议文档】
Prometheus ：pull 采集后样本 append 进内存 head block，一旦落盘为 block 即不可修改 ，retention 到期整块删除------完全没有 UPDATE/DELETE 的概念，与 RDBMS 行级更新模型根本不同。【已查证，官方 storage 文档】
IoTDB / TDengine ：原生支持设备时钟不同步带来的乱序写入 ，数据按时间戳而非到达顺序组织，由后台 Compaction 归并。【已查证，IoTDB 产品介绍 / TDengine WAL 文档】
DolphinDB 双引擎 ：其 TSDB 引擎基于 LSM 树，专门支撑高频小批量、乱序、更新删除；而同一产品的 OLAP 纯列存引擎批量写入才高效------一个产品内部都能看出"时序写入"与"OLAP 批量导入"的路径分野 。【已查证，DolphinDB TSDB 引擎文档】

关键机制：TSDB 的写入优化与 OLAP 完全不同------OLAP 面向"隔一段时间灌一批大文件"，TSDB 面向"持续不断的细粒度追加"。LSM 树把随机写变成顺序写（先内存表 + WAL，后台批量落盘），加上批量协议与无事务开销，换来的是千万点/秒级写入吞吐（见 4.2）。

数据生命周期：数据"会死"是设计前提，降采样是原生能力

维度	TSDB	RDBMS	OLAP
保留策略	TTL / 保留策略（RP）/ 多级 KEEP 原生	无原语，需定时任务 DELETE（产生 WAL/VACUUM 放大）	分区管理 + TTL（ClickHouse 具备，非通用）
降采样	连续聚合 / CQ / Stream / RSMA 原生	物化视图 + 调度系统自建	离线 ETL / 物化
冷热分层	多级存储自动迁移	手动归档	分层存储

实证（8 库）：

openGemini ：CREATE DATABASE monitor WITH DURATION 30d 一条语句即建库并设置 30 天自动过期------TTL 是 schema 的原生属性，而非应用层的定时任务。【已查证，openGemini 官方文档】
TDengine ：KEEP keep0,keep1,keep2 配置三级保留时长，数据向高存储层级迁移时自动触发降采样物化（RSMA） ，无需外部调度 。【已查证，TDengine RSMA 文档】
TimescaleDB ：add_retention_policy('metrics', INTERVAL '30 days') 一条 SQL 自动 drop 旧 chunk；连续聚合物化视图声明式增量刷新------降采样是 SQL 声明，不是离线 ETL 脚本。【已查证，官方文档】
InfluxDB：Retention Policy + 连续查询/任务实现"原始数据 7 天、1 小时聚合 30 天、1 天聚合 1 年"式的多级降采样链路。【已查证，官方文档】
Prometheus ：retention 到期按 2 小时 block 为单位整块删除，无行级删除概念。【已查证，官方 storage 文档】

结论：这是 TSDB 与 RDBMS 最本质的立场差异------关系模型把数据当作需要永久维护的资产，时序模型把数据当作"有保质期的流"，TTL 与降采样内建为第一方能力，运维成本从"人工清理 + 物化调度"降为"声明式配置"。

查询范式：时间是查询语言的一等公民

维度	TSDB	RDBMS	OLAP
时间窗口聚合	一等公民（`GROUP BY time()` / `time_bucket` / 窗口）	需手工 `date_trunc + GROUP BY` 拼凑	支持但非专用优化
连续聚合/预聚合	原生（CQ / 连续聚合 / recording rules）	物化视图（增量刷新成本高）	物化 / 预聚合
插值/对齐/前值	原生（FILL / INTERP / gapfill / as-of join）	需自连接 + LATERAL 等复杂实现	有限支持
关联分析	弱（多为单序列窗口聚合）	强（任意 JOIN / 事务 / 子查询）	强（大规模多维分析）

实证（8 库）：

IoTDB ：SIGMOD'23 论文给出 3 年千万点聚合查询 100ms 内完成 ；GROUP BY 时间窗口 + FILL(PREVIOUS/LINEAR) 插值 + ALIGN BY TIME/DEVICE 对齐是原生算子。【已查证，SIGMOD 论文 PDF】
TDengine ：SELECT INTERP(current) ... FILL(LINEAR) 在 SQL 层直接完成时间截面插值与等间隔对齐------关系库需要应用层自行补点。【已查证，TDengine 函数文档】
kdb+ ：aj/wj（as-of join / window join）是金融行业的区间对齐标配，回答"上一时刻这只股票的价格是多少"这类问题------关系 SQL 没有"as-of"原语，只能靠窗口自连接且难以优化。【已查证，code.kx.com】
Prometheus ：PromQL 的 rate()、histogram_quantile() 与 recording rules 预计算，是"监控查询"这一时序子类的标杆。【已查证，官方文档】
TimescaleDB ：连续聚合物化视图增量刷新 + time_bucket，把降采样声明为 SQL 对象。【已查证，官方文档】

结论：TSDB 把"时间窗口、对齐、前值、变化率"做成原生算子并针对时间索引优化执行；RDBMS 用通用 SQL 拼凑同样语义，性能与表达力都不占优；OLAP 强在"扫全量做多维聚合"，弱在点查与近实时语义。

存储引擎与压缩：B+Tree 行存 vs LSM/列存 + 时序专用编码

维度	TSDB	RDBMS	OLAP
引擎	LSM-Tree / 列式 / 内存列存，时间索引 + 序列索引（TSID）+ 标签倒排	B+Tree 行存（页压缩）	列存 + 向量化执行（或结合 LSM-Tree）
压缩	时序专用编码：增量（delta）、Gorilla/XOR、字典、RLE	通用行压缩（压缩比低）	列压缩（高）
高基数（序列数量爆炸）	序列索引/倒排/标签分桶，是设计焦点	索引膨胀问题，无"序列"概念	字典编码可应对，但非时序专用

实证（8 库）：

IoTDB TsFile ：列式编码 + 多级压缩，官方生态口径无损压缩 10~15 倍 （Timecho 称 12:1 vs InfluxDB 3:1）。【一方称，Timecho】
TDengine ：官方 TSBS 自测压缩比 9.89:1 ~ 87.64:1 （对比 InfluxDB 3.39:1 ~ 7.44:1）。【官方自测基准，一方称，TDengine TSBS 对比】
Prometheus：Gorilla/XOR 浮点编码使单样本远小于行存储；WAL 压缩后体积约减半（CPU 开销极小）。【已查证，官方 storage 文档】
TimescaleDB ：历史 chunk 自动转列存，RLE/delta/Gorilla 组合压缩，官方称节省 80%~95% 空间；但 2026 年 MSST 学术论文指出 chunk 过小时压缩反而可能多占 54% 存储 ------压缩是调优收益，不是无条件收益。【一方称官方页面 + 已查证 MSST'26 论文】
DolphinDB ：官方称金融行情压缩比 ≥10:1 ，存储成本降约 80%。【一方称，dolphindb.cn 金融方案页】

⚠️ 口径提醒：以上压缩比/性能数字除标注【已查证】外，均为厂商自测或宣传口径，目前没有统一第三方基准横评全部 8 款产品。引用时应区分证据强度（本报告已在各单库章节标注）。

扩展性/一致性/部署模型

维度	TSDB	RDBMS	OLAP
扩展模型	分片（时间 + 序列 hash）+ 多副本；部分产品单机 + 联邦生态	主从 / 分库分表，强一致优先	MPP 无共享，扩展优先
一致性	多数派（Raft）或最终一致为主	强一致（ACID 事务）	副本异步为主
部署	云原生（K8s/Helm）普遍，二进制 + Docker	成熟（云托管普遍）	成熟（MPP 集群）

实证（8 库）：

openGemini ：ts-sql（无状态入口）+ ts-meta（元数据）+ ts-store（存储）三层 MPP，各层独立水平扩展，支持 100+ 节点。【已查证，官方集群架构文档】
IoTDB：ConfigNode（Ratis 共识、奇数节点）与 DataNode 分离，Region 按"库 + 时间区间 + 副本"切分。【已查证，官方文档】
TDengine ：VGroup 基于 Raft 组成副本组，写入走 Leader，Qnode 与 Dnode 存算分离。【已查证，TDengine 分布式架构】
Prometheus ：原生无集群------单实例本地存储；高可用与长期化靠 remote write 到 Thanos/Mimir/VictoriaMetrics 或 federation 分层。这反映了"单机内核 + 生态扩展"的监控路线。【已查证，官方文档】
kdb+ ：无透明分布式，靠 tick 架构（多 TP 镜像、多 HDB 分片）手工拼装。【已查证，code.kx.com】
趋势：存算分离 + 对象存储成为共性方向------InfluxDB 3.x（Parquet + 对象存储）、TDengine 3.0（云原生）、openGemini（存算分离演进中）。

核心优势：写吞吐 × 压缩 × 实时查询 × 生命周期自动化

优势	机制	8 库实证（口径）
写入吞吐	无事务开销 + 顺序写 + 批量协议 + LSM	IoTDB 千万级点/秒【官方口径】；TDengine 写入为 InfluxDB 的 3.0~10.6 倍【官方 TSBS 自测】；DolphinDB 4 节点约 1,450 万条/秒（1.25 GB/s）【官方自测】；openGemini 官方称千万级写入、40+ 节点集群 10GB/s 流量【一方称】
存储成本	时序专用编码（delta/Gorilla/字典/RLE）+ 列式	IoTDB 10~15 倍【一方称】；TDengine 9.89~87.64:1【官方自测】；TimescaleDB 80~95%【一方称】；DolphinDB ≥10:1【一方称】
查询延迟	时间索引跳过 + 预聚合 + 列存	IoTDB SIGMOD'23：千万点聚合 100ms【已查证论文】；kdb+ 内存列存多年历史聚合秒级【厂商口碑，一方称】；TimescaleDB 历史聚合较原生 PG 最高约 1000 倍【一方称】
生命周期自动化	TTL / 降采样 / 连续聚合原生	openGemini `WITH DURATION`、TDengine `KEEP`+RSMA、InfluxDB RP+CQ、TimescaleDB 保留策略+连续聚合（详见 4.1.3）
运维模型	单二进制 / 云原生 K8s	Prometheus 单二进制；openGemini / TDengine / IoTDB 提供 K8s/Helm 部署
生态集成	监控/物联网栈深度绑定	Prometheus+CNCF+Grafana 事实标准；InfluxDB+Telegraf（400+ 插件）；IoTDB 与 Flink/Spark 打通；TDengine 对接 Kafka/Flink/Grafana

注：写入吞吐与压缩比数值均为厂商自测或宣传口径（除标注【已查证】者），本报告不将其当作可横向比较的独立事实------横向比较请以第三方基准为准。

适用边界：什么时候不要用时序数据库

需要事务、复杂多表关联、任意即席查询的业务系统 → 用 RDBMS。TSDB 的查询能力集中在"单序列/多序列的时间窗口分析"，业务级 JOIN 不是其设计目标（TimescaleDB 是唯一的桥------PG 扩展形态，可同时承担两类负载）。
无强时间语义的海量多维分析（用户画像、经营分析、超大规模明细扫描）→ 用 OLAP（ClickHouse / 数仓）。时序库的列存与时间索引在这里没有优势，OLAP 的向量化扫描与维度建模更强。
数据根本没有时间维度 → 任何 TSDB 都不合适。
反例 1：用 Prometheus 长期留存业务明细。其本地存储定位短期监控（默认 retention 15 天），单机不原生扩展，且官方反复警告 label 高基数会打爆内存与索引------这是"拿专用件干通用活"的典型反面教材。【已查证，官方文档】
反例 2：用 IoTDB / TDengine 存订单、用户等实体数据。其模型面向"测点/设备"，复杂 JOIN 与事务非强项，建模会非常别扭。【已查证，官方定位】
反例 3：全文检索场景选 TSDB。时序库本不擅长全文检索（openGemini 直到 v1.1.0 才引入全文索引），日志检索应选 ES/Loki 类产品。

选型建议：场景 → 推荐

场景	推荐	核心理由
云原生监控/可观测（K8s/微服务）	Prometheus + Thanos/Mimir/VictoriaMetrics	指标事实标准，生态最成熟
工业物联网 / 能源 / 车联网（国产化）	TDengine 或 Apache IoTDB	集群 + 高压缩 + 中文生态；TDengine 偏标准 SQL，IoTDB 偏端边云一体
已有 InfluxDB 技术栈、需水平扩展	openGemini（或 InfluxDB Enterprise）	Line Protocol/InfluxQL 无缝兼容
多模型指标 + 事件 + 数据湖一体化	InfluxDB 3.x	Parquet 开放格式 + 对象存储，与数据湖打通
已有 PostgreSQL 栈、业务+时序同库	TimescaleDB	100% PG 兼容，事务/JOIN 与时序并存
金融 tick / 实时风控 / 高频回测	kdb+（外资机构）/ DolphinDB（国产替代）	内存列存 + 向量计算 + 库内因子
超大规模可观测性（亿级时间线）	openGemini / TDengine / InfluxDB Enterprise	MPP/集群扩展能力

再次总结

本质：时序数据库把"时间"变成数据模型与查询语言的一等公民，围绕追加写入、时间索引、生命周期老化 做整套专用设计，从而在写入吞吐 × 压缩比 × 时间窗口查询延迟的组合上全面超越"拿关系库/OLAP 硬扛时序负载"的方案。
代价：它牺牲了事务、通用关联分析与复杂多维分析能力；数据规模再大、时间语义再弱，都不该选 TSDB。
边界：RDBMS、OLAP、TSDB 是互补的三类工具------业务数据进关系库，分析数据进 OLAP，时序数据进 TSDB；TimescaleDB 是前两者的桥梁，Prometheus 是时序库在监控子类的"专用件"。

摘要：主流的时序数据库

一、流行度与市占率

DB-Engines 时序榜单 + Github社区（Star/Commit活跃度等）
公开最常用是 DB-Engines 时序榜 ，但它是流行度（搜索、招聘、社区、文档、讨论量），不是营收份额、也不是生产部署量。2026-10 官方时序榜前排大概：

https://db-engines.com/en/ranking/time+series+dbms

InfluxDB 21.22

DB-Engines 时序榜: 持续多年的 TSDB 扛把子。

Prometheus 9.72

DB-Engines 时序榜: 与 Kdb 争老二，从 2025.10 的第 3 名已上升到 2026.10 的第 2 名。

Kdb 7.84

DB-Engines 时序榜: 与 Prometheus 争老二，从 2025.10 的第 2 名已下降到 2026.10 的第 3 名。

TimescaleDB 6.32

DB-Engines 时序榜: 从 2025.10 的第 5 名已上升到 2026.10 的第 4 名。

DolphinDB 4.55

DB-Engines 时序榜: 从 2025.10 的第 8 名已上升到 2026.10 的第 6 名。

Apache Druid 4.67
Graphite 4.20
QuestDB 3.05
TDengine 3.04

DB-Engines 时序榜: 从 2025.10 的第 10 名已上升到 2026.10 的第 9 名。

Apache IoTDB 2.85

DB-Engines 时序榜: 从 2025.10 的第 11 名已上升到 2026.10 的第 10 名。

VictoriaMetrics 1.49、OpenTSDB 1.38、Amazon Timestream 1.31
小结

Influx/Prometheus/Kdb/Timescale 是综合热度第一梯队；

DolphinDB 国内金融量化热度上涨快；

TDengine、IoTDB 工业 IoT 国内强但全球流行度分数不算高；

VictoriaMetrics 实际生产用得很多，但 DB-Engines 分数偏低，别只按分数砍。

真要"部署市占"只能分场景估：

K8s 监控几乎 Prometheus 系一家；

DevOps/Telegraf/车联网 场景 InfluxDB/OpenGemini 多；

工业国内 TDengine/IoTDB 多；

金融行情 Kdb/DolphinDB/QuestDB；

PG 混合 TimescaleDB；

超大规模分析常拿 ClickHouse/Druid 当时序分析层（但严格说不是专用 TSDB）。

二、按场景分库与短板

1) 云原生/容器/微服务监控

Prometheus： pull 采集、PromQL、告警原生，K8s 标准。

短板：单机本地存储为主、长期存储要 Thanos/Cortex/Mimir、高基数 label 容易爆、不是通用业务时序库。

VictoriaMetrics：Prometheus 长期存储替代，MetricsQL 兼容 PromQL，单机/集群都开源、压缩省资源。

短板：偏 metrics 模型，复杂关系/业务事件不行。

Grafana Mimir/Thanos：只作 Prom 长期/全局存储层，不单独当主库提。

2) 通用指标 / DevOps / 中小 IoT

InfluxDB：TSM 引擎、Telegraf 采集生态、2.x InfluxQL/Flux、3.x Rust+Arrow+Parquet 支持 SQL。短板：旧版开源集群弱/企业版才全；3.x 重构后 Flux 不支持、HA/集群偏商业；高基数 Tag的性能衰减。
Graphite：老牌指标，适合存量；新项目一般不首选。

3) 工业 IoT / 设备 / 车联网 / 边云

TDengine：超级表/一设备一子表、SQL、列存高压缩、开源可集群、内置缓存/流计算/MQTT。短板：超级表模型对自由多维 tag、深层级"工厂-车间-产线-设备"要额外用 tag 表达；部分高级功能企业版；AGPL 商用要看法务。
Apache IoTDB：树形路径 root.厂.线.设备.测点，TsFile 列存、乱序写入、边云协同、OPC UA/MQTT 适配，Apache 2.0、信创友好。短板：国际生态比 Influx/Prom 小；复杂 BI 跨域 JOIN 不如 PG 系；企业级运维平台多在商业版。
补充： KaiwuDB/CnosDB/OpenGemini(华为开源) 等国产/云原生也在用。

4) 金融行情 / 高频 tick / 量化

Kdb+：内存列存、q 语言、低延迟，银行/对冲基金主流。

短板：q 学习曲线陡、闭源/贵、非通用。

DolphinDB：分布式流批一体、SQL+脚本，国内量化/物联网都有用。

短板：自研生态，人员培养成本。

QuestDB：高吞吐写、纳秒时间、SQL、ASOF join，行情/传感器合适。

短板：生态和托管成熟度不如前两者，JOIN/集群高级能力要 POC。

5) 时序+关系混合 / 要完整 SQL

TimescaleDB（Tiger Data）：PG 扩展、hypertable、连续聚合、列存压缩，和业务表 JOIN 最顺。

短板：纯写吞吐不如专用 TSDB，单节点写有上限，分布式更多靠云/商业；行存底子压缩比一般 5--10:1，极端设备规模成本偏高。

6) 超大规模分析 / 日志型时序（非严格 TSDB）

ClickHouse：列存、向量化、即席分析强，高基数扫描好。

短板：没有原生降采样/连续聚合/时序保留语义，高频小批写和告警不如 TSDB，通常做分析层不替代【主采集库】。

Apache Druid：Kafka 实时聚合、亚秒看板。

短板：节点类型多（Broker/History/MiddleManager 等）、运维重、JOIN 弱。

OpenTSDB：HBase 后端、老大数据栈。

短板：HBase 运维重、查询语言弱，新项目少选。

三、技术调研必查清单

可转成打分表用

序列规模与高基数：总设备数×测点数×tag 组合＝活跃序列数。用真实 label 集压测，不看平均值；Prom/Influx 旧版高基数最易炸。
写入模型：batch/单点、OPC UA/MQTT/Kafka/Telegraf/remote_write；乱序比例（工业常 5--30%）、迟到数据窗口；峰值点/秒和日均增量分开测。
存储与压缩：原始→落盘压缩比（Influx 8--10:1、TDengine/IoTDB 可 10:1+，具体看数据类型和编码）、TsFile/TSM/Parquet 格式、冷热分层、对象存储归档、TTL 自动删。
查询语义：PromQL / InfluxQL / SQL / MetricsQL；时间窗口、插值、降采样、last/first、连续聚合、JOIN、UDF；监控告警一套，BI 即席一套，别混为一谈。
集群与 HA：开源是否真给多副本/分片/再均衡；Influx 旧版 OSS 集群弱、VM/TDengine 开源可集群、IoTDB 集群企业能力要确认版本、Timescale 横向靠云/商业更多。
长期保留与备份：热 7--30 天、温 90--180、冷 1--N 年；PITR、全量/增量、跨机房恢复演练。
集成边界：只问"写进来、查出去"的协议和连接器，不把 Grafana/看板当库；但要看它接 Prom/SQL/JDBC/Kafka/Flink/Spark 的成本。
许可与 TCO：Apache 2.0（IoTDB/VM/QuestDB/Druid）、MIT（Influx 部分）、AGPL（TDengine 等，嵌入/分发要注意）、商业闭源（Kdb、Influx 企业/云、Timescale 商业功能）；算硬件+存储+人力+培训+迁移。
POC 最低集：峰值写+30% 乱序、千万级活跃序列内存/磁盘、1h/7d/1y 三类查询延迟、单节点宕机恢复、3 年容量测算、备份还原。

针对客户需求，可以再提供具体的时序数据画像（比如"X 万设备、每设备 Y 测点、Z 秒/点、保留 N 年、要 SQL 还是 PromQL、是否国企信创"）。

摘要：8 款时序数据库的定位对比

数据库	定位	开源/闭源	最新版本（2026-10）	GitHub Star（2026-10-09）
Apache IoTDB	清华系工业物联网原生时序库：端边云同格式、高压缩，2.x 起新增标准 SQL 与 AI 分析节点	开源（Apache-2.0，ASF TLP）	2.0.11（1.3.7 LTS 并行）	6,404（GitHub API 实测）
InfluxDB	指标/事件/IoT 多模型时序平台：3.0 以 Rust+Parquet 完成云原生列存重构	核心开源（3 Core MIT/Apache-2.0）+ 商业 Enterprise（分布式等）	3.x（2025-04 GA）；2.8.0 / 1.11.8 维护线	26,731（GitHub API 实测）
OpenGemini	华为云开源的 InfluxDB 生态兼容的、云原生的、分布式时序库（CNCF Sandbox 项目）	开源（Apache-2.0）	v1.5.2	≈1.2k（shields.io 约数）
TDengine	涛思数据国产开源高性能时序库：超级表模型 + 标准 SQL + 内置流计算	开源（AGPLv3 核心）+ 企业版	ver-3.4.1.6	≈2.5 万（shields.io 约数；官方口径 24.7K）
kdb+	Kx（FD Technologies）闭源商业内存列存时序库：金融 tick 事实标准，q 语言驱动	闭源商业	kdb+ 4.1	--
Prometheus	CNCF pull 式监控系统 + 本地块存储 TSDB：云原生指标事实标准	开源（Apache-2.0）	3.15.0	59,708（GitHub API 实测）
TimescaleDB	PostgreSQL 扩展形态的时序 SQL 数据库：hypertable + 连续聚合 + 列存压缩	开源（Apache-2.0 核心 + TSL）	2.30 线（2.30.2）	≈2.36 万（第三方快照）
DolphinDB	国产闭源分布式 "时序存储 + 流计算 + 库内编程"一体化实时计算平台基于高性能时序数据库，支持复杂分析与流式处理的实时计算平台	闭源商业	V3.00.6.2	--

Apache lotDB

https://iotdb.apache.org/

https://github.com/apache/iotdb

InfluxDB

https://www.influxdata.com/

https://github.com/influxdata/influxdb

OpenGemini

https://docs.opengemini.org/zh/

https://github.com/openGemini/openGemini

TD-Engine

https://tdengine.com/

https://github.com/taosdata/tdengine

Promethus

https://prometheus.io/

https://github.com/prometheus

TimescaleDB (Tiger Data)

https://github.com/timescale/timescaledb

https://www.tigerdata.com/

DolphiDB

https://www.dolphindb.com | https://dolphindb.cn/

https://github.com/dolphindb

KDB+

https://kx.com/products/kdb/

1 横向对比总表（8 款 × 关键维度）

1.1 基本信息对比

维度	Apache IoTDB	InfluxDB	openGemini	TDengine	kdb+	Prometheus	TimescaleDB	DolphinDB
成立/首发	约 2014 年清华启动研发；2018-11 入 Apache 孵化器，2020-09 毕业 TLP	2013 年创立；2016-09 1.0 GA	2022-06-16 华为云宣布开源	2017-06 公司成立；2019-07 开源单机版	1993 年 Kx 创立；2003 年发布 kdb+	2012 年 SoundCloud 启动；2015 公开发布	2017-04-04 首发	2016 年公司成立；2018 年初首发
开源/闭源	开源	核心开源（1/2.x OSS、3 Core）	开源	开源（核心 taosd）+ 商业双轨	闭源商业	开源	开源（核心 Apache-2.0）	闭源商业（社区免费版）
License	Apache-2.0	1/2.x MIT；3 Core MIT/Apache-2.0	Apache-2.0	AGPLv3（核心）+ MIT（适配器/连接器）	商业专有许可	Apache-2.0	Apache-2.0（核心）+ TSL（高级功能）	商业专有许可
开发语言	Java（AINode 含 Python）	Go（1/2.x）；Rust（3.x）	Go	C	C + q/K 语言	Go	C（PostgreSQL 扩展）	C++ + DolphinScript
最新版本（2026-10）	2.0.11（1.3.7 LTS 并行维护）	3.x（2025-04 GA）；2.x 至 2.8.0；1.x 至 1.11.8	v1.5.2	ver-3.4.1.6	kdb+ 4.1（二进制 2026.01.23）	3.15.0	2.30 线（2.30.2；2.28.2 为 6 月稳定线）	V3.00.6.2
GitHub Star（2026-10-09）	6,404	26,731	≈1.2k	≈2.5 万	--	59,708	≈2.36 万	--
维护组织	Apache Software Foundation（清华/天谋科技主导）	InfluxData, Inc.	openGemini 社区（华为云发起，CNCF Sandbox）	涛思数据（TAOS Data）	KX（FD Technologies 事业部）	Prometheus 开发社区（CNCF 毕业）	Tiger Data（原 Timescale, Inc.）	浙江智臾科技
官网	iotdb.apache.org	influxdata.com	docs.opengemini.org	taosdata.com	code.kx.com	prometheus.io	tigerdata.com/timescaledb	dolphindb.cn
GitHub	github.com/apache/iotdb	github.com/influxdata/influxdb	github.com/openGemini/openGemini	github.com/taosdata/TDengine	无公开源码仓库	github.com/prometheus/prometheus	github.com/timescale/timescaledb	无产品源码（组织内仅有工具链）

表注：

Star 数逐项信源与抓取方式详见各单库章节"基本信息卡"。

IoTDB / InfluxDB / Prometheus 为 GitHub REST API 实测值（本报告组织方于 2026-10-09 复核一致）；

TDengine / openGemini 因 API 直连受限采用 shields.io 实时徽章约数（四舍五入，官方口径 24.7K / 24,000+ 佐证）；

TimescaleDB 为第三方镜像站 2026-10-05 快照（官方口径 22K+，另第三方快照 22.2K~23.6K）；

kdb+ / DolphinDB 闭源无公开仓库。各数字均为约数精度，正式引用请回链各库信源。

1.2 技术特性对比

维度	Apache IoTDB	InfluxDB	openGemini	TD-Engine	kdb+	Prometheus	TimescaleDB	DolphinDB
存储引擎	自研 TsFile 列式（LSM 式追加 + Compaction）	1/2.x TSM （LSM）；3.x Arrow 内存 + Parquet 磁盘（对象存储一等公民）	LSM 列式（.tssp 文件）	LSM 列式（Vnode 内）	内存列存 + 按日分区磁盘列存（splayed/segmented）	Head block + WAL + 不可变 block（2h 起、Compaction 合并）	PG 行存（近期 chunk）+ 历史 chunk 列存压缩（Hypercore）	OLAP 纯列存 + TSDB LSM 行列混存双引擎
写入模式	append-only、批量、乱序容忍（按时间戳归并）	Line Protocol append-only 批量 push	append-only LSM 批量	append-only 批量、无模式（兼容 Line Protocol 等）	tick 追加 + 日终归并落盘	pull 采集 append-only（落盘样本不可改）	标准 SQL INSERT（事务）	批量 append；TSDB 引擎支持高频小批量/乱序/更新删除
时间窗口聚合	`GROUP BY` 原生	`GROUP BY time()`	`GROUP BY time()`	SQL 窗口 + `INTERP`	qSQL `by time`	PromQL 范围向量	`time_bucket`	`window`/`moving`
连续聚合/降采样	CQ 连续查询 ✓	连续查询/任务 ✓	CQ 连续查询 ✓	Stream 流计算 + RSMA 自动降采样 ✓	无内建（q 脚本自建）	recording rules（预聚合，近似）	连续聚合物化视图 ✓	流引擎物化 ✓
TTL/保留策略	database 级 TTL ✓	Retention Policy ✓	RP（`WITH DURATION`）✓	`KEEP` 多级保留 + 多级存储迁移 ✓	无内建	retention 到期整块删除	保留策略自动 drop 旧 chunk ✓	`dropPartition` ✓
插值/对齐	`FILL`(PREV/LINEAR) ✓	FILL/差值 ✓	FILL ✓	`INTERP`+`FILL` ✓	`aj`/`wj` as-of join ✓	无	`time_bucket_gapfill`（部分 TSL）	`aj`/区间函数（对标 kdb+）✓
查询语言	SQL-like（1.x 树模型；2.x 表模型标准 SQL）	InfluxQL / Flux / SQL	InfluxQL	标准 SQL（TAOS SQL）	qSQL	PromQL	标准 SQL（100% PG 兼容）	DolphinScript（SQL+向量）
集群/扩展	ConfigNode + DataNode MPP，多副本（Ratis/IoTConsensus）	3 Core 单机；HA/集群仅 Enterprise	ts-sql / ts-meta / ts-store 三层 MPP，独立水平扩展	VGroup Raft 副本组，Qnode 存算分离	无透明分布式，tick 架构手工多节点拼装	无内建集群，靠 remote write + Thanos/Mimir/VictoriaMetrics 或联邦	社区版单节点；分布式 hypertable 为 TSL	控制节点 + 数据节点对等分布式，多副本
高基数处理	动态模板批量建序列	标签索引；3.x 称无限基数【一方称】	倒排索引（v1.2 起增强）	标签索引 + 一设备一子表物理分片	不适配（非标签模型）	高基数风险明确警告（内存/索引爆炸）	高基数标签场景开销大【一方称】	分区 + 块索引
压缩比（口径）	无损 10~15 倍【一方称】	---（未收录无出处数字）	存储成本约关系库 1/20【一方称】	9.89:1 ~ 87.64:1【官方 TSBS 自测】	官方未公布	Gorilla/XOR 编码（WAL 压缩约减半）【已查证】	80%~95% 空间节省【一方称】	金融行情 ≥10:1【一方称】
是否支持Schema动态追加字段	是。树模型运行期按路径追加新测点（对齐 / 非对齐序列均可，受 auto-create schema 参数控制）；2.x 表模型支持 `ALTER TABLE ADD COLUMN`；动态模板（Template）批量扩展同构测点	是。Line Protocol schemaless 无模式写入：新 measurement/tag/field 随写入自动创建（Tag 建索引、Field 不建索引）；约束：同一 field 类型冲突时新类型写入被拒	是。无模式写入（兼容 InfluxDB Line Protocol）：新字段 / 标签随写入自动纳入现有库，无需预建表 / 列	是。超级表动态加列（`ALTER TABLE ADD COLUMN`，子表自动继承）；另有 Schemaless 无模式写入（兼容 Line Protocol/OpenTSDB 协议），按标签组合自动建子表	部分支持。内存表可随时单列追加（q 向量语言）；磁盘 HDB 按日分区列存列集合固定，历史分区追加新列需脚本重建分区，无自动 schema 迁移	否。无字段 / 列概念：metric+label 集合由采集端固定，样本仅（时间戳，值）；新增 metric 或 label 组合自动成为新序列，但无法在已有序列上 "追加字段"，模型变更即视为新序列	是。超表即 PG 表，标准 `ALTER TABLE ADD COLUMN` 直接生效、chunk 自动继承；约束：已压缩 chunk 上部分 DDL 需先解压（官方限制）	是。已有表上追加列（内置 ALTER TABLE/SQL 扩展，分区表亦支持；历史分区新列为空值，列存追加不触发全表重建）
典型场景	工业物联网、能源电力、车联网、端边云协同	监控/可观测、IoT、时序+数据湖分析	可观测性（Metrics/Log/Trace）、华为云生态	IIoT、能源/电力、车联网、IT 运维	金融 tick、实时风控、高频回测	云原生监控与告警	PG 技术栈 + 时序分析（SaaS/IoT/金融辅助）	量化金融、电力高频量测、工业 IoT
核心优势	工业物联网原生：端边云 TsFile 同格式同步；TsFile 列式高压缩（无损 10~15 倍【一方称】）+ 原生乱序 / 多频率写入；2.x 起标准 SQL 表模型 + 连续查询 / 降采样 + AI 节点（AINode）	多模型（指标 / 事件 / IoT）+ 三查询语言（InfluxQL/Flux/SQL）；3.x 云原生列存（Arrow/Parquet/ 对象存储，开放格式对接数据湖）【官方口径】；生态成熟（Telegraf 400+ 插件、Grafana 一等公民）	InfluxDB 生态无缝兼容（Line Protocol / InfluxQL / Prometheus remote storage，迁移成本极低）；MPP 三层（ts-sql/ts-meta/ts-store）各层独立水平扩展，100+ 节点；CNCF Sandbox 中立治理；官方称存储成本约关系库 1/20【一方称】	超级表 + 一设备一子表 + 标签索引，高基数物理分片；官方 TSBS 自测：写入为 InfluxDB 的 3.0~10.6 倍、压缩 9.89~87.64:1【官方自测】；一体化（缓存 / 订阅 / 流计算 / RSMA 自动降采样 + 标准 SQL + AI Agent）	内存列存 + 向量计算：当日全量 tick 驻内存、亚秒级查询（金融事实标准，q 语言）；tick 架构（feedhandler/tickerplant/RDB/HDB）写入与分析解耦；as-of join（`aj`/`wj`）区间对齐原生	云原生监控事实标准：pull 模型 + 服务发现 + PromQL + Alertmanager；本地 TSDB 轻量（单二进制、Gorilla/XOR 高压缩、WAL 压缩约减半）；长期存储明确外包（remote write + Thanos/Mimir/VictoriaMetrics）	100% PostgreSQL 兼容（事务 / JOIN / 全部 PG 生态，业务数据与时序数据同库）；连续聚合物化视图 + 保留策略均为声明式 SQL；历史 chunk 自动转列存压缩（官方称省 80~95% 空间【一方称】）	流批一体 + 库内编程（存储 / 流计算 / 因子计算同一集群，避免数据搬运）；双引擎（OLAP 纯列存 + TSDB LSM 行列混存）兼顾批量分析与高频 / 乱序写入；金融国产 kdb+ 替代（官方自测 4 节点约 1,450 万条 / 秒【一方称】）
主要短板	社区规模小；1.x→2.x 迁移成本；复杂关联分析弱	版本线割裂；3 Core 单机无 HA；Flux 采用率不及预期	社区规模小；存算分离未 GA；标准 SQL 弱	AGPLv3 传染性；可观测生态弱；2.x→3.0 语法不兼容	价格昂贵；q 语言门槛高；生态封闭	单机不原生扩展；不擅长长周期留存；高基数风险	写入吞吐受 PG 行存约束；高基数开销大；TSL 非纯开源	闭源可审计性受限；DolphinScript 学习成本；国际生态弱

2 时序数据库定位图谱

2.1 按"技术路线 × 场景定位"分类图谱

flowchart TB subgraph S1 $"自研引擎 \cdot 通用时序数据库"$ A $"Apache IoTDB\工业物联网 · 端边云 · 高压缩"$ B $"InfluxDB 3.x\多模型 · 云原生列存 · 开放格式"$ C $"openGemini\Influx 生态兼容 · MPP 分布式"$ D $"TDengine\超级表 · 标准 SQL · 流计算"$ end subgraph S2 $"关系型生态路线"$ E $"TimescaleDB\PostgreSQL 扩展 · SQL/事务/JOIN"$ end subgraph S3 $"监控指标专用"$ F $"Prometheus\pull 模型 · PromQL · 本地短期存储"$ end subgraph S4 $"金融 \cdot 内存计算路线"$ G $"kdb+\内存列存 · tick 架构 · q 语言"$ H $"DolphinDB\分布式内存列存 · 流批一体 · 库内编程"$ end B -->|"生态兼容 / 竞品"| C A -->|"国产竞品"| D F -->|"remote write / 长存外包"| E G ---|"国产替代"| H

2.2 按"存储引擎 × 部署模型"再看一眼

路线	代表产品	特点	取舍
LSM + 列式（自研引擎）	IoTDB（TsFile）、InfluxDB（TSM/Parquet）、openGemini（.tssp）、TDengine	写优化（顺序写、乱序归并）+ 高压缩，时序场景主流	写吞吐与压缩比优先；事务/复杂 JOIN 弱
内存优先列存	kdb+、DolphinDB	当日数据全驻内存 + 向量计算，亚秒级金融分析	延迟极致；成本高、生态封闭（kdb+ 尤甚）
关系型引擎增强	TimescaleDB	复用 PostgreSQL 行存 + 时间分区 + 列存压缩	SQL/生态完整；写入吞吐与高基数弱于专用引擎
本地块存储（监控专用）	Prometheus	pull 模型 + 短期本地留存 + PromQL	简单可靠；长期存储/集群外包给 Thanos/Mimir 等

2.3 补充解读

自研引擎阵营是"纯时序"主力 ：IoTDB / TDengine 面向工业 IoT，主打高写入、高压缩、国产化；InfluxDB 3.x 走"开放列存格式（Parquet）+ 云原生对象存储"路线，向数据湖一体化靠拢；openGemini 则打"InfluxDB 生态无缝兼容 + 水平扩展"牌。
TimescaleDB 是"关系型桥头堡"：以 PostgreSQL 扩展形态存在，业务数据与时序数据同库 JOIN，是"不想引入专有时序库"的团队首选，代价是写入吞吐上限与高基数开销。
Prometheus 是"专用件"而非通用时序库：它解决"近期监控指标怎么查"这一件事，长期存储与横向扩展明确外包给生态（Thanos / Mimir / VictoriaMetrics），这也是其与通用 TSDB 的根本分工。
kdb+ / DolphinDB 走"金融高频"路线：内存列存 + 向量计算 + 库内编程，服务于 tick 级行情与实时风控；DolphinDB 常作为 kdb+ 的国产替代（官方提供迁移文档）。

3 单库深度调研

每库统一模板：产品介绍 / 发展历程 / 基本信息卡 / 主要功能 / 核心优势 / 主要短板 / 潜在风险与局限性 / 适用场景 / 同类竞品 / 发展趋势 / 工作原理与核心架构（含 mermaid 架构图）/ 写入与查询性能特点 / 支持的部署方式 / 重要依赖 / 生态与集成 / 使用指南 / FAQ / 推荐文献 / 参考文献。

事实标注口径（【已查证】/【一方称】）与 Star 数信源见各节"基本信息卡"及报告头部说明。

3.1 【Apache IoTDB】（面向工业物联网的高吞吐、高压缩开源时序数据库）

产品介绍

产品定位 ：Apache IoTDB 是一款低成本、高性能的物联网原生时序数据库（IoT-native TSDB） ，主打工业物联网（IIoT）场景下海量、高并发、多频率、乱序时序数据的统一存储与分析，采用"端-边-云"协同架构，可独立部署也可与 Hadoop/Spark/Flink 大数据生态打通。【已查证】官网产品介绍
诞生背景与原因 ：项目最早由清华大学大数据系统软件团队 研发（约 2014 年启动），源于国家重点研发计划支持下的工业大数据需求，解决"物联网设备数量爆炸、采样频率高、数据乱序多、传统关系库/OLAP 扛不住写入与压缩"的痛点。【一方称】天谋科技官网；【一方称】CSDN：盘点 2020 年晋升 TLP 项目
解决的核心问题 ：
- 海量设备测点的高吞吐写入（千万级点/秒级）
- 时序数据高压缩比长期留存（磁盘成本）
- 端边云协同：边缘端与云端使用同一套 TsFile 格式无缝同步
- 工业现场乱序、多频率数据的写入与对齐查询
URL ：
- 官网：https://iotdb.apache.org/ 【已查证】
- GitHub：https://github.com/apache/iotdb 【已查证】

发展历程

2014 年前后 ：清华大学大数据系统软件团队启动 IoTDB 研发。【一方称】CSDN
2018-11-18 ：正式进入 Apache 孵化器（Incubator），成为中国高校首个进入 Apache 孵化器的项目，也是 ASF 旗下唯一的开源时序数据库项目。【已查证】Apache Incubator 项目列表
2018-11-24 ：Apache 官方 GitHub 仓库 apache/iotdb 创建。【已查证】GitHub API
2020-09-18 ：孵化器状态结束（graduation）；2020-09-23/24 ASF 官方宣布 IoTDB 毕业成为 Apache 顶级项目（TLP），孵化期 1 年 10 个月。【已查证】Apache Incubator；【已查证】清华大学软件学院公告
2022-12-03 ：发布 V1.0.0 ，稳定分布式架构（ConfigNode/DataNode）。【已查证】官方 Release History
2023-06-30 ：发布 V1.2.0，引入流处理框架、动态模板、内置查询函数。【已查证】同上
2024-01-01 ：发布 V1.3.0 ，支持 SSL 加密、权限模块重构；后续 1.3.x 线持续维护，最新 1.3.7 （见下载页）。【已查证】官方 Release History；【已查证】官方下载页
2025 年起 ：进入 2.x 大版本线 ，引入表模型（Table Model） 与标准 SQL（SELECT/JOIN/GROUP BY/子查询），新增 AINode （机器学习/时序大模型分析节点）；最新 V2.0.11 于 2026-09-11 发布。【已查证】GitHub Release v2.0.11；【已查证】2.0 Release Notes

基本信息

项	值
开源/闭源	开源（Apache 顶级项目）【已查证】
开发语言	Java （核心）；AINode 含 Python 组件【已查证】GitHub API
当前最新版本（2026-10 口径）	2.0.11 （2026-09-11 发布，主线）；1.3.7 （并行维护的 1.x LTS 线）；0.13.4 （旧线归档）【已查证】官方下载页
License	Apache License 2.0 【已查证】GitHub API
GitHub Star（截至 2026-10-09）	6,404 Star / 1,159 Fork （抓取日期 2026-10-09，来源 GitHub REST API）
维护组织	Apache Software Foundation （核心 committer 主要来自清华大学/天谋科技 Timecho）【已查证】清华大学软件学院
官网 URL	https://iotdb.apache.org/
GitHub URL	https://github.com/apache/iotdb

主要功能

高吞吐写入 ：支持 Session 批量插入、JDBC、MQTT/REST 等多协议接入，面向百万级设备测点。【已查证】产品介绍
时序原生查询语义 ：时间窗口聚合 GROUP BY([start,end), interval)、降采样、FILL（PREVIOUS/LINEAR/常数插值）、ALIGN BY TIME/DEVICE 结果对齐、近百种内置聚合与时序计算函数（DIFF、导数、累加等）。【已查证】SQL Manual；【已查证】Query Data
连续聚合（Continuous Query, CQ） ：滑动窗口流式预计算，如每小时平均温度自动写入新序列，支持 RESAMPLE 容忍乱序。【已查证】CQ 文档
TTL 数据过期 ：可按 database 设置 TTL，原始高精度数据短留存、降采样结果长留存，自动释放磁盘。【已查证】Timecho CQ 文档
树模型 + 表模型双模式 ：1.x 为面向设备层级的树模型（root.sg.device.sensor）；2.0 起新增表模型，兼容标准 SQL（JOIN/子查询），两种模型相互隔离。【已查证】2.0 Release Notes
数据订阅（Data Subscription） ：1.3.3 起支持流式消费变更数据，输出 Message 或 TsFile 格式，可在入库后再建 Topic。【已查证】数据订阅文档
边云同步 ：边缘端与云端共用 TsFile，支持无缝数据同步与聚合 。【已查证】产品介绍
AI 能力（AINode） ：2.x 引入机器学习节点，支持模型注册、时序预测/异常检测，乃至时序大模型。【已查证】Cluster Concepts

核心优势

写多读少 + 高压缩比 ：专为时序 append-only 负载优化，TsFile 列式存储 + 多级编码压缩，无损压缩可达 10~15 倍。【一方称】Timecho 能源行业文章
工业场景深度适配 ：原生支持乱序写入、多频率采样、对齐查询，不要求设备时钟严格同步。【已查证】产品介绍
端边云一体 ：边缘（TsFile/Edge 包）与云端同格式，数据可直接同步上传，避免格式转换损耗。【已查证】下载页含 Edge 包
Apache 中立治理 ：Apache-2.0 协议、ASF TLP，无厂商锁定；企业版由天谋科技 TimechoDB 商业化。【已查证】ASF 毕业公告
MPP 分布式可线性扩展 ：2.x 采用 ConfigNode/DataNode 分离架构，支持多副本、多种共识协议（Simple/IoTConsensus/Ratis）。【已查证】Release History

主要短板

社区规模相对小 ：GitHub Star 仅 6.4k，远低于 InfluxDB/TimescaleDB 等；open issues 757，生态成熟度仍在追赶。【已查证】GitHub API
2.0 大版本引入表模型，与 1.x 树模型语法/体系差异较大 ，老用户迁移与文档割裂（1.x 与 2.x 用户手册并行维护）。【已查证】下载页
通用 OLAP/关联分析能力弱于 ClickHouse/Doris：定位时序写入，复杂多表 JOIN、大宽表分析非其强项。【一方称】综合官方定位推断
学习曲线：树模型路径结构（root.xx.xx）对关系型背景开发者不直观；运维参数（compaction、多目录策略）较复杂。

潜在风险与局限性

版本不兼容风险 ：0.13 → 1.0 数据目录结构不兼容，不能直接拷贝 data 目录；UDF API 在 1.0 发生 Breaking Change，需改写。【已查证】官方下载页升级说明
商业公司绑定度较高 ：核心 committer 与天谋科技（Timecho）深度绑定，虽 Apache 治理中立，但企业级特性（企业版 TimechoDB）与开源版存在分化。【一方称】Timecho 官网
JDK 依赖 ：强依赖 Java 运行时，内存占用与 JVM 调优成本不可避免；V2.0.11 起 C++ Native API 要求 JDK ≥ 17。【已查证】C++ API 文档
生态可视化插件相对小众：Grafana 插件存在但非官方一等公民；相比 Prometheus 生态在云原生监控领域渗透率仍低。

适用场景

工业物联网 / 工业互联网：智能制造产线、设备传感器、数控机床监控（清华系背景强项）。
能源电力 ：风电（金风科技）、光伏、储能电站海量机组运行数据采集。【一方称】Timecho 案例
车联网 / 智慧出行 ：蔚来汽车等百万级车辆实时数据上报。【一方称】CSDN 案例
端边云协同：边缘网关采集 + 云端汇聚的统一时序存储。
不适用：强事务、复杂多表关联 OLTP、大规模 ad-hoc 关联分析（应选关系库/OLAP）。

发展趋势

Star/Fork 趋势 ：截至 2026-10-09 为 6,404 Star / 1,159 Fork（GitHub API）；GitHub 仓库创建于 2018-11-24，2020-09 毕业 TLP 后进入稳步增长期；从版本节奏看，2026 年仍保持高频迭代（2.0.x 已迭代到 2.0.11，最近一次 push 2026-10-02），社区活跃度健康。【已查证】
技术演进方向 ：2.x 重点转向表模型 + 标准 SQL （降低关系型用户迁移门槛）、AINode 时序大模型/AI 分析 、数据订阅 （类 Kafka 流式消费）、云原生 K8s/Helm 部署。【已查证】Release Notes
一句话总结：IoTDB 正从"纯工业物联网时序库"向"兼容标准 SQL、带 AI 能力的云原生时序分析平台"演进，背靠清华 + 天谋科技，在工业/能源国产替代赛道持续深耕。

工作原理与核心架构

概念术语（5~10 个）

TsFile ：面向时序数据的列式存储文件格式（也是 Apache 顶级项目），IoTDB 与 AINode 底层统一使用，支持边云共享。【已查证】产品介绍
ConfigNode ：集群管理节点，管理元数据、分区、权限、负载均衡，多副本全量互备。【已查证】Cluster Concepts
DataNode：数据节点，接收客户端请求、负责数据存储与计算（MPP 执行）。【已查证】同上
AINode：2.x 新增分析节点，提供机器学习/时序大模型推理能力。【已查证】同上
Region / 数据分区 ：IoTDB 将数据按"分库 + 分时间区间 + 副本"切分为 Region，分布在 DataNode 上，Region 放置算法保证均衡与故障容错。【已查证】Data Partitioning
Tree Model / Table Model ：1.x 设备层级树模型；2.0 新增标准关系表模型。【已查证】2.0 Release Notes
3C3D ：典型集群部署形态（3 ConfigNode + 3 DataNode）。【已查证】集群部署文档
CQ（Continuous Query） ：连续聚合查询，定时将窗口聚合结果写回新序列。【已查证】CQ 文档
Template（动态模板） ：1.2 引入，批量为同构设备批量创建时间序列，避免高基数元数据膨胀。【已查证】Release History

架构与运行原理

写入路径：客户端 → DataNode（RPC/Session）→ 写前日志 WAL 持久化 → MemTable 内存表 → 后台 Flush 为 TsFile（列式、时间有序、按设备/测点分组）→ Compaction 合并小文件。【已查证，综合官方架构文档】
存储引擎 ：基于自研 TsFile，列式编码 + 压缩（支持 PLAIN/DN/GORILLA 等编码），数据 append-only，历史数据不可原地修改，靠 Compaction 合并。
查询路径 ：SQL 解析 → MPP 优化器定位涉及的 DataNode/Region → 并行扫描 TsFile（时间索引跳过不相关文件）→ 聚合/对齐/插值 → 结果汇聚返回。【已查证】MPP 框架见 Release History
集群拓扑：ConfigNode 组（奇数节点、Ratis 共识）管理元数据；DataNode 组承载数据与计算，多副本；AINode 独立提供 AI 推理。

flowchart TB subgraph Client $"客户端 / 边缘端"$ C1 $Session / JDBC$ C2 $MQTT / REST$ C3 $Grafana / 应用$ end subgraph CN $"ConfigNode 组 (3C)"$ CN1 $ConfigNode-1$ CN2 $ConfigNode-2$ CN3 $ConfigNode-3$ CN1 -.全量互备.-> CN2 CN2 -.全量互备.-> CN3 end subgraph DN $"DataNode 组 (3D)"$ DN1 $DataNode-1\WAL + MemTable + TsFile$ DN2 $DataNode-2\WAL + MemTable + TsFile$ DN3 $DataNode-3\WAL + MemTable + TsFile$ end subgraph AI $"AINode"$ AI1 $ML / 时序大模型推理$ end C1 --> DN1 C2 --> DN1 C3 --> DN1 DN1 <-->|元数据调度/分区| CN1 DN2 <--> CN2 DN3 <--> CN3 DN1 <-->|多副本共识| DN2 DN2 <--> DN3 DN1 --> AI1

写入模式与查询特性

写入模式 ：以 append-only 为主，批量 Session 插入为高性能推荐方式；支持乱序写入 （带时间戳的迟到数据可写入，配合 CQ 的 RESAMPLE 窗口容忍）；原生协议为 IoTDB Session RPC，兼容 JDBC。【已查证】产品介绍
查询特性 ：
- 时间窗口聚合 ：GROUP BY([start, end), interval) 原生支持。【已查证】SQL Manual
- 连续聚合（CQ） ：定时预计算写回，支持 RESAMPLE 乱序容忍。【已查证】CQ 文档
- 降采样 ：树模型 GROUP BY 窗口聚合；表模型用 data_bin() + 标准 GROUP BY。【一方称】Timecho 树表双模型
- TTL ：按 database 设置数据保留时间，到期自动清理。【已查证】Common Config
- 插值对齐 ：FILL(PREVIOUS/LINEAR/常数) 补空值；ALIGN BY TIME/DEVICE 两种结果对齐模式。【已查证】Timecho 查询文档

写入与查询性能特点

以下数字均标注口径与出处；无第三方独立复现的标注【一方称】。

写入吞吐 ：
- 官方自述：单台服务器写入可达数千万点/秒 ，集群线性扩展至数亿点/秒 ；单核写入请求 >数万次/秒。【一方称】官方性能文档 V1.2.x
- TPCx-IoT 基准（第三方 InfoQ 援引）：IoTDB 363 万点/秒 ，对比 InfluxDB 开源版 52 万点/秒（约 7 倍）、TimescaleDB 15 万点/秒。【一方称】InfoQ 对比文；博客园
- SIGMOD'23 论文：系统达到 10 million inserted values/sec （单节点测试口径）。【已查证，学术论文】Sigmod 2023 PDF
压缩比 ：无损压缩可达 10~15 倍 （TsFile 列式编码）；Timecho 对比文中给出 12:1 ，对比 InfluxDB 3:1。【一方称】Timecho 选型指南
查询延迟 ：
- SIGMOD 论文：1 天 10 万点选择查询、3 年千万点聚合查询可在 100ms 内完成。【已查证，学术论文】Sigmod 2023 PDF
- 官方自述：单台支持数千万点/秒查询吞吐，毫秒级聚合百亿数据点 。【一方称】官方性能文档
- 第三方援引：查询延迟稳定在 2ms 级 （对比 InfluxDB 45ms、TimescaleDB 120ms）。【一方称】CSDN
高基数处理 ：支持动态模板（Template） 批量管理同构设备，缓解百万级测点元数据膨胀；官方宣称支持百万级设备接入 。【一方称】产品介绍

支持的部署方式

单机版 ：解压即用（all-in-one 包），Windows/Linux 均可。【已查证】下载页
集群版 ：3C3D（3 ConfigNode + 3 DataNode）为推荐起步拓扑，支持多副本、水平扩缩容。【已查证】集群部署
Docker / Docker Compose ：官方提供 Docker 部署文档，支持 3C3D 容器化（host/overlay 网络）。【已查证】Docker 部署
Kubernetes ：官方 Helm Chart（要求版本 ≥ 1.3.3.2），helm install iotdb ./ -n iotdb-ns。【已查证】K8s 文档
边云协同 ：提供 Edge 边缘包，与云端 TsFile 同格式同步。【已查证】下载页
云托管/企业版 ：天谋科技 TimechoDB 为基于 IoTDB 的商业企业版，提供云托管与国产化部署。【一方称】Timecho 官网

重要依赖

运行时依赖 ：
- Java ≥ 1.8 （1.8、11、17 已验证）；自 V1.3.2.2 起推荐直接部署 JDK 17 （老版本 JDK 部分场景性能问题，DataNode 可能 stop 不掉）。【已查证】环境要求
- 源码编译需 Maven ≥ 3.6。【已查证】GitHub README
- AINode 额外要求 Python ≥ 3.11（推荐 3.12）。【已查证】AINode 部署
系统参数 ：max open files 设为 65535；somaxconn 设为 65535 避免高负载 connection reset。【已查证】下载页环境配置
C++ Native API 依赖 ：自 V2.0.11 起要求 JDK ≥ 17，另需 Flex/Bison/Boost/OpenSSL。【已查证】C++ API

生态与集成

客户端驱动 ：Java（Session/JDBC）、Python、C++、Go、Node.js 等原生 SDK；JDBC 驱动类 org.apache.iotdb.jdbc.IoTDBDriver，可接入 DataGrip/DBeaver。【已查证】DataGrip 集成
可视化 ：官方提供 Grafana 连接器与 Grafana 插件 （下载页单列）；支持 ThingsBoard、DataEase。【已查证】下载页
监控：对外暴露 Prometheus 格式指标，可被 Prometheus + Grafana 采集监控。【已查证】监控工具
大数据生态 ：提供 Spark-IoTDB-Connector （Java/Scala Spark 读写树模型）；深度集成 Hadoop、Flink 。【已查证】Spark 集成
周边工具 ：TsFile 独立文件格式（可脱离 IoTDB 直接 Hadoop/Spark 分析）、数据同步工具、IoTDB-Benchmark 压测工具、Cli 命令行。【已查证】Benchmark 工具

使用指南（精简）

安装部署要点

Linux ：安装 JDK 17 → 下载 All-in-one 二进制包解压 → 配置 conf/iotdb-system.properties 等 → 运行 sbin/start-standalone.sh 启动单机；集群则按 3C3D 分别启动 ConfigNode/DataNode。参考官方集群部署。
Windows ：同样解压二进制包后执行 sbin\start-standalone.bat，开箱即用；需自行配置 JDK 环境变量与文件句柄数。
官方文档 ：https://iotdb.apache.org/zh/UserGuide/latest/

关键操作示例（建库 → 写数据 → 查询）

sql 复制代码

-- 1. 创建数据库（存储组）
CREATE DATABASE root.ln.wf01;

-- 2. 创建设备测点（或使用 Template 批量创建）
CREATE TIMESERIES root.ln.wf01.wt01.status WITH DATATYPE=BOOLEAN, ENCODING=PLAIN;
CREATE TIMESERIES root.ln.wf01.wt01.temperature WITH DATATYPE=FLOAT, ENCODING=RLE;

-- 3. 写入数据
INSERT INTO root.ln.wf01.wt01(timestamp, status, temperature)
VALUES(1, true, 36.5);

-- 4. 时间窗口聚合查询（降采样：每 10s 平均温度）
SELECT AVG(temperature)
FROM root.ln.wf01.wt01
GROUP BY([2024-01-01T00:00:00, 2024-01-02T00:00:00), 10s);

-- 5. 按设备对齐查询 + 线性插值补空
SELECT * FROM root.ln.wf01.**
ALIGN BY DEVICE FILL(LINEAR);

Q: IoTDB 1.x 和 2.x 有什么区别？该选哪条线？

2.0 起新增表模型 （标准 SQL/JOIN/子查询）与 AINode AI 节点，面向新场景推荐；1.3.x（最新 1.3.7）仍在维护，适合存量树模型生产环境平滑升级。两者数据模型相互隔离，不可直接互通。【已查证】2.0 Release Notes；下载页

Q: IoTDB 一定要用集群吗？最小生产部署是什么？

不必。单机 all-in-one 即可边缘/小规模生产；高可用推荐 3C3D （3 ConfigNode + 3 DataNode）起步，ConfigNode 奇数保证共识，DataNode 水平扩展。【已查证】集群部署

Q: IoTDB 能直接当 Grafana 数据源做监控大盘吗？

可以。官方在下载页提供 Grafana 连接器与 Grafana 插件 ；同时 IoTDB 自身暴露 Prometheus 指标，可被 Prometheus 抓取后用 Grafana 可视化。【已查证】下载页；监控工具

Q: TsFile 是什么？为什么强调边云同格式？

TsFile 是 Apache 顶级的时序列式文件格式，IoTDB 底层存储即 TsFile。边缘端采集写 TsFile、云端也用 TsFile，数据无需格式转换 即可直接上传/加载进 IoTDB（LOAD 命令），简化端边云数据链路。【已查证】产品介绍

参考文献

3.2 InfluxDB（含 3.0）------从 Go+TSM 单机时序库演进为 Rust+Arrow/Parquet 列存、面向云原生分析的多模型时序平台

产品介绍

产品定位 ：面向指标、事件、IoT 遥测与实时分析的开源时序数据库（TSDB），官方描述为 "Scalable datastore for metrics, events, and real-time analytics"【已查证：GitHub API repo description】。当前存在三条并行版本线：1.x（Go，TSM 引擎，InfluxQL） 、2.x（Go，TSM 引擎，内置 Flux 查询语言与 UI） 、3.x（Rust 重写，FDAP 列存堆栈，SQL/InfluxQL/Flux）。
诞生背景与原因：2013 年 Paul Dix 创立 Errplane（2015 年更名 InfluxData），初衷是解决"监控数据写入快、时间维度查询多、关系型数据库扛不住高写入"的问题；当时主流方案（RRDtool、Graphite）缺乏多租户、SQL 与水平扩展能力【已查证：InfluxData 官方博客，首次公开演讲为 2013-11-12】。
解决的核心问题：高吞吐 append-only 时序写入、按时间窗口聚合查询、数据 TTL 自动过期、高基数标签索引、监控/ IoT 场景下的实时降采样与告警。
官方链接 ：
- 官网：https://www.influxdata.com/
- GitHub（主仓库，1.x/2.x/3.x 开源代码）：https://github.com/influxdata/influxdb

发展历程

2013 年末：Errplane 创立，InfluxDB 首次公开演讲（2013-11-12）【已查证：InfluxData 博客《Announcing InfluxDB IOx》】。
2015 年：公司更名 InfluxData；Telegraf 首次发布（2015-06）、Kapacitor 首次发布（2015-11），形成 TICK 技术栈【已查证：InfluxData 博客《InfluxDB 2.0 Alpha Release》】。
2016-09：InfluxDB 1.0 GA【已查证：InfluxData 2.0 GA 公告中明确 "InfluxDB 1.0 ... made generally available in September 2016"】。
2020-11：宣布 InfluxDB IOx------用 Rust + Apache Arrow/DataFusion/Parquet/Arrow Flight 重写下一代核心【已查证：InfluxData 博客《Announcing InfluxDB IOx》】。
2020 年末：InfluxDB 2.0 GA（MIT 许可，引入 Flux、UI、任务脚本）【已查证：InfluxData 2.0 GA 公告】。
2023-10：宣布 IOx 项目即 InfluxDB 3.0 产品套件基础【已查证：InfluxData 博客《InfluxData Unveils Future of Time Series Analytics with InfluxDB 3.0》】。
2025-01-13：InfluxDB 3 Core（开源）与 3 Enterprise（商业）公开 alpha【已查证：InfluxData 博客，2025-01-13】。
2025-04-15：InfluxDB 3 Core 与 3 Enterprise GA【已查证：InfluxData 官方 GA 公告】。
2025-05：官方宣布将 IOx 仓库全部代码合入主 influxdb 仓库 main 分支并关闭 IOx 独立仓库，3.x 开源代码回归主仓库（MIT/Apache-2 双许可）【已查证：InfluxData 博客《The Plan for InfluxDB 3 Open Source》，2025-05-29】。
2026-09-15 ：Docker 镜像 latest tag 切换指向 InfluxDB 3 Core【已查证：InfluxData 官方文档多处提示】。

基本信息卡（表格）

项	值
开源/闭源	核心开源（1.x/2.x OSS 与 3 Core）；3 Enterprise 与 Cloud 为商业/托管版
开发语言	1.x/2.x：Go ；3.x：Rust（GitHub API 当前主仓库主语言字段返回 Rust，因 3.x 代码已合入 main 分支）【已查证】
当前最新版本（2026-10 口径）	3 线并行：3.x （3 Core/Enterprise，官方文档 2026-09 更新提及 Enterprise 3.11 性能升级，Core 最新补丁号本次未抓取到）；2.x （OSS 最新列至 v2.8.0）；1.x（release notes 最新列至 v1.11.8，官方文档 2026-09 更新页另提及 OSS 1.13.0 发布）【已查证：docs.influxdata.com 各 release notes】
License	1.x/2.x OSS：MIT；3 Core：MIT / Apache-2.0 双许可；GitHub API license 字段：apache-2.0【已查证】
GitHub Star	26,731 stars / 3,476 forks （抓取日期 2026-10-09，信源：`https://api.github.com/repos/influxdata/influxdb`；注：本次 API 响应 updated_at 显示 2023-11-23，疑为缓存快照，Star 数以本次抓取值为准并建议复核）
维护组织	InfluxData, Inc.（商业化公司，开源项目独立治理）
官网 URL	https://www.influxdata.com/
GitHub URL	https://github.com/influxdata/influxdb

主要功能

Line Protocol 高性能写入协议（measurement + tags + fields + timestamp），批量写入。
多查询语言：InfluxQL（类 SQL）、Flux（2.x 主推的数据处理脚本语言）、SQL（3.x 基于 DataFusion 原生支持，兼容 Arrow Flight SQL）。
连续查询/任务（Continuous Queries / Tasks）：定时降采样、预聚合。
Retention Policy（RP）：按时间自动过期删数据；3.x 中为数据保留期配置。
3.x 内置 Python Processing Engine：在库内做数据转换、富化与告警【一方称：InfluxData GA 公告】。
生态组件 Telegraf（采集，400+ 插件）、Chronograf（UI）、Kapacitor（告警/处理）。

核心优势

三条版本线覆盖从轻量单机到分析型列存：老用户平滑升级，新用户直接上 3 Core。
3.x 拥抱开放列存标准（FDAP = Flight / DataFusion / Arrow / Parquet），Parquet 存储可直接对接数据湖/仓，避免格式锁定【一方称：InfluxData 产品页】。
官方宣称 3.x 支持无限基数（unlimited cardinality）、对象存储低成本存储【一方称：InfluxData 产品页/GA 公告】。
开发者体验成熟：单二进制部署、丰富客户端库、Grafana 一等公民支持。
DB-Engines 时序库分类长期排名第一【一方称：InfluxData 对比页，2026-06】。

主要短板

版本线割裂带来迁移成本：1.x→2.x（协议/Flux 变更）、2.x→3.x（TSM→Parquet 存储引擎完全不同）均非无感升级，3 Core 早期仅查询最近 72 小时热数据【已查证：官方 alpha 公告】。
3 Core 单机定位，高可用/水平扩展仅在 Enterprise 商业版，开源版集群能力弱。
2.x 主推的 Flux 采用率不及预期，社区大量回流 InfluxQL/SQL。
官方"无限基数""高性能"等量化宣传缺乏统一第三方基准佐证（本次未查到可引用的第三方评测数字）。

潜在风险与局限性

开源版（3 Core）不含长期存储/读副本/HA，生产级集群必须购买 Enterprise------存在商业化锁定风险。
存储引擎两次重写（TSM→Parquet），旧版本长期维护窗口与社区分叉（如 VictoriaMetrics 等）形成替代压力。
本次抓取的 GitHub API 数据存在时间戳异常（见基本信息卡注），活跃度判断需结合最近 release 节奏复核。

适用场景

DevOps 监控指标与基础设施遥测、应用 APM 事件。
IoT/工业物联网传感器时序数据、电池储能（BESS）、工厂产线等官方参考架构场景。
实时分析与事件追踪；3.x + Parquet 亦适合"时序 + 数据湖"一体化分析。

发展趋势

趋势依据：3.x 于 2025-01 alpha、2025-04 GA、2025-05 代码合并入主仓库、2026-09 Docker latest 切换------官方资源明显向 3.x（Rust+Arrow 列存）集中，1.x/2.x 转为维护线【已查证各官方公告时间线】。主仓库 API 本次抓取 26.7k stars（数值见基本信息卡，响应疑有缓存，未取得 star-history 连续数据点）。
一句话总结：InfluxDB 正从"单机 Go 时序库"转型为"Rust 列存 + 开放数据格式 + 商业集群增值"的平台，3.x 是其未来主线，但开源与商业版的功能分界是长期争议点。

工作原理与核心架构

概念术语：

Measurement：度量容器，类似关系表名/日志中的事件类型。
Tag / Field：Tag 是带索引的元数据标签（高基数过滤维度）；Field 是数值/值本身（不索引）。
Line Protocol ：measurement,tag1=v1 field1=1.0 1609459200000000000 的文本写入格式。
Retention Policy (RP)：数据自动保留与过期策略。
TSM Tree-Structured Merge：1.x/2.x 自有磁盘存储引擎（LSM 类不可变段 + WAL）。
FDAP 堆栈：Flight（RPC/数据传输）、DataFusion（查询引擎）、Arrow（内存列式格式）、Parquet（磁盘列式存储）------3.x 的技术底座。
IOx：3.x 前身/内部代号（iron oxide = Rust 的双关）。

架构与运行原理：

写入路径 ：Line Protocol（或 v2 的 /api/v2/write）→ WAL 先落盘 → 内存缓冲 → 后台compaction。1.x/2.x 压实为 TSM 段；3.x 压实为 Parquet 文件写入本地/对象存储。
存储引擎：1.x/2.x = TSM（Go）；3.x = 内存 Arrow + 磁盘 Parquet，对象存储为一等公民。
查询路径：InfluxQL/Flux（1.x/2.x）；3.x 经 DataFusion 优化器执行 SQL/InfluxQL，Arrow Flight 返回列式结果。
集群拓扑：1.x/2.x OSS 为单机（meta 节点 + data 节点仅企业版集群）；3 Core 单进程；HA/读副本/集群仅 3 Enterprise 与 Clustered 自管商业版【已查证官方公告】。

flowchart TD subgraph Write $"写入路径 (append-only)"$ LP $"Line Protocol /api/v2/write"$ --> WAL $"WAL 先落盘"$ WAL --> Mem $"内存缓冲 (3.x: Arrow 列存)"$ end Mem --> Comp $"后台 Compaction"$ subgraph Storage $"存储层"$ Comp -->|1.x/2.x| TSM $"TSM 不可变段 (Go)"$ Comp -->|3.x| PAR $"Parquet 文件 (本地/对象存储)"$ end subgraph Query $"查询路径"$ Q1 $"InfluxQL / Flux (1.x/2.x)"$ Q2 $"SQL / InfluxQL / Flux (3.x, DataFusion)"$ end Q1 --> TSM Q2 --> PAR TSM --> RP $"Retention Policy: 到期自动删除"$ PAR --> RP RP --> App $"应用 / Grafana / Telegraf 采集"$

写入与查询特性：

写入模式 ：append-only 为主，Line Protocol 批量写入，支持乱序时间戳写入（后台按时间归并段）；push 模型（客户端主动推），同时兼容 Prometheus remote write。
查询特性 ：时间窗口聚合（GROUP BY time()）、连续聚合/任务（定时降采样）、TTL/Retention 自动过期均为原生能力；插值（fill()）在 InfluxQL 中支持；3.x 借助 DataFusion 获得完整 SQL 窗口函数能力。

写入与查询性能特点

本次未取得可引用出处的第三方基准数字（官方宣传的吞吐/压缩比数字均未附可复核口径，按要求不罗列无出处数字）。
可确认的机制性事实：WAL 先行保证写入持久性；3.x 以 Parquet 列存压缩替代 TSM，官方称 Parquet 提供"high-compression storage"【一方称：InfluxData 产品页】；高基数场景 3.x 重构索引以应对 1.x/2.x 的高基数痛点【一方称】。

支持的部署方式

单机二进制（Linux/macOS/Windows）、Docker、Docker Compose（官方发布多个参考架构 compose 包）、Kubernetes（Helm/Operator，主要面向 Enterprise/Cloud）、InfluxDB Cloud 托管（Serverless/Dedicated）、3 Clustered 自管商业集群。

重要依赖

1.x/2.x：Go 运行时（单二进制，无外部依赖）。
3.x：Rust 编译产物（单二进制）；对象存储模式依赖 S3 兼容存储；查询依赖 Apache Arrow/DataFusion/Parquet 生态（已静态链接入二进制）。

生态与集成

采集：Telegraf（400+ 插件）、Fluentd、OpenTelemetry collector。
客户端：官方/社区 Go、Python、JS、Java、Rust（InfluxCommunity/influxdb3-rust 等）库。
可视化：Grafana 原生数据源；3.x 官方 MCP Server 对接 Claude/ChatGPT 等 LLM 工具【已查证：2026-08 官方博客】。
可观测生态：兼容 Prometheus remote read/write、OpenTelemetry、Arrow Flight SQL 对接数据湖。

使用指南（精简）

Linux 安装 （3 Core）：下载单二进制或 docker pull influxdb:3-core，influxdb3 server 启动；官方文档 https://docs.influxdata.com/influxdb3/
Windows ：官方主要提供 Linux/macOS 二进制，Windows 推荐使用 Docker Desktop 运行 influxdb:3-core 镜像。
关键操作示例（3 Core SQL）：

bash 复制代码

# 启动并创建数据库
influxdb3 server --object-store file --data-dir ~/.influxdb3
influxdb3 database create mydb

# 写入一行数据（Line Protocol）
influxdb3 write mydb "cpu,host=server01 usage=0.64"

# SQL 查询最近 1 小时平均使用率
influxdb3 query mydb --language sql "SELECT date_bin('1 hour', time) AS t, avg(usage) FROM cpu WHERE time > now() - 1 hour GROUP BY t"

Q: InfluxDB 1.x、2.x、3.x 该怎么选？

A：新项目直接选 3 Core（Rust+Parquet，官方 2026-09 起 Docker latest 已切到 3 Core）；存量 1.x/2.x 可继续用维护版（1.11.x / 2.8.x），但生产集群与 HA 需求需评估 3 Enterprise------存储引擎不兼容，需做数据迁移而非原地升级【已查证：官方 release notes 与 GA 公告】。

Q: InfluxDB 3 开源版和商业版差在哪？

A：3 Core 是单机"recent-data engine"（早期 alpha 仅热数据查询窗口约 72 小时）；Enterprise 在 Core 之上增加长期查询、读副本、高可用、细粒度安全与集群扩展【一方称：InfluxData alpha/GA 公告】。

Q: InfluxDB 兼容 Prometheus 生态吗？

A：兼容。1.x/2.x 原生支持 Prometheus remote read/write 接收与暴露；3.x 亦提供 Prometheus 远程存储集成，因此 Prometheus 采集端可直接把 InfluxDB 当长期后端【已查证：官方文档生态页】。

参考文献

3.3 【OpenGemini】（华为云开源、兼容 InfluxDB 生态的云原生分布式时序数据库）

OpenGemini 是由华为云数据库创新实验室 自行设计、研发并面向全球开源的一款【云原生分布式时序数据库】。主要面向物联网和运维监控等场景，提供海量时序数据库处理和分析的开源解决方案，以进一步降低企业运营和运维成本，提升产品质量和生产效率。
多模数据库 作为一种新兴的数据管理解决方案，正在受到越来越多的关注。而华为云多模数据库 GeminiDB 基于云原生数据库优势，让企业应用更智能、更高效。

2024年，华为云 NoSQL 数据库研发总监余汶龙通过直播（链接见文末）的方式，于2024年03月在直播间分享了《华为云多模数据库 GeminiDB 的技术架构及应用实践》，对 GeminiDB 的技术特性、架构优势等进行了全方位解读。

产品介绍

产品定位 ：openGemini 是一款开源、高性能、云原生分布式时序数据库 ，定位为可观测性（Observability）场景下的指标/日志/追踪数据底座，兼容 InfluxDB Line Protocol 与 InfluxQL 生态。【已查证：openGemini 官方文档】
诞生背景与原因 ：其内核源自华为云 GaussDB(for Influx)，最初作为华为云基础设施运维监控底座。为回馈社区、摆脱对单一厂商商业版的依赖，华为云数据库创新 Lab 将该内核对外开源并命名为 openGemini。【已查证：华为云官方新闻】
解决的核心问题 ：在高并发写入、亿级时间线、PB 级数据规模下，提供水平扩展、低存储成本、毫秒级查询的时序数据管理能力，同时保持与 InfluxDB 工具链的兼容性，降低迁移成本。【已查证：openGemini 官方文档】
URLs：(官方)

官网：http://openGemini.org

https://www.huaweicloud.com/product/geminidb.html

文档: https://docs.opengemini.org/zh/

GitHub：https://github.com/openGemini/openGemini | https://github.com/openGemini

Gitee: https://gitee.com/src-openeuler/openGemini

第三方URLs

云原生分布式多模架构：华为云多模数据库 GeminiDB 架构与应用实践 - CSDN

华为云GeminiDB新版本发布：全面支持Redis 6.2 - Zhihu

【干货分享】华为云多模数据库 GeminiDB 架构与应用实践直播问答实录 - 东方财富网

openGemini正式加入openEuler SIG-DB - 百度

发展历程(V1)

GeminiDB 引领 NoSQL 存算分离架构，持续战略投入，打造世界级数据库。

GeminiDB 发展历程具体如下图所示：

结合 GeminiDB 发展历程，我们将其成就归纳为以下几点：

国内第一款：存算分离架构 NoSQL 数据库。

100% 兼容：5 款最热门生态数据库------------Redis、MongoDB、Cassandra、DynamoDB、InfluxDB。

0 秒 RPO：3AZ 高可用实例，0 秒 RPO，数据"0"丢失。

RTO 10 秒：实例故障恢复，RTO 10 秒内完成。

99.995% SLA：高可用双活实例承诺，99.995% SLA，服务可用性保证远超国内其他厂商。

发展历程(V2)

2021 年 ：openGemini 技术成熟，成为华为云基础设施运维监控底座，兼容 InfluxDB 生态。【一方称：华为云公开分享 PDF】
2022 年 6 月 16 日 ：在华为伙伴暨开发者大会 2022 上，华为云宣布将 GaussDB 时序时空数据库内核开源，命名为 openGemini，全部内核源码正式开放。【已查证：华为云官方新闻】
2022 年 10 月 ：发布 v0.2.0，支持 KubeEdge、实时分析框架。【已查证：openGemini ROADMAP】
2023 年 7 月 ：发布 v1.1.0，引入全文索引、数据副本（可靠性）、非分区特性。【已查证：openGemini ROADMAP】
2023 年 11 月 ：发布 v1.2.0，增强高基数处理、连续查询能力。【已查证：openGemini ROADMAP】
2024 年 7 月 9 日 ：CNCF（云原生计算基金会）正式接纳 openGemini 为官方项目（Sandbox），成为 CNCF 旗下可观测性专用数据库项目。【已查证：华为云官方新闻】
2025 年 12 月 24 日 ：发布 v1.5.1。【已查证：pkg.go.dev 版本列表】
2026 年 1 月 9 日 ：发布 v1.5.2（当前最新稳定版）。【已查证：pkg.go.dev v1.5.2】
2026 年 3 月 21 日 ：发布 v1.5.3-rc5（发布候选版，截至 2026-10-09 未查到 v1.5.3 正式版发布记录）。【已查证：pkg.go.dev 版本列表】

基本信息卡（表格）

项	值
开源/闭源	开源（核心内核全部开源）【已查证：华为云官方新闻】
开发语言	Go【已查证：pkg.go.dev】
当前最新版本（2026-10 口径）	稳定版 v1.5.2（2026-01-09 发布）；v1.5.3-rc5（2026-03-21，RC）【已查证：pkg.go.dev】
License	Apache License 2.0 【已查证：pkg.go.dev License: Apache-2.0】
GitHub Star（截至 2026-10-09）	约 1.2k （shields.io 徽章实时抓取，四舍五入值；抓取日期 2026-10-09，信源 https://img.shields.io/github/stars/openGemini/openGemini.json ）
GitHub Fork（截至 2026-10-09）	约 175 （同上，信源 https://img.shields.io/github/forks/openGemini/openGemini.json ）
维护组织	openGemini 社区（华为云数据库创新 Lab 发起/捐赠，CNCF Sandbox 项目）【已查证：华为云官方新闻】
官网 URL	https://docs.opengemini.org/zh/
GitHub URL	https://github.com/openGemini/openGemini

注：GitHub API 实时接口在本次调研中因网络限流（403）无法直连，Star/Fork 数采用 shields.io 实时徽章接口（四舍五入到百位），精确个位数未获取到。

主要功能

高并发写入与查询 ：支持亿级时间线、PB 级数据管理，官方宣称每秒千万级数据写入、毫秒级查询响应。【一方称：openGemini 官方文档】
MPP 分布式架构 ：由 ts-sql、ts-meta、ts-store 三类组件组成，各组件独立水平扩展，支持 100+ 节点集群。【已查证：openGemini 集群架构文档】
InfluxDB 生态兼容 ：兼容 InfluxDB Line Protocol 写入协议与 InfluxQL 查询语言，支持 InfluxDB v1 API、Prometheus Remote Read/Write API，可直接对接现有 InfluxDB/Telegraf/Prometheus 工具链。【已查证：openGemini ROADMAP】
保留策略（Retention Policy, RP） ：按数据库/保留策略设置数据自动过期清理，实现 TTL。【已查证：openGemini 连续查询文档】
连续查询（Continuous Query, CQ） ：CREATE CONTINUOUS QUERY 语法，按时间窗口自动聚合原始数据并写入新 measurement，配合 RP 实现多级降采样。【已查证：openGemini 连续查询文档】
流计算/窗口聚合 ：ts-store 侧内置 Stream + Window 五级 pipeline，支持实时窗口聚合计算。【已查证：openGemini Stream 文档】
全文索引与高基数 ：v1.1.0 起支持全文索引，v1.2.0 起增强高基数（high cardinality）时间线处理。【已查证：openGemini ROADMAP】
数据副本：v1.1.0 起支持数据多副本，提升可靠性。【已查证：openGemini ROADMAP】

核心优势

云原生 + 存算分离式 MPP 架构 ：ts-sql 无状态可独立扩展，ts-store 独立扩展，ts-meta 管理元数据，集群各层可按需伸缩。【已查证：openGemini 集群架构文档】
InfluxDB 生态无缝兼容：直接复用 Line Protocol、InfluxQL、Telegraf、Grafana、Prometheus remote storage，迁移成本极低。【已查证：openGemini ROADMAP / 官方文档】
高压缩比 ：采用列式存储 + LSM Tree，官方宣称同等数据量下存储成本仅为关系型数据库的 1/20、NoSQL 的 1/10。【一方称：openGemini 官方文档】
CNCF 项目背书：2024 年进入 CNCF Sandbox，社区治理中立化，降低厂商锁定顾虑。【已查证：华为云官方新闻】

主要短板

社区规模较小：GitHub Star 约 1.2k（2026-10-09），相比 InfluxDB、TDengine（25k 量级）社区贡献者与第三方集成生态明显薄弱。【已查证：shields.io 实时抓取】
企业级生产案例公开度不足：除华为云内部运维监控底座外，公开的外部大规模生产落地案例较少。
3.x 存算分离云原生能力尚在演进：当前版本仍以本地存储（shared-nothing）为主，存算分离的云原生形态截至 2026-10 未查到正式 GA 发布。
查询生态以 InfluxQL 为主：对标准 SQL 的支持弱于 TDengine、TimescaleDB 等采用标准 SQL 的产品。

潜在风险与局限性

License 为 Apache 2.0：商业友好，无 AGPL 那样的网络传染性风险，但也意味着厂商对商业版的投入需依赖云服务（华为云 GeminiDB Influx 接口）变现，长期可持续性取决于商业版收入。【已查证：pkg.go.dev License】
高基数场景仍在完善：高基数（如千万级唯一设备 ID）性能在 v1.2.0 才增强，成熟度需第三方生产验证。
Windows 仅推荐开发调试 ：官方明确 Windows 版本仅建议用于项目开发与调试，生产环境推荐 Linux。【已查证：openGemini 安装文档】

适用场景

IT 运维监控/可观测性：指标（Metrics）、日志（Log）、追踪（Trace）数据的统一存储后端，兼容 Prometheus remote storage。【已查证：openGemini 官方文档】
物联网/工业互联网时序数据采集：高频传感器数据写入与聚合查询。
InfluxDB 替代/扩容场景：已有 InfluxDB 技术栈、需水平扩展且希望保持生态兼容的团队。
华为云生态用户：使用华为云基础设施、希望自建或混合部署时序数据底座的企业。

发展趋势

版本节奏 ：从 2022 年 v0.x 到 2026 年 v1.5.x，保持约每年 1-2 个 minor 版本迭代（v1.1.0 2023.07 → v1.2.0 2023.11 → v1.5.2 2026.01），节奏稳定但不算高频。【已查证：openGemini ROADMAP + pkg.go.dev 版本列表】
Star 趋势：本次调研抓取约 1.2k Star（2026-10-09），相比 2024 年 CNCF 入驻时有所增长，但绝对量级在时序数据库赛道中仍偏小。shields.io 未提供历史曲线，截至 2026-10 未查到 star-history 公开数据点。
社区方向：CNCF Sandbox 项目，重点投入可观测性（Metrics/Log/Trace 一体化）、高基数、实时分析。
一句话总结：openGemini 正从"华为云内部监控底座开源版"向"CNCF 中立的云原生可观测性时序数据库"演进，生态兼容是其最大卖点，但社区规模与生产案例积累仍需时间。

工作原理与核心架构

概念术语

ts-sql ：无状态 SQL/接口层组件，对外提供统一读写入口（端口 8086），负责协议解析、查询计划生成、数据按时间线哈希分发与结果聚合。【已查证：openGemini 集群架构文档】
ts-meta：元数据管理组件，存储数据库、表、数据分区、保留策略、集群节点等元信息。【已查证：同上】
ts-store：数据存储节点，基于 LSM Tree，列式存储，数据追加写入，负责实际数据存储与子查询执行。【已查证：同上】
LSM Tree ：Log-Structured Merge Tree，数据先写内存表再批量刷盘为 SSTable 文件，openGemini 数据文件格式为 .tssp。【已查证：GOTC 2023 openGemini 技术分享 PDF】
时间线（Timeline）：一条连续的指标序列（由 measurement + tags 唯一标识），ts-sql 按时间线名称哈希后分发到对应 ts-store。【已查证：集群架构文档】
保留策略（Retention Policy, RP）：控制数据保留时长，到期自动清理，是 TTL 的实现机制。【已查证：连续查询文档】
连续查询（Continuous Query, CQ）：定时按时间窗口聚合原始数据并写入结果表，实现降采样。【已查证：连续查询文档】
倒排索引（Inverted Index） ：ts-store 侧用于按 tag 快速定位时间线，支撑高基数过滤。【已查证：KubeCon 2023 openGemini OTel 分享 PDF】

架构与运行原理

写入路径 ：客户端 → ts-sql（校验数据格式 → 按时间线名称哈希取模 → 转发到对应 ts-store 节点）→ ts-store 追加写入 LSM Tree（先内存后刷盘）。【已查证：集群架构文档】
存储引擎 ：LSM Tree + 列式存储，数据文件 .tssp，append-only 追加写入，后台 compaction 合并。【已查证：GOTC 2023 PDF】
查询路径：客户端 → ts-sql（解析 InfluxQL → 生成分布式查询计划 → 将子查询分发到涉及的 ts-store）→ ts-store 通过倒排索引定位时间线 → 读取数据并按条件过滤 → 返回 ts-sql 聚合结果 → 返回客户端。【已查证：集群架构文档】
集群拓扑 ：ts-sql 无状态多副本（水平扩展）、ts-meta 多副本（元数据高可用）、ts-store 多副本（数据分片 + 水平扩展），整体 shared-nothing MPP 架构。单机版 ts-server 二进制 = 一个 ts-sql + 一个 ts-meta + 一个 ts-store。【已查证：openGemini 快速开始文档】

flowchart TD subgraph Client $"客户端 / 采集端"$ C1 $Telegraf / Prometheus / InfluxDB Client$ end subgraph SQLLayer $"ts-sql 层（无状态，水平扩展）"$ TSQL1 $ts-sql #1\Interface/Parser/Optimizer/Executor$ TSQL2 $ts-sql #2$ TSQLn $ts-sql ...$ end subgraph MetaLayer $"ts-meta 层（元数据管理）"$ TMETA $ts-meta\数据库/表/分区/RP/节点元数据$ end subgraph StoreLayer $"ts-store 层（存储计算，水平扩展）"$ subgraph TS1 $"ts-store #1"$ SE1 $Storage Engine\Memory / Index / LSM$ ME1 $Metric/Trace Engine$ end subgraph TS2 $"ts-store #2"$ SE2 $Storage Engine\Memory / Index / LSM$ ME2 $Metric/Trace Engine$ end subgraph TSn $"ts-store ..."$ SEn $Storage Engine$ end end C1 -->|Line Protocol / HTTP :8086| TSQL1 C1 --> TSQL2 TSQL1 -->|读取元数据| TMETA TSQL2 --> TMETA TSQLn --> TMETA TSQL1 -->|按时间线哈希分发写入| SE1 TSQL1 -->|按时间线哈希分发写入| SE2 TSQL2 -->|子查询下发| SEn SE1 -->|结果聚合| TSQL1 SE2 -->|结果聚合| TSQL1

写入模式与查询特性

写入模式：append-only 追加写入；批量写入（HTTP Line Protocol，端口 8086）；兼容 InfluxDB Line Protocol；乱序数据由 LSM Tree compaction 处理（官方未单独强调乱序优化策略，截至 2026-10 未查到专门乱序处理章节）。【已查证：集群架构文档 + 端口文档】
时间窗口聚合 ：支持 GROUP BY time() 窗口聚合（InfluxQL 语法）。【已查证：连续查询文档示例】
连续聚合 ：CREATE CONTINUOUS QUERY 定时窗口聚合写入结果表。【已查证：连续查询文档】
降采样 ：配合多级保留策略（RP）+ 连续查询，实现原始数据 → 1h 聚合 → 1d 聚合的多级降采样，不同粒度数据保留不同时长。【已查证：墨天轮 openGemini 多级降采样】
TTL：通过 Retention Policy 的 duration 设置数据自动过期清理。【已查证：连续查询文档】
插值对齐 ：截至 2026-10 未查到 openGemini 官方文档明确支持 INTERP 插值或线性对齐语法（InfluxQL 生态中通常由应用层或 Grafana 处理）。

写入与查询性能特点

写入吞吐 ：官方宣称"每秒千万级数据写入"、"每天万亿指标数据写入"。【一方称：openGemini 官方文档 + 华为云官方新闻】
对比 InfluxDB（GOTC 2023 官方分享数据） ：写入吞吐 openGemini v1.0.1 约 377,581 points/s（140 MB/s），InfluxDB 2.x 约 871,960 points/s（31 MB/s）------即 openGemini 单条写入点数低于 InfluxDB，但带宽（MB/s）约为 InfluxDB 的 4.5 倍（因单条数据更大）。【一方称：GOTC 2023 PDF】
查询性能：官方宣称相比 InfluxDB，简单查询性能提升 2-5 倍，复杂查询性能提升 60 倍。【一方称：openGemini 官方文档】
压缩比 ：官方宣称同等数据量下存储成本仅为关系型数据库的 1/20、NoSQL 的 1/10（即约 20:1 压缩比）。【一方称：openGemini 官方文档】
高基数处理 ：v1.2.0 起增强高基数能力，KubeCon 2023 分享称倒排索引相比搜索引擎方案内存索引空间减少 65%、索引构建时间减少 60%。【一方称：KubeCon 2023 PDF】
注：以上性能数字均为厂商官方自测/分享口径（一方称），截至 2026-10 未查到独立第三方权威评测。

支持的部署方式

单机部署 ：ts-server 二进制（内置 ts-sql + ts-meta + ts-store），适合开发调试。【已查证：快速开始文档】
集群部署 ：通过 Gemix 工具一键在一台或多台虚拟机/物理机上部署 openGemini 集群。【已查证：openGemini 安装文档】
Windows：支持 Windows（验证版本 Win11），官方明确推荐仅用于项目开发与调试。【已查证：安装文档】
Linux：生产环境推荐，提供二进制包。【已查证：安装文档】
容器化/K8s：兼容 KubeEdge（v0.2.0 起），截至 2026-10 未查到官方 Helm Chart 的明确 GA 文档。
云托管 ：华为云 GeminiDB Influx 接口为 openGemini 的商业云托管版。【已查证：华为云 GeminiDB 产品页】

重要依赖

运行时依赖 ：Go 语言开发，单机/集群部署为独立二进制，无外部数据库依赖；依赖本地文件系统存储 .tssp 数据文件。【已查证：GOTC 2023 PDF + pkg.go.dev】
端口：ts-sql 对外服务端口 8086（与 InfluxDB 一致，便于无缝切换）。【已查证：openGemini 端口文档】

生态与集成

客户端驱动 ：官方提供 Go 客户端 opengemini-client-go（v0.9.2，2026-01-22）。【已查证：pkg.go.dev opengemini-client-go】
InfluxDB 生态：直接兼容 InfluxDB v1 API、Line Protocol、InfluxQL，可对接 Telegraf。【已查证：ROADMAP】
Prometheus 生态：支持 Prometheus Remote Read/Write API，可作为 Prometheus 远端存储。【已查证：ROADMAP】
可视化：通过 InfluxDB 数据源接口对接 Grafana（复用 InfluxDB 数据源插件）。【已查证：官方文档 InfluxDB 兼容说明】
大数据生态：截至 2026-10 未查到官方 Flink/Spark Connector，KubeEdge 边缘计算集成为 v0.2.0 起支持。
周边工具：ts-monitor 监控工具、ts-cli 命令行客户端。【已查证：ROADMAP + 构建文档】

使用指南（精简）

Linux 安装 ：从 GitHub Releases 下载对应版本二进制包，解压后启动 ts-server（单机）或通过 Gemix 部署集群；官方文档：https://docs.opengemini.org/zh/guide/quick_start/get_started.html
Windows 安装 ：下载 Windows 版二进制（Win11 验证），启动 ts-server，仅推荐开发调试。【已查证：安装文档】
关键操作示例（InfluxQL 语法，端口 8086）：

sql 复制代码

-- 1. 建库（含保留策略，30天自动过期）
CREATE DATABASE monitor WITH DURATION 30d

-- 2. 写数据（Line Protocol，measurement=temperature, tags=device_id=1, field=value=23.5）
curl -i -XPOST "http://localhost:8086/write?db=monitor" \
  --data-binary "temperature,device_id=1 value=23.5 1696800000000000000"

-- 3. 查询最近1小时平均温度（按10分钟窗口聚合）
SELECT mean(value) FROM temperature 
WHERE device_id='1' AND time > now() - 1h 
GROUP BY time(10m)

Q: openGemini 和 InfluxDB 是什么关系？可以直接替代吗？

A: openGemini 兼容 InfluxDB Line Protocol、InfluxQL 和 v1 API，理论上可直接替换 InfluxDB 作为后端（端口同为 8086），Telegraf 等采集端无需修改。但 openGemini 不支持 InfluxDB 2.x 的 Flux 查询语言，且压缩比、高基数等特性需实际业务验证。【已查证：openGemini ROADMAP + 官方文档】

Q: openGemini 是华为公司的商业产品吗？开源版和商业版有什么区别？

A: openGemini 是 Apache 2.0 协议的开源项目，由华为云数据库创新 Lab 发起并捐赠给 CNCF。商业版为华为云 GeminiDB Influx 接口（托管云服务），开源版内核与商业版同源，企业可自行部署使用。【已查证：华为云官方新闻 + 华为云 GeminiDB 产品页】

Q: openGemini 适合生产环境大规模部署吗？

A: openGemini 支持 100+ 节点 MPP 集群，已在华为云内部作为运维监控底座大规模运行。但对外公开的第三方生产案例较少，GitHub Star 约 1.2k，社区规模在时序数据库赛道中偏小，生产落地建议先在非核心业务验证。【已查证：官方文档 + shields.io】

参考文献

3.4 【TDengine】（涛思数据开源、面向 IoT/工业的高性能云原生时序数据库）

产品介绍

产品定位 ：TDengine 是一款开源、高性能、云原生、AI 驱动的时序数据库（TSDB） ，面向物联网、工业互联网、车联网、IT 运维、金融等场景，除核心时序存储外还内置缓存、数据订阅、流式计算等功能。【已查证：TDengine 产品简介】
诞生背景与原因 ：创始人陶建辉（Jeff Tao）于 2016 年底看到万物互联时代需要高效处理海量时序数据的引擎，遂创立涛思数据。2018 年 8 月发布首个商业版，2019 年 7 月将内核开源，以开源换取市场采用与生态积累。【已查证：涛思数据官方博客】
解决的核心问题 ：以一个极简系统解决时序数据的高并发写入、高效压缩存储、实时聚合查询、数据订阅与缓存，替代传统基于 Hadoop/Spark 或关系型数据库的时序大数据栈。【一方称：涛思数据 TCO 文档】
官方链接 ：
- 官网：https://www.taosdata.com/ / https://tdengine.com/
- GitHub：https://github.com/taosdata/TDengine

发展历程

2017 年 6 月 ：涛思数据正式成立（获明势资本、蛮子基金天使投资）。【已查证：涛思数据官方博客】
2018 年 8 月：发布 TDengine 第一个商业版。【已查证：同上】
2019 年 7 月 12 日 ：在深圳全球架构师大会上，陶建辉宣布将 TDengine 单机版内核（存储和计算引擎）100% 开源，采用 AGPL 协议。【已查证：涛思数据官方新闻】
2020 年 8 月 ：发布 2.0 版本，将集群版开源。【已查证：TDengine 开源说明】
2021 年 5 月 ：完成 4700 万美元 B 轮融资（经纬中国领投，红杉中国、GGV、index 跟投）。【已查证：TDengine 官方新闻】
2022 年 8 月 23 日 ：发布 TDengine 3.0，定位为真正的云原生时序数据库，存算分离、核心代码全部开源（37 万行产品代码 + 23 万行测试代码）。【已查证：TDengine 官方博客 + 涛思数据】
2025 年 10 月 16 日 ：发布 3.3.8，增强多级小物化视图（SMA）、AI 数据能力、安全性。【已查证：TDengine 3.3.8 Release Notes】
2026 年 1 月 6 日 ：发布 TDengine TSDB 3.4，内置时序预测与异常检测 AI Agent。【已查证：TDengine 3.4 Release Notes】
2026 年 4 月 30 日 ：发布 ver-3.4.1.6（截至本次调研查到的最新 release）。【已查证：DEV.co TDengine 页面】
2026 年 7 月 ：TDengine 战略升级为"AI 原生工业数据底座"，宣布完整 All-in-One 版本对 5000 测点以内的部署永久免费。【已查证：TDengine 免费永久公告】

基本信息卡（表格）

项	值
开源/闭源	开源（核心服务器 taosd 开源）+ 商业版（企业版）双轨
开发语言	C （核心引擎）【已查证：DEV.co】
当前最新版本（2026-10 口径）	ver-3.4.1.6（2026-04-30 发布）；3.4 系列起点 3.4.0（2026-01-06）【已查证：DEV.co + 3.4 Release Notes】
License	AGPLv3 （核心服务器 taosd）；taosAdapter 及连接器采用 MIT 【已查证：TDengine 开源页 + 涛思数据】
GitHub Star（截至 2026-10-09）	约 25k （shields.io 实时抓取，四舍五入值；涛思官网称 24.7K，截至 2026-09-30）；抓取日期 2026-10-09，信源 https://img.shields.io/github/stars/taosdata/TDengine.json
GitHub Fork（截至 2026-10-09）	约 5k （同上，信源 https://img.shields.io/github/forks/taosdata/TDengine.json ）
维护组织	涛思数据（TAOS Data），创始人陶建辉【已查证】
官网 URL	https://www.taosdata.com/ / https://tdengine.com/
GitHub URL	https://github.com/taosdata/TDengine

注：GitHub API 实时接口在本次调研中因网络限流（403）无法直连，Star/Fork 数采用 shields.io 实时徽章接口（四舍五入到千位），精确个位数未获取到。涛思官网 2026-09-30 页面显示 24.7K Star。

主要功能

超级表（STable）+ 子表数据模型 ：一张超级表代表一类采集点（schema 相同），每个具体设备自动创建一张子表，子表携带静态标签（tags），支持按标签过滤做多表聚合查询。【已查证：TDengine 架构文档】
标准 SQL 查询：完整 SQL 支持（TAOS SQL），建表/查询/聚合与传统关系型数据库语法接近，学习成本低。【已查证：TDengine 产品简介】
高并发写入 ：面向 IoT 海量设备数据写入，内置 WAL 保证数据不丢。【已查证：TDengine WAL 机制文档】
数据 TTL 与多级存储 ：通过 KEEP（keep0/keep1/keep2）配置数据保留时长，支持多级存储层自动迁移。【已查证：TDengine RSMA 文档】
流式计算（Stream） ：3.0 起用 CREATE STREAM 替代 2.x 连续查询，支持窗口聚合（滚动窗口/会话窗口）实时计算并写入结果表。【已查证：TDengine Stream 文档 + 语法变更文档】
降采样存储（RSMA）：数据由低存储层级向高存储层级迁移时自动完成降采样物化。【已查证：RSMA 文档】
插值与对齐 ：INTERP 函数 + FILL(PREV/NULL/LINEAR/NEXT/VALUE) 支持时间截面插值与线性对齐。【已查证：TDengine 函数文档】
无模式写入（Schemaless） ：兼容 InfluxDB Line Protocol、OpenTSDB Telnet/JSON 协议，写入时自动建表。【已查证：TDengine 无模式写入文档】
数据订阅 ：支持变更数据捕获（CDC）与消息订阅，对接下游 Kafka/Flink。【已查证：TDengine 2026 白皮书】
缓存：内置每个子表最新数据点缓存，无需额外 Redis。【一方称：TDengine 产品简介】
AI 能力 ：3.4 起内置时序预测与异常检测 AI Agent。【已查证：3.4 Release Notes】
可视化 ：内置 taosExplorer 可视化管理工具、taosKeeper 监控组件。【已查证：taosExplorer 指南】

核心优势

超高写入吞吐与压缩比 ：官方 TSBS 基准显示写入性能为 InfluxDB 的 3.0-10.6 倍，压缩比达 9.89:1 至 87.64:1（InfluxDB 为 3.39:1-7.44:1）。【一方称：TDengine TSBS 对比】
极简架构：一个系统涵盖存储、缓存、消息订阅、流式计算，无需搭配 Kafka + Redis + Flink。【一方称：TDengine 产品简介】
标准 SQL + 超级表模型：设备建模直观（一设备一表），标签索引支持高基数过滤，查询语言学习成本低。
云原生存算分离（3.0+） ：计算节点（Qnode）与数据节点（Dnode）分离部署，可独立扩缩容，VGroup 基于 Raft 保证高可用。【已查证：TDengine 分布式架构】
国产化与工业落地：覆盖制造、能源、电力、化工等关键领域，客户遍布全球。【一方称：涛思数据官网】

主要短板

License 为 AGPLv3 ：对网络访问式部署有源代码传染性要求，商业集成需谨慎评估；相比 Apache 2.0（openGemini）更严格。【已查证：GreptimeDB 对比 + TDengine 开源页】
可观测性生态弱于 Prometheus/InfluxDB ：不原生支持 PromQL、OpenTelemetry，日志/追踪接入能力有限。【一方称：GreptimeDB 对比】
2.x 到 3.0 语法不兼容 ：3.0 废除了连续查询（改为 Stream）、授权语法等，升级需迁移改造。【已查证：TDengine 语法变更文档】
AGPL 对云厂商不友好 ：官方自述选择 AGPL 而非 Apache 的唯一目的就是阻止云厂商免费使用，这限制了部分云厂商集成意愿。【已查证：涛思数据开源说明】

潜在风险与局限性

AGPLv3 合规风险：若将 TDengine 开源版嵌入 SaaS 产品对外提供服务，AGPL 要求开放对应源代码，商业闭源产品需购买企业授权。【已查证：TDengine 开源页】
开源版与企业版功能差异：集群高可用、企业级安全、备份等能力在开源版与企业版间存在差异，生产大规模部署需确认开源版能力边界。
社区驱动 vs 公司主导 ：虽然开源，但核心开发由涛思数据公司主导，社区贡献者占比相对有限，公司战略转向（如 2026 年转向 AI 工业数据底座）可能影响开源版演进方向。【一方称：TDengine 战略升级文章】

适用场景

工业物联网（IIoT） ：传感器、PLC、OPC-UA 数据采集与实时监控。【已查证：PLC+OPC+TDengine 方案】
能源/电力/化工：智能电表、电网设备、风电光伏数据时序存储。【一方称：能源行业报告】
车联网：车辆传感器高频数据接入与分析。
IT 运维监控：服务器/应用指标监控与告警（通过 taosAdapter 对接 Prometheus/Grafana）。
金融交易时序数据：行情数据、交易流水存储。
数字孪生/工业数据底座 ：2026 年起定位延伸至 AI 原生工业数据平台。【已查证：TDengine 免费永久公告】

发展趋势

版本节奏：2019 年开源 1.x → 2020 年 2.0（集群）→ 2022 年 3.0（云原生）→ 2026 年 3.4（AI Agent），大版本约 2 年一代，小版本持续迭代（3.3.8 2025.10 → 3.4.0 2026.01 → 3.4.1.6 2026.04）。【已查证：TDengine 各 Release Notes】
Star 趋势 ：2019 年开源时 Star 快速破万（2020 年初），2021 年 7 月达 15.5k，2026 年约 25k，7 年间增长约 2.5 倍，近年增速趋缓。【已查证：涛思数据 2021 年新闻 + shields.io 2026-10-09】
战略方向 ：2026 年 3 月起从"时序数据库"升级为"AI 原生工业数据底座"，内置 AI Agent、工业本体建模、KPI 报表等，从单一数据库向工业数据平台延伸。【已查证：TDengine 战略升级】
一句话总结：TDengine 是国产时序数据库中商业化最成功、GitHub Star 最高的项目，正从高性能时序库向 AI 驱动的工业数据平台演进，AGPL 协议是其主要采用门槛。

工作原理与核心架构

概念术语

Dnode（Data Node） ：物理节点上运行的 taosd 实例，是所有逻辑节点的运行载体。【已查证：TDengine 2026 白皮书】
Vnode（Virtual Node） ：数据分片单元，每个 vnode 有独立的线程、内存、存储目录，管理特定时间范围的数据分片，内置 LSM 存储引擎与 WAL。【已查证：TDengine 分布式架构】
Mnode（Management Node）：集群管理节点，负责元数据管理、节点管理、负载均衡。【已查证：白皮书】
Qnode（Query Node）：查询计算节点，无状态，跨库处理查询请求，可水平扩展。【已查证：白皮书】
Snode（Stream Node）：流处理节点，负责流式计算任务。【已查证：白皮书】
VGroup（Virtual Node Group） ：一组 vnode（通常 3 个）通过 Raft 协议组成副本组，保证数据高可用，写入走 Leader，查询可走 Follower。【已查证：涛思数据云原生文档】
超级表（STable）：一类采集点的模板表，定义 schema 与标签结构，不存实际数据。【已查证：架构文档】
子表（Subtable）：每个具体设备对应一张子表，继承超级表 schema，携带自己的静态标签值，实际数据落在子表。【已查证：架构文档】
标签（Tags）：子表的静态元数据（如设备 ID、位置、型号），建立标签索引以支持按标签过滤聚合。【已查证：架构文档】
WAL（Write-Ahead Log） ：预写日志，vnode 写入时先记 WAL 再写内存表，保证宕机不丢数据。【已查证：WAL 机制文档】

架构与运行原理

写入路径 ：客户端 → taosAdapter/taosd → 路由到对应 vnode Leader → 写 WAL → 写 MemTable（内存表）→ MemTable 满后刷盘为 SSTable 文件（按时间有序、非重叠）→ 后台 compaction 合并。【已查证：TDengine LSM 存储引擎文档 + WAL 文档】
存储引擎：LSM Tree，MemTable → SSTable，因时序数据按时间追加且有序，compaction 比通用 LSM 更简单（SSTable 天然时间维度不重叠）。【已查证：LSM 存储引擎文档】
查询路径：客户端 → Qnode（解析 SQL、生成查询计划）→ 分发到涉及的 VGroup（Leader 或 Follower vnode）→ vnode 读取 SSTable 数据并执行子查询 → Qnode 聚合结果 → 返回客户端。【已查证：白皮书】
集群拓扑：多个 Dnode 组成集群，内部按 vnode 分片 + VGroup Raft 副本；Mnode 负责元数据与调度，Qnode 无状态扩展查询能力，Snode 处理流计算。3.0 起计算与存储可分离部署。【已查证：白皮书 + 分布式架构文档】

flowchart TD subgraph Client $"客户端 / 采集端"$ C1 $应用程序 / Telegraf / MQTT / OPC-UA$ end subgraph Adapter $"接入层"$ TA $taosAdapter\REST / WebSocket / schemaless$ end subgraph Mgmt $"管理与计算层"$ MNODE $Mnode\元数据/节点管理/负载均衡$ subgraph QNodes $"Qnode 查询计算层（无状态，水平扩展）"$ Q1 $Qnode #1$ Q2 $Qnode #2$ end SNODE $Snode\流式计算$ end subgraph DataLayer $"数据节点层（Dnode）"$ subgraph VG1 $"VGroup #1（Raft 副本）"$ V1L $vnode Leader\MemTable/SSTable/WAL$ V1F $vnode Follower$ V1F2 $vnode Follower$ end subgraph VG2 $"VGroup #2（Raft 副本）"$ V2L $vnode Leader$ V2F $vnode Follower$ V2F2 $vnode Follower$ end end C1 --> TA TA -->|写入请求| V1L TA -->|写入请求| V2L C1 -->|SQL 查询| Q1 Q1 --> MNODE Q1 -->|子查询| V1L Q1 -->|子查询| V2L Q2 --> V1F Q2 --> V2F SNODE -->|流计算结果写回| V1L

写入模式与查询特性

写入模式：append-only 追加写入；批量写入（原生连接/JDBC/REST/schemaless Line Protocol）；WAL 保证持久性；乱序写入由 vnode 内部处理（SSTable 按时间排序，compaction 时合并）。【已查证：LSM 存储引擎文档】
时间窗口聚合 ：INTERVAL(1m) 滚动窗口聚合、SESSION(ts, tol) 会话窗口。【已查证：特色查询文档】
连续聚合/流式计算 ：3.0 起用 CREATE STREAM ... INTERVAL(1m) 实现实时窗口聚合写入结果表（替代 2.x 连续查询）。【已查证：Stream 处理文档】
降采样 ：RSMA（Reduced Storage Materialized Aggregate）在数据向高存储层级迁移时自动降采样，由 KEEP 多级保留控制。【已查证：RSMA 文档】
TTL ：数据库级 KEEP keep0,keep1,keep2 设置多级数据保留时长，到期自动删除。【已查证：RSMA 文档】
插值对齐 ：INTERP(field) ... FILL(LINEAR/PREV/NEXT/NULL/VALUE) 支持时间截面插值与等间隔对齐。【已查证：函数文档】

写入与查询性能特点

写入吞吐 ：官方 TSBS 基准显示 DevOps 场景写入性能为 InfluxDB 的 3.0-10.6 倍，IoT 场景为 InfluxDB 的 6-11 倍；第三方评测称单机写入可达 100 万+ points/s。【一方称：TDengine TSBS 对比 + 掘金评测】
压缩比 ：官方 TSBS 数据显示 TDengine 压缩比 9.89:1 至 87.64:1，InfluxDB 为 3.39:1 至 7.44:1；实际项目中存储占用可低至原始数据的 10%-17%。【一方称：TSBS 压缩对比 + 能源行业报告】
查询延迟：官方称查询延迟仅为 InfluxDB 的 1/8（实际项目口径）。【一方称：能源行业报告】
高基数处理：通过超级表 + 标签索引 + 一设备一子表模型，天然避免高基数时间线合并问题（每个子表独立存储）。【已查证：架构文档】
注：以上性能数字除标注"已查证"外均为厂商官方 TSBS 自测口径（一方称），独立第三方权威评测较少。

支持的部署方式

单机部署 ：安装包一键部署（Windows 安装器 / Linux Deb/RPM/Tarball）。【已查证：下载中心】
集群部署：多 Dnode 组成集群，VGroup Raft 副本。【已查证：集群部署文档】
Docker ：官方镜像 tdengine/tdengine / tdengine/tsdb-ee，支持 docker run 与 docker-compose。【已查证：Docker 部署文档】
Kubernetes ：官方 Helm Chart（helm install tdengine tdengine/tdengine）。【已查证：K8s 部署指南】
云托管 ：TDengine Cloud 全托管时序大数据云服务。【已查证：快速体验文档】
Windows ：提供 Windows 安装器（TDengineSetup-x64.exe），默认安装目录 C:\TDengine。【已查证：Windows 安装文档】

重要依赖

运行时依赖 ：C 语言编写，核心引擎 taosd 为独立二进制；Linux 生产环境依赖 glibc；无外部数据库/中间件依赖（内置缓存、消息订阅、流计算）。【已查证：DEV.co + 白皮书】
端口：原生连接 6030-6049（TCP/UDP），REST 服务 6041。【已查证：Docker 部署文档】

生态与集成

客户端驱动 ：官方提供 C/C++、Java（JDBC）、Python、Go、Rust、Node.js、C#、REST/WebSocket 连接器，多数采用 MIT 协议。【已查证：连接器指南】
可视化 ：Grafana 官方数据源插件 + TDinsight 预置监控仪表盘；内置 taosExplorer 可视化管理工具、taosKeeper 监控。【已查证：Grafana 集成 + taosExplorer】
大数据生态 ：官方 Flink Connector（双向读写）；支持 Kafka 数据订阅对接；Spark 集成通过 JDBC。【已查证：Flink Connector 文档】
工业协议接入：taosX 支持 MQTT、OPC-UA、OPC-DA、PI System 等工业协议直接接入。【已查证：2026 白皮书】
采集端 ：兼容 Telegraf、EMQX、HiveMQ、StatsD、collectd 等。【已查证：2.4 产品简介】
BI 工具：Power BI、帆软、永洪等通过 JDBC/ODBC 对接。【已查证：PLC+OPC 方案】

使用指南（精简）

Linux 安装 ：下载 Deb/RPM/Tarball 安装包，执行 systemctl start taosd 启动服务；官方文档：https://docs.taosdata.com/get-started/package/
Windows 安装 ：下载 TDengineSetup-x64.exe，双击安装，默认目录 C:\TDengine。【已查证：Windows 安装文档】
Docker 快速体验 ：docker run -d --name tdengine -p 6041:6041 tdengine/tdengine。【已查证：Docker 部署文档】
关键操作示例（TAOS SQL）：

sql 复制代码

-- 1. 建库（保留数据 365 天）
CREATE DATABASE demo KEEP 36500;

-- 2. 建超级表（电表模型：标签 location/group_id，字段 current/voltage/phase）
CREATE STABLE meters (ts TIMESTAMP, current FLOAT, voltage INT, phase FLOAT)
  TAGS (location BINARY(64), group_id INT);

-- 3. 写入数据（自动创建子表 d1001）
INSERT INTO demo.d1001 USING demo.meters TAGS('California.SanFrancisco', 2)
  VALUES (NOW, 10.3, 219, 0.31);

-- 4. 查询：按 location 分组统计最近 1 小时平均电流（10 分钟窗口）
SELECT _wstart, AVG(current) FROM meters
  WHERE ts > NOW - 1h
  PARTITION BY location INTERVAL(10m);

Q: TDengine 开源版和企业版有什么区别？AGPL 协议能否免费商用？

A: TDengine 核心服务器 taosd 采用 AGPLv3 开源，任何组织都可免费使用和修改；但 AGPL 要求若通过网络对外提供服务，需开放对应修改源码。企业版在开源版基础上提供企业级安全、备份、技术支持等商业功能。taosAdapter 及各语言连接器为 MIT 协议，可自由集成。【已查证：TDengine 开源页】

Q: TDengine 3.0 和 2.x 有什么不兼容？升级要注意什么？

A: 3.0 是云原生重构版本，废除了 2.x 的连续查询（改为 CREATE STREAM 流式计算）、授权语法变更（v3.4 提供 enableGrantLegacySyntax 兼容参数），存算分离架构下集群部署方式也有变化。从 2.x 升级需参考官方迁移指南。【已查证：语法变更文档 + 3.4.1.0 版本说明】

Q: TDengine 的"超级表"和关系型数据库的表有什么本质区别？

A: 超级表不存实际数据，它是一类采集点的 schema 模板。每个具体设备运行时自动创建一张独立子表，子表继承超级表 schema 但携带自己的静态标签值。这种"一设备一表"模型将高基数时间线物理隔离，避免了关系型数据库中单表海量行导致的索引膨胀问题，同时标签索引又支持跨设备聚合查询。【已查证：TDengine 架构文档】

参考文献

3.5 kdb+（Kx）（金融级内存列存时序数据库，以 q 语言驱动的超高性能 tick 数据平台）

产品介绍

产品定位 ：kdb+ 是 KX 公司（原 Kx Systems）推出的面向时序数据的高性能内存列式数据库 ，内置数组编程语言 q（底层为 K 语言），长期主导全球投行/对冲基金的高频行情（tick）数据存储与实时分析市场【已查证：code.kx.com 官方文档】。
诞生背景与原因 ：1990 年代，Arthur Whitney 在 Morgan Stanley 期间用 APL/A+ 处理金融数据；1993 年他离开该行创立 Kx Systems，将数组编程思想压缩为极简的 K 语言，目标是在单机内存中装下一整天的逐笔行情并以向量计算做极速分析【已查证：handwiki.org、code.kx.com 官方文档】。
解决的核心问题：金融 tick 数据量级极大（每秒数万至数十万笔）、要求亚秒级历史回测与实时风控查询；关系型数据库当时无法在单机内存里承载当日全量行情并保持交互级查询速度。
官方链接 ：
- 官网/文档：https://code.kx.com/ 【已查证】
- GitHub：无公开源码仓库（闭源商业产品，二进制授权分发）

发展历程

1993 年：Arthur Whitney 与 Janet Lustgarten 创立 Kx Systems，并发布 K 语言【已查证：handwiki.org / codearchaeology.dev】。
1998 年：推出内存列式数据库 kdb（32 位）【已查证：ODBMS.org Bloor 报告 PDF、timestored 编年】。
2001 年：推出 kdb-tick（经典 tick 架构雏形）【已查证：ODBMS.org 报告】。
2003 年 ：发布 64 位 kdb+ 及可读层语言 q（qSQL 兼容 ANSI SQL 子集）【已查证：code.kx.com 官方文档、tutorialspoint】。
2009 年 10 月：First Derivatives（FD）将所持 Kx Systems 股份增至 22%【已查证：FD 2011 年报 PDF】。
2014 年 10 月：First Derivatives 收购 Kx Systems 控股权【一方称：timestored.com 编年整理】。
2018--2019 年：FD 收购剩余少数股权，2019 年完成 100% 控股（对价约 5380 万美元）【一方称：timestored.com 编年；FD Technologies 官网现称 Kx 为其下属事业部】。
2024-02-13 ：kdb+ 4.1 正式生产发布【已查证：code.kx.com/q/releases/ChangesIn4.1/】。
2026-01-23：kdb+ 4.1 分支最新二进制版本（4.1 2026.01.23），随 kdb Insights Core 4.1.19（2026-02-25）发布【已查证：code.kx.com/insights/1.18/core/release-notes/latest.html】。

基本信息卡（表格）

项	值
开源/闭源	闭源商业软件（按进程/核数授权收费）【已查证：code.kx.com/licensing/】
开发语言	C（kdb+ 引擎）+ q/K 语言（内置 DSL）【一方称：官方文档】
当前最新版本（2026-10 口径）	kdb+ 4.1（生产版 2024-02-13；最新二进制 4.1 2026.01.23）【已查证】
License	商业专有许可（非开源）；另有免费 32 位个人/评估版【已查证：code.kx.com/licensing/】
GitHub Star	--（无公开源码仓库；产品不开放源码）
维护组织	KX（FD Technologies plc 旗下事业部）【已查证：fdtechnologies.com】
官网 URL	https://code.kx.com/ 【已查证】
GitHub URL	无公开源码仓库

主要功能

内存优先的列式存储，磁盘历史库为按日期分区的列存文件（splayed/segmented）。
内置 q 语言：向量/数组运算、qSQL 类 SQL 查询、函数式编程，库内直接做因子计算与回测。
Tick 架构：feedhandler → tickerplant（发布订阅+持久化日志）→ RDB（当日内存实时库）→ HDB（历史库）。
流订阅（pub/sub IPC）、实时风控/告警、跨日数据归并（日终 rollup）。
配套 KDB-X / kdb Insights 平台：时序 + 向量（KDB.AI）+ 流处理的企业级扩展【已查证：code.kx.com】。

核心优势

极致查询性能：当日全量行情驻留内存，列存 + 向量计算使多年历史聚合查询在秒级返回【一方称：厂商/社区普遍口径】。
单机可承载当日全量 tick：设计目标即"一台机器装下一天 tick 并跑向量数学"【一方称：questdb.com 对比文转述其设计目标】。
写入与分析解耦的成熟 tick 范式：tickerplant 单线程发布订阅，分析负载不冲击实时行情链路【已查证：code.kx.com 官方架构文档】。
金融生态事实标准：高盛、摩根大通、摩根士丹利、花旗等头部机构长期使用【一方称：quantt.co.uk 教程文】。

主要短板

价格昂贵：商业授权按进程/核数计费，中小团队难以承受【一方称：QuestDB 等竞品对比文普遍指出】。
语言门槛高：q/K 语法极简但逆向，人才稀缺、培训成本高【一方称：社区共识】。
生态封闭：无开源社区、无标准 SQL 协议之外的通用连接器，绑定 q 生态。
横向扩展靠手工架构：本身不提供透明分布式集群，需自行用 tick 架构 + 多节点拼装。

潜在风险与局限性

厂商为 FD Technologies 事业部，2024 年 3 月集团公告曾提及"评估 KX 与 First Derivative 的分拆"，存在战略变动可能【已查证：FD Technologies 2024-03 公告 PDF】。
无公开源码，安全审计与可维护性依赖厂商；技术栈锁定 q 语言。
对非金融时序场景（如高基数标签/普罗米修斯式指标）适配性差，非通用时序数据库。

适用场景

证券/期货/外汇逐笔行情（tick）存储、实时风控、高频回测、做市/量化因子计算。
低延迟实时事件流处理（金融、电信、物联网高频数据）。
不适合：中小团队轻量监控指标、需要标准 SQL + 开源生态的通用时序场景。

发展趋势

闭源产品无公开 Star/Fork 趋势数据；产品演进方向为 KDB-X 平台化（融合向量库 KDB.AI、流处理、云参考架构 GCP/Azure）【已查证：code.kx.com/kdb-x/】。
一句话总结：kdb+ 是金融 tick 时序领域的"老字号事实标准"，正从单一数据库向"时序+AI/向量"企业平台演进，但闭源高价与 q 语言门槛决定其难以向通用时序市场扩张。

工作原理与核心架构

概念术语

q/K：数组导向编程语言，表（table）为一等公民，类 SQL 的 qSQL。
Tick 架构：以逐笔行情为中心的经典数据管线（feedhandler/tickerplant/RDB/HDB 四件套）。
Tickerplant (TP)：单线程发布订阅中枢，接收行情、写日志、向订阅者广播。
RDB（Real-time Database）：驻留内存的当日实时库，订阅 TP 数据。
HDB（Historical Database）：磁盘历史库，按交易日（或其他分区列）分目录的列存文件。
Feedhandler：对接交易所/行情网关，把外部行情转成 kdb 表推给 TP。
IPC：kdb+ 进程间二进制通信协议，跨语言客户端（Java/Python/C#）通过它读写。
Sym file / attribute ：列存符号字典与列属性（g# 分组、p# 分区），用于加速过滤。

架构与运行原理

写入路径：行情网关 → feedhandler →（IPC）tickerplant 写日志并 pub/sub → RDB 内存表即时可查；日终脚本把当日数据归并落盘为 HDB 按日分区目录。
存储引擎：RDB 为纯内存列存；HDB 为磁盘列存（splayed 表，每列一个文件，符号列独立字典）。
查询路径：查询进程可同时挂接 RDB（当日）与 HDB（历史），q 自动跨分区合并；向量遍历 + 属性索引过滤。
集群拓扑：无原生分布式，通过多 TP 镜像、多 HDB 按业务域分片、负载均衡网关手工拼装；官方提供 GCP/Azure 参考架构【已查证：code.kx.com/q/cloud/】。

flowchart LR FH $Feedhandler\行情网关接入$ -->|IPC| TP $Tickerplant\单线程 pub/sub + 日志$ TP --> RDB $RDB 实时库\当日数据内存列存$ TP --> SUB $实时订阅客户端\风控/告警$ RDB -->|日终归并| HDB $HDB 历史库\按日分区磁盘列存$ HDB --> Q $查询/回测进程\qSQL 向量计算$ RDB --> Q

写入模式与查询特性

写入：以 append-only 为主（tick 数据只追加）；批量 IPC 写入；实时数据乱序容忍度低（行情本身按时序到达）；落盘靠日终批处理。
查询特性 ：原生按时间窗口聚合（select by time）、列属性加速、as-of join（aj/wj 区间连接，金融对齐利器）；无内建 TTL/自动降采样/连续聚合，需用 q 脚本与日终作业自行实现【一方称：基于其架构文档的功能边界】。

写入与查询性能特点

官方/厂商口径：当日全量 tick 驻内存、向量运算，聚合查询可达毫秒~秒级；但截至 2026-10 未查到官方公开的可复现基准数字（如每秒写入条数），此处不杜撰【已查证：官方文档未公开统一 benchmark】。
第三方对比方（QuestDB）称 kdb+ 设计目标为"单机内存装一天 tick"，性能口碑来自金融机构多年生产验证【一方称：questdb.com 对比文】。
压缩：磁盘 HDB 列存 + 符号字典去重，金融行情压缩比通常较高，但官方未公布统一压缩比数字，不写。

支持的部署方式

单机（Linux 为主，亦提供 Windows/macOS 二进制）【已查证：code.kx.com/q/learn/install/】。
自建分布式集群（tick 架构手工拼装）。
容器/K8s：KX 官方提供 kdb Insights 的 Helm/K8s 参考部署【已查证：code.kx.com/insights/.../kubernetes/】。
云参考架构：GCP、Azure 官方文档【已查证】。

重要依赖

运行时：自包含二进制（自带 q 运行时），无外部数据库依赖；操作系统 Linux x86/ARM 为主，新版已支持 macOS ARM64【已查证：kdb Insights Core 4.1.10 起支持】。
语言客户端依赖：Java/Python/PyKX 等通过 IPC 套接字对接。

生态与集成

客户端：q/C API、Java、Python（PyKX）、C#、WebSocket 网关。
可视化：KX 自带 Insights/前端；第三方如 KXI、自有 BI 通过 ODBC/JDBC。
大数据生态：可与 Kafka、Spark 对接（feedhandler 模式）；KDB.AI 提供向量检索扩展【已查证：code.kx.com/kdbai/】。

使用指南（精简）

安装（Linux） ：从 KX 官网下载 tar 包解压，设置 QHOME 与许可证后运行 q；Windows 解压后运行 q.exe（32 位免费版可直接跑）。详见 https://code.kx.com/q/learn/install/ 【已查证】。
关键操作示例（建库→写→查）：

q 复制代码

// 1) 定义行情表并插入数据（内存 RDB 模式）
trade:([]time:09:30:00.000 09:30:00.125;sym:`AAPL`MSFT;price:189.2 428.5;size:100 500);

// 2) 按符号统计每分钟均价（时间窗口聚合）
select avg price, sum size by sym, minute time from trade;

// 3) 日终将当日数据落盘为按日分区 HDB
. Q.d[`:./hdb/2026.10.09;`trade];

Q: kdb+ 为什么在投行圈流行了二十年？

A：核心是"内存列存 + q 向量语言 + tick 架构"三位一体------当日全量行情在内存里用向量遍历做秒级聚合，且实时写入与分析负载解耦，这在 1990s--2000s 没有其他开源方案能达到同等性能【一方称：社区与厂商共识】。

Q: kdb+ 是开源软件吗？个人/学生能用吗？

A：核心是闭源商业授权；KX 提供免费的 32 位个人评估版（内存有上限），可学习 q 与搭 tick 原型【已查证：code.kx.com 下载页说明】。

Q: kdb+ 和 DolphinDB 是什么关系？

A：DolphinDB 官方明确将 kdb+ 作为对标与迁移对象，提供中文《从 kdb+ 迁移到 DolphinDB》文档，主打"国产、开源工具链更开放、中文生态"替代【已查证：docs.dolphindb.com/zh/tutorials/kdb_to_dolphindb.html】。

参考文献

3.6 【Prometheus】------CNCF 毕业级 pull 式监控系统与本地块存储 TSDB，云原生指标事实标准

产品介绍

产品定位 ：开源系统监控与告警工具链，内置时序数据库；官方描述为 "The Prometheus monitoring system and time series database"【已查证：GitHub API repo description】。核心是拉取（pull）模型采集指标 + PromQL 查询 + Alertmanager 告警，本地 TSDB 仅保留近期数据，长期存储与横向扩展交由 remote write 生态（Thanos/Mimir/VictoriaMetrics 等）。
诞生背景与原因：2012 年在 SoundCloud 内部启动，受 Google Borgmon 启发，针对当时缺乏面向容器/微服务、带多维标签数据模型与强大查询语言的监控系统而设计【已查证：CNCF 项目页与官方 Overview】。
解决的核心问题：多维度标签指标模型、服务发现自动抓取、PromQL 即席聚合、告警管理；本地 TSDB 解决"近期监控数据快速查询"，而非通用长周期数据仓库。
官方链接 ：
- 官网：https://prometheus.io/
- GitHub：https://github.com/prometheus/prometheus

发展历程

2012-05-19 ：首次提交（First commit）【已查证：CNCF 项目页 https://www.cncf.io/projects/prometheus/ 】。
2012 年：在 SoundCloud 创建，Apache-2.0 许可【已查证：CNCF 博客《Prometheus 1.0 is here》】。
2013 年：逐步在 SoundCloud 生产环境投入监控使用【已查证：同上 CNCF 博客】。
2015 年：正式向外界公开发布【已查证：CNCF 博客《Inside Prometheus》】。
2016-05-09：加入 CNCF，成为继 Kubernetes 之后第二个托管项目【已查证：CNCF 项目页】。
2016-07：Prometheus 1.0 发布【已查证：CNCF 博客】。
2017-11：Prometheus 2.0 发布，重写本地 TSDB（2 小时 block + WAL 架构）【已查证：KubeCon 2025 Japan Maintainer Session 历史页】。
2018-08-09：CNCF 毕业（第二个毕业项目）【已查证：Linux Foundation 官方新闻稿】。
2024-11：Prometheus 3.0 发布（新 UI、native histogram 增强、remote write 2.0 等）【已查证：官方 3.0 migration 文档】。
2026-09-24 ：最新版 3.15.0 发布【已查证：prometheus.io/download 官方下载页】。

基本信息卡

项	值
开源/闭源	完全开源（Apache-2.0），CNCF 毕业项目，无单一公司控制
开发语言	Go【已查证：GitHub API language 字段】
当前最新版本（2026-10 口径）	3.15.0（2026-09-24）【已查证：prometheus.io/download】；2.x 维护线仍并行（2.55.x 文档在线）
License	Apache License 2.0【已查证：GitHub API license 字段】
GitHub Star	59,708 stars / 9,684 forks （抓取日期 2026-10-09，信源：`https://api.github.com/repos/prometheus/prometheus`；注：本次 API 响应 updated_at 为 2025-07-31，疑为缓存快照，Star 数以本次抓取值为准）
维护组织	Prometheus 开发社区（独立治理），初始由 SoundCloud 赞助【已查证：官网 Community 页】
官网 URL	https://prometheus.io/
GitHub URL	https://github.com/prometheus/prometheus

主要功能

多维数据模型：指标名 + 键值标签（labels），支持任意维度组合聚合。
PromQL ：即时向量/范围向量查询语言，含聚合、rate、histogram quantile、info() 标签富化函数等【已查证：官方文档】。
pull 采集：通过 HTTP 从 target 拉取 /metrics 文本 exposition 格式；支持服务发现（Kubernetes、Consul、DNS、file_sd 等数十种 SD）。
本地 TSDB：WAL + 2 小时 head block + 后台 compaction + 可配置 retention。
Recording Rules / Alerting Rules：预计算聚合与告警判定；Alertmanager 负责分组、抑制、静默、路由。
Remote Write/Read 2.0：把样本推给远端长期存储（Snappy 压缩的 protobuf over HTTP）【已查证：官方 storage/remote write 文档】。
联邦（Federation）：一个 Prometheus 抓取另一个 Prometheus 的部分时序，实现分层聚合。
Agent 模式：关闭查询/告警/本地存储，仅做 WAL + remote write 转发【已查证：官方 Agent 文档】。
Native Histograms、Exemplars（关联 trace）、OTLP receiver（接收 OpenTelemetry 指标）。

核心优势

云原生事实标准：Kubernetes 原生监控默认选项，CNCF 毕业项目，生态（Grafana、Alertmanager、各种 exporter）极其成熟【已查证：CNCF】。
pull 模型 + 服务发现天然适配动态伸缩的容器环境。
PromQL 的多维度聚合表达力在监控领域公认强于传统单机 TSDB。
本地 TSDB 压缩高效：Gorilla/XOR 浮点编码，WAL 压缩后体积约减半（CPU 开销极小）【已查证：官方 storage 文档】。
架构简单、单二进制、资源占用低，"近期数据本地查"体验好。

主要短板

单机本地存储，不原生水平扩展：官方明确长期存储/高可用依赖 remote write 外接 Thanos/Cortex/Mimir/VictoriaMetrics，部署复杂度转移到生态。
pull 模型的局限：跨网络/防火墙、大量短生命周期任务时不如 push 灵活；label 基数爆炸会直接打爆内存与索引。
本地 TSDB 不擅长长周期（月级以上）原始数据留存与重分析型查询（非 OLAP 列存）。
无原生降采样/连续聚合写入主链路（recording rules 可近似，但需自行维护）。

潜在风险与局限性

高基数风险：label 中放入 user_id、URL 等会导致时序数爆炸，官方文档反复警告。
本地 retention 到期即删，误删不可恢复；长期方案选型（Thanos vs Mimir vs VictoriaMetrics）带来二次架构决策成本。
remote write 链路在大规模下需调优 queue/shard，存在背压与丢样本风险【一方称：官方 remote write tuning 文档】。

适用场景

Kubernetes/微服务环境指标监控与告警（主战场）。
基础设施与应用性能指标的近期可观测性（小时~天级 retention）。
作为指标采集前端 + remote write 到长期存储（Thanos/Mimir/VictoriaMetrics）的分层架构。
不适用：长周期 IoT 海量传感器数据仓库、金融高频 tick 存储、日志主存。

发展趋势

趋势依据：版本节奏密集------3.0（2024-11）→ 3.11.2（2026-04，安全修复）→ 3.15.0（2026-09-24），约每 2~3 个月一个小版本【已查证：官方下载页与 changelog 记录】；方向为 native histogram、Remote Write 2.0、OpenMetrics 2.0、XOR2 编码、uncached I/O（v3.5 引入）等【已查证：官方博客 2026-02/03】。Star 59.7k（本次抓取）居时序/监控类项目前列，但增量主要由生态项目（Thanos、VM、OTel）承接扩展需求。
一句话总结：Prometheus 本身保持"轻量单机采集+查询内核"定位持续小步快跑，规模与长期存储问题整体外包给 CNCF/开源生态扩展层，成为指标领域的"Linux 内核式"标准底座。

工作原理与核心架构

概念术语：

Metric family / Time series ：<metric name>{label1=v1,label2=v2} 唯一确定一条时序。
Exposition format ：被采集端暴露的 /metrics 文本格式（OpenMetrics 演进中）。
Head block：内存中最近样本块，受 WAL 保护。
WAL（Write-Ahead Log）：崩溃恢复日志，启用压缩后约减半体积【已查证】。
Block：不可变磁盘段，初始 2 小时；后台 compaction 合并为更大块（跨度至多 retention 的 10% 或 31 天，取小）【已查证：官方 storage 文档】。
Chunk encoding：Gorilla/XOR 浮点编码（XOR2 为新一代可选编码）【已查证】。
PromQL：即时向量（瞬时点）与范围向量（区间序列）两种主类型。
Recording Rule / Alerting Rule：预计算规则 / 告警规则。
Remote Write/Read：与外部长期存储的双向协议（Snappy+protobuf over HTTP）。
Federation：跨 Prometheus 实例的时序抓取聚合。

架构与运行原理：

写入路径：Scheduler 按 scrape_interval pull target → 样本入内存 head block → 同步写 WAL → 每 2 小时 head 冻结为磁盘 block → 后台 compaction 合并。
存储引擎：本地 TSDB = head（内存）+ WAL + 不可变 block 目录（chunks/ + index + meta），Gorilla/XOR 压缩；不修改已落盘样本（append-only，retention 到期整块删除）。
查询路径：PromQL 查询器同时扫内存 head 与匹配时间范围的磁盘 block，合并返回；recording rules 在查询前预物化常用聚合。
集群拓扑 ：原生无集群------单实例本地存储；高可用/长期化靠：① remote write 到 Thanos/Mimir/VictoriaMetrics；② federation 分层；③ Agent 模式只转发。

flowchart TD subgraph Scrape $"采集层 (pull)"$ SD $"服务发现 (K8s/Consul/DNS...)"$ --> SCH $"Scrape Scheduler"$ SCH --> T1 $"Target /metrics"$ T1 -->|HTTP pull| ING $"样本摄入"$ end subgraph TSDB $"本地 TSDB"$ ING --> HEAD $"Head Block (内存)"$ HEAD --> WAL $"WAL (可压缩)"$ HEAD -->|每2小时冻结| BLOCK $"不可变磁盘 Block (chunks+index)"$ BLOCK -->|后台 Compaction| BIG $"更大 Block (\leqretention 10%/31天)"$ end subgraph Query $"查询与告警"$ PQ $"PromQL 查询器"$ --> HEAD PQ --> BLOCK RR $"Recording / Alerting Rules"$ --> PQ RR --> AM $"Alertmanager (分组/抑制/路由)"$ end subgraph Remote $"外部扩展"$ RW $"Remote Write 2.0"$ --> REMOTE $"Thanos / Mimir / VictoriaMetrics / 远端 TSDB"$ FED $"Federation 抓取"$ --> REMOTE end HEAD --> RW BLOCK --> RW subgraph UI $"接入层"$ GRA $"Grafana"$ --> PQ end

写入与查询特性：

写入模式 ：pull 为主（默认），样本按 scrape 间隔到达；append-only，落盘块不可变；乱序样本（scrape 抖动）接受但影响效率；remote write 为 push 出向。
查询特性 ：原生时间窗口聚合（rate()、histogram_quantile()）、recording rules 预聚合（近似连续聚合）、retention TTL 自动过期；无原生降采样写路径与 SQL ；插值对齐由 PromQL 函数（如 increase）近似，不做通用连续聚合物化。

写入与查询性能特点

压缩：Gorilla/XOR 浮点编码（官方 storage 文档确认算法存在；具体"每样本 X 字节"的官方量化口径本次未抓取到原文，不臆造）。
WAL 压缩：官方称视数据而定 WAL 体积约减半，CPU 开销很小【已查证：官方 storage 文档】。
Compaction 块大小：合并后块跨度至多为 retention 的 10% 或 31 天，取较小者【已查证：官方 storage 文档】。
写入吞吐/查询延迟的官方基准与第三方评测数字本次未取得可引用出处，按要求不罗列。

支持的部署方式

单机二进制（Linux/macOS/Windows 均提供，Windows 以 exe 发布）、Docker、Kubernetes（官方 Helm chart / kube-prometheus-stack）、系统包；无官方集群发行版，集群能力由 Thanos/Mimir/VictoriaMetrics 等生态提供；托管等价物为 Grafana Cloud / Amazon Managed Service for Prometheus 等。

重要依赖

Go 编译单二进制，无外部运行时依赖；本地文件系统即可运行；系统依赖极少（v3.5 起 uncached I/O 仅支持 Linux）【已查证：官方博客 2026-03】。

生态与集成

可视化：Grafana 原生数据源（事实标准组合）。
采集端：数百个 exporter（Node Exporter、黑盒 exporter 等）、OpenTelemetry collector（OTLP receiver 接收）。
告警：Alertmanager（独立组件）。
扩展层：Thanos、Cortex、Mimir、VictoriaMetrics、Kube-Prometheus-Stack、Prometheus Operator。
协议生态：OpenMetrics、Remote Write 2.0、PromQL 被 VictoriaMetrics 等广泛兼容实现。

使用指南（精简）

Linux 安装 ：下载对应版本 tarball，解压后 ./prometheus --config.file=prometheus.yml 启动；文档 https://prometheus.io/docs/prometheus/latest/getting_started/
Windows ：官方提供 Windows amd64 zip，解压后直接运行 prometheus.exe（生产推荐 Linux/Docker）。
关键操作示例：

yaml 复制代码

# prometheus.yml：抓自身 + 查询
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]

promql 复制代码

# 查询过去 5 分钟 CPU 使用率（每实例）
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# 过去 1 小时 HTTP 请求 P99 延迟
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[1h]))

Q: Prometheus 能当长期时序数据库用吗？

A：不建议。本地 TSDB 只服务近期数据（默认 retention 可配但磁盘成本高），官方长期方案是 remote write 到 Thanos/Mimir/VictoriaMetrics【已查证：官方 storage 与 comparison 文档】。

Q: Prometheus 为什么是 pull 而不是 push？

A：pull 模型便于服务发现自动纳管 target、健康检查与抓取间隔统一控制；push 场景（短生命周期任务、跨网络）由 Pushgateway 或 remote write/OTLP 补充【已查证：官方 FAQ/架构文档】。

Q: 高基数 label 为什么危险？

A：每条 <metric>{label组合} 都是独立时序并占用索引与内存，label 基数失控会导致内存暴涨、OOM 与查询变慢------这是 Prometheus 运维最常见事故之一【一方称：官方最佳实践文档反复强调】。

Q: Prometheus 3.x 和 2.x 兼容吗？

A：配置与数据模型大体兼容，但 3.0 含若干不向后兼容变更（部分特性 flag 默认化、新 UI），升级前需读官方 3.0 migration guide【已查证：官方 migration 文档】。

参考文献

3.7 TimescaleDB（Timescale/TigerData）（以 PostgreSQL 扩展形态存在的开源时序 SQL 数据库）

产品介绍

产品定位 ：TimescaleDB 是打包为 PostgreSQL 扩展的开源时序关系型数据库，在 100% 兼容 PostgreSQL SQL/生态的前提下，通过自动时间分区、列存压缩、连续聚合等能力优化时序写入与分析【已查证：tigerdata.com/timescaledb】。
诞生背景与原因 ：2017 年前后，监控/IoT/金融时序数据爆炸，而专用时序库（InfluxDB 等）要么放弃 SQL、要么放弃事务与 JOIN；Timescale 公司（现品牌 Tiger Data）的判断是"时序分析也能跑在 Postgres 上"，于是以扩展形式增强 Postgres【已查证：tigerdata.com 官方博客回顾 2017-04-04 发布】。
解决的核心问题：让开发者用熟悉的 PostgreSQL（事务、JOIN、丰富生态）处理亿级时序数据，同时获得远超原生 Postgres 的写入吞吐、压缩与时间窗口聚合性能。
官方链接 ：
- 官网：https://www.tigerdata.com/timescaledb 【已查证】
- GitHub：https://github.com/timescale/timescaledb 【已查证】

发展历程

2017-04-04：TimescaleDB 首次对外发布（开源）【已查证：tigerdata.com 官方博客回顾】。
2018-12 ：许可证策略调整，拆分为 Apache-2.0 核心版 与 TSL（Timescale License）社区版【已查证：tigerdata.com/legal/licenses】。
2021 年起：陆续推出分布式 hypertable（多节点）、连续聚合物化视图、列式压缩（columnstore / Hypercore）等能力【一方称：官方 changelog 历史】。
2024-10：TimescaleDB 2.13 起弃用 PostgreSQL 13 支持【已查证：官方 changelog】。
2025-10（v2.23）：引入自动列存（automatic columnstore）与连续聚合失效跟踪改进【已查证：官方 changelog】。
2026-03-24（v2.26）：列存查询性能、压缩数据过滤效率大幅改进【已查证：tigerdata.com 官方 changelog】。
2026-05-12（v2.27）：Bloom filter pruning 扩展到写入路径【已查证：tigerdata.com 官方 changelog】。
2026-06-30（v2.28.2）：bugfix 版本【已查证：newreleases.io / pkgsrc-changes】。
2026-08-18（v2.29.2） ：宣布 v2.29 起停止支持 PostgreSQL 15，仅支持 PG16/17/18【已查证：newreleases.io 2.28.0 release 说明】。
2026-09（v2.30.x）：进入 2.30 版本线（2.30.0 约 2026-09-21 由发行版打包，2.30.2 为追踪站所列最新版）【已查证：rpmfind.net / newreleases.io 版本列表】。

基本信息卡（表格）

项	值
开源/闭源	开源（双授权：Apache-2.0 核心 + TSL 社区版）【已查证：tigerdata.com/legal/licenses】
开发语言	C（PostgreSQL 扩展）【一方称：SRA OSS 教程、官方仓库】
当前最新版本（2026-10 口径）	2.30 版本线（追踪站列最新 2.30.2，约 2026-09 末；2.28.2 为 2026-06-30 稳定线）【已查证：newreleases.io / rpmfind】
License	Apache-2.0（核心）+ Timescale License / TSL（社区高级功能，source-available，不得转售为托管服务）【已查证】
GitHub Star	约 23.6k stars、约 1.1k forks （第三方仓库镜像站快照：modern-datatools 2026-10-05 显示 23.6k；opensourcedrop 显示 23,641 stars / 1,166 forks）。注：GitHub REST API 直连本次抓取失败，Star 数以第三方镜像站为准；抓取日期 2026-10-09。信源：https://www.modern-datatools.com/tools/timescaledb
维护组织	Tiger Data（原 Timescale, Inc.）【已查证：tigerdata.com】
官网 URL	https://www.tigerdata.com/timescaledb 【已查证】
GitHub URL	https://github.com/timescale/timescaledb 【已查证】

主要功能

Hypertable（超表）：透明地把一张逻辑表按时间（及可选空间分区）切成多个 chunk，对用户仍是一张表。
连续聚合（Continuous Aggregates）：物化视图自动增量刷新，预计算小时/天级降采样。
列式压缩（Columnstore/Hypercore）：历史 chunk 自动由行存转为列存，使用 RLE、delta、Gorilla 编码。
数据保留策略（Retention / TTL）：按时间自动 drop 旧 chunk。
时间 bucket（time_bucket） ：类 date_trunc 的灵活时间窗口聚合。
全部 PostgreSQL 能力：事务、JOIN、二级索引、窗口函数、PL/pgSQL、复制。
分布式 hypertable（多节点集群，TSL 高级功能）。

核心优势

100% PostgreSQL 兼容：任意 Postgres 客户端/Driver/ORM/备份工具直接可用，迁移成本极低【已查证：官方定位】。
开发体验统一：业务数据与时序数据同库 JOIN，无需在"关系库 + 时序库"间同步。
高压缩比 ：官方称列存压缩可节省 80%~95% 存储空间（官方决策框架表：压缩 90--97%）【一方称：tigerdata.com 官方页面】。
连续聚合 + 保留策略：把降采样与 TTL 内建为声明式 SQL，而非外部脚本。
生态成熟：Docker、K8s Helm、各大云厂商托管 Postgres（Azure、阿里云 PolarDB、VMware Postgres）均已集成【已查证】。

主要短板

写入吞吐上限受 Postgres 行存架构约束：典型场景为几万~十几万行/秒量级，低于专用列存时序库（官方宣称优化后可达 1.2M 行/秒，属理想基准）【一方称：tigerdata.com 官方对比表】。
高基数标签场景：相比 InfluxDB/VictoriaMetrics，在百万级标签基数的监控场景下索引与存储开销更大【一方称：第三方对比共识】。
TSL 双授权争议：高级功能（分布式、部分压缩策略）为 source-available 而非 OSI 认证开源，不能直接拿来做托管服务。
版本跟随 Postgres：需同时维护 PG 大版本与 TimescaleDB 扩展版本（如 v2.29 起弃 PG15）。

潜在风险与局限性

许可证非纯开源（TSL 限制托管转售），企业法务需评估。
2026 年学术研究（MSST 2026 论文）指出：在 chunk 过小时，TimescaleDB 2.27 的 Hypercore 列存压缩反而可能增加最多 54% 存储------压缩效果依赖 chunk 调优，不是无条件收益【已查证：MSST26_paper_10.pdf】。
分布式集群为 TSL 功能，开源社区版只能单节点。

适用场景

已有 PostgreSQL 技术栈、希望"一套库搞定业务 + 时序"的团队（SaaS 产品分析、应用监控、IoT 设备数据、金融订单/行情辅助分析）。
需要事务/JOIN/复杂 SQL 的时序分析（如用户行为时序 + 业务维表 JOIN）。
不适合：超大规模纯监控指标（亿级时间序列标签）、超高吞吐纯写入流水线场景。

发展趋势

Star 趋势：截至 2026-10 约 23.6k stars、1.1k forks，近 90 天约 337 commits（modern-datatools 2026-10-05 快照），社区活跃度高【已查证：modern-datatools.com】。公司称已有"数百万下载、超 300 万活跃数据库"【一方称：tigerdata.com 官方博客】。
版本节奏：约 2--4 周一个小版本，持续向列存性能、自动压缩、Bloom 过滤裁剪方向演进。
一句话总结：TimescaleDB 走"Postgres 原生时序"路线，靠生态兼容与连续聚合/压缩持续吃掉"不想引入专有时序库"的开发者市场，是开源时序中最贴近关系型数据库的一脉。

工作原理与核心架构

概念术语

Hypertable：时序逻辑表，由多个 chunk 组成，对应用户透明。
Chunk：按时间区间（可叠加空间分区）切出的物理表，是压缩与保留策略的最小单位。
Columnstore / Hypercore：历史 chunk 压缩后的列式存储格式。
Continuous Aggregate（CAgg）：自动增量刷新的物化视图，用于降采样。
Retention Policy：按时间自动删除旧 chunk 的策略（即 TTL）。
time_bucket：时间窗口聚合函数（类似 date_trunc 但可任意间隔）。
Compression：RLE（游程）、delta（差值）、Gorilla（浮点/整数）编码组合。
Distributed Hypertable：多节点集群下跨节点分片的 hypertable（TSL）。

架构与运行原理

写入路径 ：客户端标准 SQL INSERT → PostgreSQL 解析器 → TimescaleDB 规划器把行路由到当前时间 chunk（行存 rowstore），写入即生效（事务）。
存储引擎：近期 chunk 为行存；达到压缩策略后由后台作业转为列式压缩；chunk 按时间目录组织。
查询路径：查询命中 hypertable → 规划器裁剪不相关 chunk（时间/空间/Bloom 过滤）→ 并行扫描行存或列存 → 可选命中连续聚合物化视图。
集群拓扑：社区版单实例；分布式版为 access node + data nodes 共享无架构（TSL）。

flowchart TD APP $应用 SQL INSERT/SELECT$ --> PG $PostgreSQL 进程$ PG --> HT $Hypertable 逻辑超表$ HT --> RC $近期 Chunk\rowstore 行存可写$ HT --> HC $历史 Chunk\后台压缩为 columnstore$ HC --> CA $Continuous Aggregates\连续聚合/降采样$ RC --> CA RET $Retention 保留策略\按时间 drop 旧 chunk$ --> HT Q $查询规划器\时间/空间/Bloom 裁剪$ --> RC Q --> HC Q --> CA

写入模式与查询特性

写入：标准 PostgreSQL append 语义（支持事务、乱序写入后可在未压缩 chunk 内修正）；批量 COPY/多行 INSERT 吞吐更高；写入协议即 PG 原生协议（无专用线协议）。
查询特性 ：时间窗口聚合（time_bucket）✓、连续聚合自动刷新 ✓、降采样 ✓、TTL 保留策略 ✓、插值对齐 （time_bucket_gapfill 等，部分 TSL）--- 官方原生支持中等【一方称：官方文档】。

写入与查询性能特点

写入吞吐：官方决策框架表称"优化后峰值 1.2M 行/秒"（对比原生 Postgres 50K、InfluxDB 3.x 800K）【一方称：tigerdata.com 官方页面，未第三方复核】。
压缩比：官方称 90--97% 空间节省（架构 PDF 称最多减少 95%）；第三方 ClickHouse 对比文称典型 5--10 倍压缩（即 80--90%）【一方称：fastero.com】。
查询延迟：官方博客称历史聚合比原生 Postgres 快最高约 1000 倍（理想基准）【一方称】；第三方 padho.ai 实测类场景 p99 查询约 200ms 量级。
高基数：未查到官方公开的百万基数压测数字，不杜撰。
学术警示：MSST 2026 指出 chunk 过小时压缩收益反转【已查证：MSST26 论文】。

支持的部署方式

单机自托管（Linux 包：apt/yum/官方仓库）【已查证：apt.postgresql.org 仓库 2026 年仍在持续发版】。
Docker 官方镜像、K8s Helm chart【一方称：官方文档】。
托管云：Tiger Cloud（官方云）、Azure Database for PostgreSQL（集成 2.24.x）、阿里云 PolarDB Ganos TSDB【已查证】。
Windows：无原生 Windows 服务端安装包，需 WSL/Linux 容器【一方称：官方文档未列 Windows 安装】。

重要依赖

强依赖 PostgreSQL ：本身是 PG 扩展，需先安装 PostgreSQL；v2.29+ 要求 PostgreSQL 16/17/18（已弃 PG15）【已查证：newreleases release 说明】。
编译/运行依赖：PG server 头文件、CMake。

生态与集成

客户端：任意 PostgreSQL 驱动（psql、JDBC、psycopg、Go pgx 等）；ORM（Hibernate、Django ORM、Prisma）无感接入。
可视化：Grafana 官方 Postgres 数据源、Tableau、Superset。
大数据：通过 PG 外表/FDW 与 Spark、Flink、Debezium 对接。
周边工具：timescaledb-tune（参数调优）、pg_dump/备份生态。

使用指南（精简）

安装（Linux） ：添加 Timescale 官方 apt/yum 源后 apt install timescaledb-2-postgresql-16，执行 timescaledb-tune 配置 shared_preload_libraries='timescaledb'。详见 https://docs.timescale.com/ 【已查证】。
Windows：无原生安装，建议 Docker Desktop 跑官方镜像或 WSL 内 Linux 安装【一方称】。
关键操作示例：

sql 复制代码

-- 1) 建扩展与 hypertable
CREATE EXTENSION IF NOT EXISTS timescaledb;
CREATE TABLE metrics(ts TIMESTAMPTZ NOT NULL, device_id INT, cpu DOUBLE);
SELECT create_hypertable('metrics','ts');

-- 2) 写入（标准 INSERT）
INSERT INTO metrics VALUES (now(), 1, 0.42);

-- 3) 时间窗口聚合 + 连续聚合 + 7 天 TTL
SELECT date_trunc('hour', ts) h, avg(cpu) FROM metrics GROUP BY h;
CREATE MATERIALIZED VIEW cpu_hourly WITH (timescaledb.continuous)
AS SELECT time_bucket('1 hour', ts) b, device_id, avg(cpu) FROM metrics GROUP BY b, device_id;
SELECT add_retention_policy('metrics', INTERVAL '30 days');

Q: TimescaleDB 是真正的开源软件吗？

A：核心引擎（hypertable、基础压缩等）为 Apache-2.0；但分布式 hypertable、部分高级压缩/连续聚合能力在 TSL（Timescale License） 下，属 source-available------可免费自用，但不能直接拿来做商业托管服务【已查证：tigerdata.com/legal/licenses】。

Q: 它和直接用 PostgreSQL 有什么本质区别？

A：表面都是 SQL，区别在引擎层：超表自动按时间切 chunk、后台把历史数据转列存压缩、声明式连续聚合与 TTL 策略------这些是原生 Postgres 没有的时序专用优化【已查证：官方架构文档】。

Q: 现在还支持哪个版本的 PostgreSQL？

A：2026 年的 v2.29 起仅支持 PostgreSQL 16/17/18，PostgreSQL 15 已于 v2.29 被弃【已查证：newreleases.io 2.28.0 release 说明】。

Q: 压缩是不是越多越好？

A：不是。2026 年 MSST 学术论文实测，chunk 过小时 Hypercore 列存压缩反而可能多占 54% 空间；压缩窗口与 chunk 时长需要按数据量调优【已查证：MSST26_paper_10.pdf】。

参考文献

3.8 【DolphinDB】（浙江智臾科技）（国产分布式时序 + 流计算 + 库内编程一体化的实时计算平台）

产品介绍

产品定位 ：DolphinDB 是浙江智臾科技有限公司自主研发的以高性能时序数据库为核心、集分布式存储、流计算与内置编程语言于一体的实时计算平台，内存与磁盘混合、列式存储，主打金融量化与工业 IoT【已查证：dolphindb.cn 官网/公司简介】。
诞生背景与原因 ：创始人周小华博士曾在华尔街从事量化交易系统研发；2016 年公司在杭州成立，2018 年初发布 DolphinDB，初衷是解决金融高频行情"存储 + 计算 + 回测"割裂于多套系统（kdb+、Python、数据库）的痛点，做一站式国产替代【已查证：dolphindb.cn/blogs/38 官方自述】。
解决的核心问题：海量时序（尤其金融 tick、电力高频量测）的高吞吐写入、低延迟实时聚合、以及库内直接跑因子计算/回测，避免数据在数据库、消息队列、计算引擎间来回搬运。
URLs ：
- 官网：https://www.dolphindb.cn 【已查证】
- GitHub：产品服务端源码私有（闭源） ；官方 GitHub 组织 https://github.com/dolphindb 仅开放工具链（K8s 部署、插件、示例），非产品源码【已查证】。

发展历程

2016 年：浙江智臾科技有限公司成立，总部杭州【已查证：dolphindb.cn/about-us/company-profile】。
2018 年初：DolphinDB 首次公开发布（OLAP 纯列存引擎）【已查证：dolphindb.cn/blogs/38】。
2020 年前后：推出分布式集群、流计算引擎、金融插件生态【一方称：官方版本历史页】。
2022 年（V2.00） ：推出基于 LSM 树自研的 TSDB 存储引擎（行列混存），弥补 OLAP 引擎在高频写入、 updates/deletes、乱序场景的短板【已查证：docs.dolphindb.com TSDB engine 文档】。
2025 年（V3.00.0）：3.00 大版本线发布（与 2.00.12 同期）【已查证：dolphindb.cn/news/detail/259】。
2026-03-06（3.00.5）：流引擎低延迟模式增强【已查证：docs.dolphindb.com】。
2026-05-28（3.00.3 / 2.00.16）：企业级实时智能方向【一方称：dolphindb.com/blogs/19】。
2026-07-09（V3.00.6） ：最新稳定版；2026-07-13 发布 V3.00.6 & V2.00.19，并推出企业级 Agent 开发治理平台 DolphinX【已查证：dolphindb.com/blogs/48】。
当前最新版本（2026-10 口径） ：V3.00.6.2（2026-07-09，官方历史版本页标注"最新版"，维护到期 2027-07-08）【已查证：dolphindb.cn/history-versions】。

基本信息卡（表格）

项	值
开源/闭源	闭源商业软件（社区版可免费用于单机/小规模生产，企业版按节点授权）【已查证：官网下载页】
开发语言	C++（服务端）；内置 DolphinScript（类 Python + SQL）【一方称：官方文档】
当前最新版本（2026-10 口径）	V3.00.6.2（2026-07-09）【已查证：dolphindb.cn/history-versions】
License	商业专有许可（社区免费版 + 企业授权，非 OSI 开源）【已查证】
GitHub Star	--（产品无公开源码仓库）；官方 github.com/dolphindb 组织仅含部署工具/插件示例，非产品源码，故 Star 数对本产品不具代表性
维护组织	浙江智臾科技有限公司（杭州）【已查证】
官网 URL	https://www.dolphindb.cn 【已查证】
GitHub URL（工具链，非源码）	https://github.com/dolphindb 【已查证】

主要功能

双存储引擎：OLAP（纯列存，高压缩、批量分析）与 TSDB（基于 LSM 树的行列混存，支持高频写入、更新删除、乱序、块索引）【已查证：官方文档】。
分布式架构：控制节点管元数据与二阶段提交，数据节点存分区副本，存算分离可扩展【已查证：官方白皮书/文档】。
流计算引擎：低延迟流表、时间窗口聚合、流高可用（HA）、增量计算流式 SQL【已查证：docs.dolphindb.com】。
内置编程语言：DolphinScript（SQL + 向量函数 + 控制流），库内直接做因子计算与回测。
金融生态：内置大量金融函数（复权、因子、K 线、tick 处理）、行情插件、回测框架【一方称：官网金融方案页】。
多资产统一数据模型（V3.00.04 起）、MCP Server（对接 AI Agent）【已查证：dolphindb.cn/news/detail/400】。

核心优势

一站式：时序存储 + 流计算 + 库内编程在同一进程/集群，避免 ETL 搬运【一方称：官方定位】。
高写入吞吐 ：官方 4 节点集群实测约 1450 万条/秒（1.25 GB/s）（开启 dataSync）【一方称：docs.dolphindb.cn 集群扩展压测】。
金融高频数据压缩 ：官方称行情数据压缩比可达 10:1 以上，存储成本降约 80%【一方称：dolphindb.cn 金融方案页】。
国产替代：通过国家安全可靠测评，中文文档/社区完善，常被国内头部券商用作 kdb+ 替代【已查证：官方迁移文档】。
流批一体：流引擎与库表共用 SQL 语义，实时结果可直接落盘为历史表。

主要短板

闭源：服务端源码不开放，可审计性与定制深度受限【已查证】。
学习成本：需要掌握 DolphinScript 与集群运维，非标准 ANSI SQL【一方称：社区反馈】。
国际生态弱于 InfluxDB/TimescaleDB：云托管、第三方 BI 连接器、ORM 适配较少【一方称】。
免费版功能边界：集群与高级流/HA 功能多在企业版，需授权【已查证：官方版本说明】。

潜在风险与局限性

商业授权与商务条款驱动，预算敏感场景受限。
双引擎（OLAP/TSDB）选型与调优（分区大小建议 400MB--1GB）需要经验，误用会导致并行度下降或元数据膨胀【已查证：官方 TSDB 文档】。
作为较新国产产品，超长周期（10 年以上）生产验证案例仍在积累。

适用场景

量化金融：tick/L1/L2 行情存储、实时风控、因子计算、回测、投研数据底座。
电力/能源：新型电力系统高频量测（PMU、智能电表）、实时监控。
工业 IoT：设备高频数据接入、边缘到云同步【已查证：官方 IoT 方案】。
不适合：纯开源、零授权成本、强 ANSI SQL/标准 BI 生态的通用监控场景。

发展趋势

闭源产品无公开 Star 趋势；产品演进方向为流批一体 + AI Agent（MCP Server、DolphinX 企业 Agent 平台）+ 多资产统一数据模型，向"实时智能平台"延伸【已查证：dolphindb.com/blogs/48、news/detail/400】。
一句话总结：DolphinDB 以"时序库 + 流计算 + 库内金融编程"一体化巩固国内金融/电力高频市场，并开始向 AI Agent 实时数据底座扩张。

工作原理与核心架构

概念术语

OLAP 引擎：纯列存，每分区每列一个文件，批量分析压缩比高。
TSDB 引擎：基于 LSM 树的行列混存，分区内按排序列建块索引，支持高频写入与更新删除【已查证】。
控制节点（Controller）：管理分区元数据、版本链、副本、二阶段提交。
数据节点（Data Node）：实际存储分区副本、执行查询与写入。
分区（chunk）：分布式存储最小单位，建议压缩前 400MB--1GB【已查证】。
流引擎（Stream Engine）：订阅式实时计算，支持窗口聚合与高可用。
DolphinScript：内置 SQL + 向量过程式语言。
存算分离：计算节点与存储节点可独立水平扩展【一方称：白皮书】。

架构与运行原理

写入路径：客户端（C++/Java/Python/WebSocket）→ 任一数据节点 → 控制节点分配分区 → 多副本写入（OLAP 列文件或 TSDB LSM level file）→ 同步刷盘可选 dataSync。
存储引擎：OLAP 纯列存；TSDB 为 LSM 行列混存 + 块索引；数据同时可驻内存（内存表）。
查询路径：任意数据节点接收 SQL → 控制节点定位分区 → 并行扫描各节点对应分区 → 结果合并（MPP）。
集群拓扑：对等分布式（无固定主查询节点），控制节点 + 多数据节点，多副本容灾。

flowchart TD CL $客户端 API\C++/Java/Python/WebSocket$ --> DN1 $数据节点 1$ CL --> DN2 $数据节点 2$ CN $控制节点 Controller\分区元数据/二阶段提交$ --- DN1 CN --- DN2 DN1 --> OLAP $OLAP 引擎\纯列存文件$ DN1 --> TSDB $TSDB 引擎\LSM 行列混存$ DN2 --> OLAP DN2 --> TSDB ST $流计算引擎\窗口聚合/HA$ --> DN1 ST --> DN2 DN1 --> MEM $内存表\实时查询$

写入模式与查询特性

写入：批量 append 为主（OLAP 高吞吐）；TSDB 引擎支持高频小批量、更新删除、乱序写入（LSM 合并）；原生 TCP/WebSocket 二进制协议。
查询特性 ：时间窗口聚合 ✓（window/moving）、连续/增量聚合（流引擎物化）✓、降采样 ✓、TTL（dropPartition）✓、插值对齐（官方有 aj/区间函数，对标 kdb+ as-of join）--- 内建支持【已查证：官方文档】。

写入与查询性能特点

写入吞吐 ：官方文档实测------4 节点集群开启 dataSync 约 1450 万条/秒、1.25 GB/s，关闭 dataSync 随节点近线性扩展【一方称：docs.dolphindb.cn 集群水平扩展压测页】。
第三方对比（厂商自测） ：1000 万设备规模 IoT 场景，DolphinDB sustained 409,000 行/秒，对比 InfluxDB 24,000、TimescaleDB 192,000【一方称：dolphindb.com/blogs/54，厂商自测，未经第三方复核】。
压缩比 ：官方称金融行情 ≥10:1（存储成本降约 80%）【一方称：dolphindb.cn 金融方案页】。
查询：官方示例称读性能较 pickle 文件高 10 倍以上【一方称：docs.dolphindb.cn pickle 对比教程】。
所有性能数字均为官方/厂商自测口径，截至 2026-10 未查到独立第三方基准，引用时须标注。

支持的部署方式

单机（Linux 服务器版；社区免费）【已查证：官网下载】。
分布式集群（多节点，企业授权）。
Docker（官方镜像 dolphindb/dolphindb）【已查证】。
Docker Compose（多容器高可用集群示例）【已查证】。
Kubernetes：官方 dolphindb/dolphindb-k8s Helm/编排示例【已查证】。
Windows：主要作为客户端/开发端，服务端官方推荐 Linux【一方称】。

重要依赖

运行时：自包含 C++ 二进制，无外部数据库依赖；服务端官方支持 Linux（x86/ARM）【已查证】。
客户端：Java/Python/C++/C#/JavaScript(WebSocket) API。

生态与集成

客户端驱动：C++、Java、Python、C#、JavaScript、R【已查证：官方 API 文档】。
消息生态：MQTT 插件、Kafka 插件、WebSocket 流式推送【已查证：官方插件文档】。
大数据：可对接 HDFS、S3 兼容对象存储、边缘-云同步【一方称：官方 edge_to_cloud 文档】。
AI：内置 MCP Server（V3.00.04 起），可被 AI Agent 直接调用【已查证】。
可视化：官方 Web 控制台；第三方通过 JDBC/REST 接入 BI。

使用指南（精简）

安装（Linux） ：官网下载 Linux 压缩包，解压后运行 dolphindb（单机模式读取 dolphindb.cfg）；详见 https://docs.dolphindb.com/ 【已查证】。
Windows：可下载 Windows 版客户端/单机开发包体验，生产集群推荐 Linux【一方称】。
关键操作示例：

python 复制代码

// 1) 建库（按日期分区的 TSDB 库）
db = database("dfs://tickDB", RANGE, [date(2026.01.01)..date(2026.12.31)])
schema = table(1000:0, `ts`sym`price`vol, [TIMESTAMP,SYMBOL,DOUBLE,INT])
t = db.createPartitionedTable(schema, "trade", `ts)

// 2) 写入
t.append!(table(now() 2026.10.09T09:30:00.000 09:30:00.125 as ts,
               `AAPL`MSFT as sym, 189.2 428.5 as price, 100 500 as vol))

// 3) 按分钟窗口聚合 + as-of 对齐
select avg(price), sum(vol) from t group by sym, minute(ts)
aj(exec sym, lastPrice from snapshot, t, `sym`ts)

Q: DolphinDB 和 kdb+ 是什么关系？

A：直接对标与国产替代。官方维护《从 kdb+ 迁移到 DolphinDB》中文文档，语法与架构（流表、内存库、as-of join）刻意对齐，国内多家券商已用其替换 kdb+【已查证：docs.dolphindb.com/zh/tutorials/kdb_to_dolphindb.html】。

Q: DolphinDB 是开源软件吗？GitHub 上的项目是源码吗？

A：服务端闭源。GitHub 上的 dolphindb 组织只放 K8s 部署、插件、示例等工具链，产品核心源码不公开；社区版可免费用于生产但功能/集群规模受限【已查证】。

Q: OLAP 引擎和 TSDB 引擎怎么选？

A：纯批量分析、写入后很少修改选 OLAP（压缩比最高）；高频小批量写入、需要更新删除、乱序到达、高并发实时写入选 TSDB（LSM 行列混存）【已查证：官方 TSDB 引擎文档】。

Q: 它真能替代专门的流计算框架（Flink）吗？

A：在金融/IoT 实时窗口聚合、风控、因子计算这类场景，其内置流引擎与库表共用 SQL 语义，可省去 Kafka+Flink+库的拼接；但复杂 CEP、超大状态后端等通用流计算场景，生态成熟度仍不及 Flink【一方称：基于其功能边界判断】。

参考文献

Z FAQ for 时序数据库

Q: 时序数据库和普通关系型数据库到底怎么选？

一句话 ：数据是"持续产生、按时间追加、随时间老化"的流 → TSDB；数据是"实体 + 关系、需要事务与任意查询" → RDBMS；数据是"超大规模历史快照、多维分析" → OLAP。

实操判据：① 写入是否高频持续（秒级/毫秒级持续产生）；② 查询是否总带时间窗口；③ 是否需要 TTL/降采样自动老化。三个都"是"则 TSDB 是正确选择（详见第 4 章）。

Q: 厂商宣传的"千万点/秒""10 倍性能""压缩 10 倍"可信吗？

不可直接横向采信。本报告收录的此类数字均标注【一方称】（厂商自测基准或宣传口径），如 TDengine 官方 TSBS、DolphinDB 4 节点 1,450 万条/秒、IoTDB 压缩 10~15 倍。真实选型应：

用你自己的数据与硬件跑 TSBS / Time Series Benchmark Suite 类基准；
关注基数（cardinality）、乱序比例、查询混合是否与厂商基准一致；
闭源产品（kdb+、DolphinDB）无第三方可复现基准，生产验证成本更高。

Q: 高基数（high cardinality）问题到底是什么？为什么时序库更怕？

高基数 = 标签/序列组合数量爆炸（如把 user_id、URL 放进 label，序列数从几千涨到几亿）。TSDB 为每条序列维护索引与元数据，序列越多，内存索引越大、Compaction 越慢。

Prometheus 官方明确警告 label 基数过大会打爆内存与索引【已查证】；
openGemini v1.2.0 起才增强高基数时间线处理【已查证】；
TDengine 用"一设备一子表 + 标签索引"物理分片缓解【已查证】；
InfluxDB 3.x 宣称"无限基数"【一方称，未经第三方验证】。
对策：控制标签维度、分层聚合（原始 → 5 分钟 → 1 小时）、必要时按设备域分库。

Q: 数据量巨大时，TSDB 和 ClickHouse 谁更合适？

TSDB 胜 ：持续高频写入（append-only 写路径）、时间窗口实时查询、TTL/降采样自动老化、运维简单------时序负载。
ClickHouse/OLAP 胜 ：超大规模历史明细的任意多维分析、JOIN、复杂聚合------分析负载。
常见架构是两者共存：TSDB 承接实时时序，定期/按需导出到 OLAP 做深度分析（InfluxDB 3.x 的 Parquet 格式即为数据湖输出铺路【已查证官方】）。

Q: 8 款库如果要选型，第一步看什么？

第一步永远看场景而非性能数字：

是监控指标 （选 Prometheus 系）还是通用时序/IoT （选 IoTDB/TDengine/InfluxDB/openGemini）还是金融 tick （选 kdb+/DolphinDB）还是SQL 优先（选 TimescaleDB）？
是否必须开源 + 无厂商锁定（kdb+、DolphinDB、InfluxDB Enterprise、TDengine 企业版出局或需评估 License）。
是否已有 PostgreSQL / InfluxDB / Hadoop 生态需要兼容（对应 TimescaleDB / openGemini / IoTDB）。
最后才比写入吞吐、压缩比、集群能力------且用自测基准验证。

Q: 为什么说 Prometheus 不算通用时序数据库？

Prometheus 的本地 TSDB 是监控专用件：pull 模型 + 短期留存（默认 15 天）+ 单机不可扩展 + PromQL 面向指标告警。它不是为"长期海量时序存储/分析"设计的通用 TSDB；长期存储与水平扩展官方明确交给 remote write 生态（Thanos/Mimir/VictoriaMetrics）【已查证官方文档】。用它存业务时序明细属于越界使用。

报告完。 8 款数据库章节末尾各附推荐文献与参考文献（含全部信源 URL）。本报告数据以 2026-10-09 为准；【一方称】内容未经第三方独立验证，引用时请区分证据强度。

Y 推荐文献

$数据库/数据结构$ LSM-Tree ：结构化的日志合并树------NewSQL数据库的基石 - 博客园/千千寰宇

X 参考文献

时序数据库的技术难度如何？ - Zhihu

https://www.zhihu.com/question/23130520

[TSDB] 时序数据库的技术选型与横向调研：Apache IoTDB / InfluxDB / openGemini / TDengine / kdb+ / Prometheus / TimescaleDB / DolphinDB

0 序

调研声明

核心问题：时序数据库与关系型数据库 / OLAP 的本质区别与核心优势

总结

本质区别：六个维度的对比

数据模型：序列是"一等公民"，而不是"带时间戳的行"

写入模式：append-only 顺序写 vs 随机写 / 批量导入

数据生命周期：数据"会死"是设计前提，降采样是原生能力

查询范式：时间是查询语言的一等公民

存储引擎与压缩：B+Tree 行存 vs LSM/列存 + 时序专用编码

扩展性/一致性/部署模型

核心优势：写吞吐 × 压缩 × 实时查询 × 生命周期自动化

适用边界：什么时候不要用时序数据库

选型建议：场景 → 推荐

再次总结

摘要：主流的时序数据库

一、流行度与市占率

二、按场景分库与短板

1) 云原生/容器/微服务监控

2) 通用指标 / DevOps / 中小 IoT

3) 工业 IoT / 设备 / 车联网 / 边云

4) 金融行情 / 高频 tick / 量化

5) 时序+关系混合 / 要完整 SQL

6) 超大规模分析 / 日志型时序（非严格 TSDB）

三、技术调研必查清单

摘要：8 款时序数据库的定位对比

1 横向对比总表（8 款 × 关键维度）

1.1 基本信息对比

1.2 技术特性对比

2 时序数据库定位图谱

2.1 按"技术路线 × 场景定位"分类图谱

2.2 按"存储引擎 × 部署模型"再看一眼

2.3 补充解读

3 单库深度调研

3.1 【Apache IoTDB】（面向工业物联网的高吞吐、高压缩开源时序数据库）

产品介绍

发展历程

基本信息

主要功能

核心优势

主要短板

潜在风险与局限性

适用场景

同类竞品

发展趋势

工作原理与核心架构

写入与查询性能特点

支持的部署方式

重要依赖

生态与集成

使用指南（精简）

Q: IoTDB 1.x 和 2.x 有什么区别？该选哪条线？

Q: IoTDB 一定要用集群吗？最小生产部署是什么？

Q: IoTDB 能直接当 Grafana 数据源做监控大盘吗？

Q: TsFile 是什么？为什么强调边云同格式？

推荐文献

参考文献

3.2 InfluxDB（含 3.0）------从 Go+TSM 单机时序库演进为 Rust+Arrow/Parquet 列存、面向云原生分析的多模型时序平台

产品介绍

发展历程

基本信息卡（表格）

主要功能

核心优势

主要短板

潜在风险与局限性

适用场景

同类竞品

发展趋势

工作原理与核心架构

写入与查询性能特点

支持的部署方式

重要依赖

生态与集成

使用指南（精简）

Q: InfluxDB 1.x、2.x、3.x 该怎么选？

Q: InfluxDB 3 开源版和商业版差在哪？

Q: InfluxDB 兼容 Prometheus 生态吗？

推荐文献

参考文献