---
url: /influxdb/introduction.md
description: >-
  InfluxDB是什么？全球第一的开源时序数据库，下载量超10亿，Rust重写后靠Arrow+DataFusion+Parquet打底，3.12让批量导入快了3倍，西门子能源拿它监控23000个电池模块
---

# 认识InfluxDB

先说个让人破防的数据对比。

你有一万台设备，每台每秒上报一次温度。一天就是 **8.64 亿条**数据。你把它们塞进 MySQL，建了索引、分了表、调了参数，然后眼睁睁看着磁盘三天涨到 2TB，一条"查某台设备最近一小时的平均温度"要跑 8 秒。

同样的硬件，换成 InfluxDB，同样的查询是 **毫秒级**，磁盘占用只有零头。

这不是玄学，是"通用数据库硬扛时序数据"这件事本身就不对。InfluxDB 是 **DB-Engines 上排名第一的时序数据库**，累计下载量超过 **10 亿次**。2026 年 10 月，它刚刚发布 **InfluxDB 3.12**。

> 通用数据库能存任何数据，所以它对任何数据都不够快。时序数据的特点是"只追加、带时间戳、按时间窗口聚合"——一旦你承认这个特点，优化空间是数量级的。

## 什么是 InfluxDB

InfluxDB 是一个开源的**时序数据库（Time Series Database，TSDB）**，也可以理解为广义上的**流数据库**。它专门为"像水流一样持续涌来"的数据设计：物联网传感器、服务器监控指标、工业遥测、金融行情、车联网轨迹、DevOps 可观测性数据。

它 2013 年就开源了，但真正脱胎换骨是 **InfluxDB 3**——用 **Rust** 从零重写，底层换成 **Apache Arrow + DataFusion + Parquet** 这套现代数据栈。

一句话定位：**为"永不停歇的数据"而生的数据库**。

注意它不是一个"带时间字段的 MySQL"。它从存储引擎、索引结构、压缩算法到查询优化器，全都是围绕时间戳重新设计的。

### 核心架构

InfluxDB 3 的性能来自四个设计决策：

* **Rust 重写的内核**：没有 GC 停顿，没有段错误，内存占用可预测。这是它能稳定扛住高吞吐写入的地基
* **Apache Arrow 列式内存模型**：数据在内存中按列存储，CPU 缓存友好，与其他 Arrow 生态工具（DuckDB、Polars、Spark）可以零拷贝交换
* **DataFusion 查询引擎**：SQL 引擎直接用 Apache DataFusion，天然支持 join、union、窗口函数。3.12 已升级到 **DataFusion 52.5**
* **Parquet + 对象存储的存算分离**：数据持久化成 Parquet 文件扔进对象存储，计算节点无状态。这就是官方说的 **diskless（无盘）架构**——可以完全不挂本地磁盘

### 数据模型

层级很朴素：**database（库）→ table（表）→ column（列）**。

如果你用过老版本，对应一下：database ≈ v2 的 bucket，table ≈ v1/v2 的 measurement。

列分四种：

* **time**：时间戳，纳秒精度
* **tag**：标签，带索引的元数据，比如 `sensor_id`、`region`。用来分组过滤，类似"维度"
* **field**：字段，真正的数值，比如 `temperature=23.5`。不索引，类似"度量"
* 类型支持 int64 / float64 / uint64 / bool / string

> 最容易踩的坑：InfluxDB 是 **schema-on-write**，你直接写数据它就自动建库建表，很爽。但 **tag 列定义是不可变的**——表一旦创建，tag 的顺序和结构就锁死了。所以别偷懒，头一批数据写进去之前想清楚哪些是 tag、哪些是 field。

## InfluxDB 的核心特点

* **极高的写入吞吐**：每秒数百万数据点，不需要你调索引、配分区
* **高压缩比长期存储**：Parquet + 对象存储，全分辨率存几年也不肉疼，无需强制降采样
* **毫秒级实时查询**：查询最新遥测数据支持亚秒级响应，够驱动实时调度和告警
* **SQL 原生支持**：基于 DataFusion 的完整 SQL，join、union、窗口函数都能写
* **InfluxQL 兼容**：从 v1 迁移过来的老代码不用重写
* **Last Values Cache（LVC）**：缓存每个序列的最后 N 个值，"最新状态"类查询 **10 毫秒内**返回
* **Distinct Values Cache（DVC）**：缓存指定列的去重值，元数据查询 **30 毫秒内**返回
* **Processing Engine**：数据库内直接跑 **Python 插件**，做数据转换和告警，不用另外搭一条流水线
* **InfluxDB 3 Explorer**：内置 Web UI，SQL 编辑器、看板、用户管理都在里面
* **Flight SQL 支持**：任何 Flight SQL 客户端都能连，Grafana 开箱即接
* **Telegraf 生态**：官方采集 Agent，**300+ 插件**，从 Redis 到 Modbus 到 MQTT 都能采
* **两个版本可选**：开源免费的 **Core**，和商业版 **Enterprise**

## 谁在用 InfluxDB

**西门子能源（Siemens Energy）—— 23000 个电池模块的预测性维护**

西门子能源用 InfluxDB 监控 **70 多个站点、23000 个电池模块**，实时分析数十亿条高频传感器读数。全分辨率留存让他们的预测性维护模型有足够的历史数据可训练，设备故障在被发现之前就被预警。

> 对储能来说，"某个电芯三个月前开始的温度漂移"才是真正的故障信号。你要是提前降采样了，这个信号就没了。

**LeoLabs —— 每秒 7000 行，追踪 27000 个太空目标**

LeoLabs 运营全球相控阵雷达网，监控轨道上的 27000+ 个物体。他们的雷达站点每秒产生 **7000 行数据、每天 6 亿行**，覆盖发射功率、服务器指标、放大器状态、环境条件。

换算下来：约 **1000 条告警规则**，每条数据都要过一遍规则检查。普通数据库在这个量级早跪了，而他们的告警能在 **30 秒内**触发。

**Enprove —— 每秒 35000 个值，查询快 6 倍**

能源管理方案商 Enprove 用 InfluxDB 驱动实时看板，跟踪工厂、公用设施和各类站点的能耗表现。每秒摄入 **35000+ 个值**，查询速度比之前快 **6 倍**。

**Epsilon3 —— NASA、Blue Origin、Axiom 都在用**

航天任务执行平台 Epsilon3 把遥测监控嵌进了电子操作流程里，服务 NASA、Blue Origin、Axiom 等机构，支撑了 **100 多次航天发射**，包括国际空间站任务。操作员一边执行流程一边看实时遥测，步骤可以自动等待系统达到某个物理条件再推进。

**Seadrill —— 省下 5500 万美元**

海上钻井承包商 Seadrill 用 InfluxDB 替换了老旧的实时数据库和关系库。每座钻井平台通过卫星宽带以亚秒级更新推送 **15000 到 22000 条时间序列**。从"按日历保养"改成"按状态保养"，资产全生命周期成本省了约 **5500 万美元**。

## 3.12 这次更新了什么

2026 年 10 月发布的 **InfluxDB 3.12**，主线是四个字：**更能长了**。官方博客的原话是——部署一旦跑起来，就会吸引来更多东西：几个月的回填数据、脉冲式写入、更多团队往同一个库里写。

**批量导入快了约 3 倍**

从 Parquet 批量导入，现在并行执行，能吃满 CPU。官方测试里导入时间下降 **64%–70%**。

顺带修了个权限上的别扭事：批量导入以前必须用 admin token，现在只需要目标库的 **写权限**。跑回填任务的凭证终于不用拿到整库的钥匙了。

**分布式压缩（beta）**

压缩（compaction）负责把刚写进来的数据在后台整理成高效的文件，查询才快。但写入量一大，压缩就跟不上，以前的唯一解法是**换更大的机器**。

3.12 把这个天花板掀了。压缩任务可以跑到集群里的**每一个 compact 节点**上，不再只有持有 compactor lease 的那个节点在干活。加节点就行，横向扩展。某个节点中途挂了，它的活会在下一个调度周期被重新分配。

默认是关的，老集群升级后行为完全不变。

**按库强制 schema（`--schema-mode explicit`）**

schema-on-write 上手很爽，但在多个团队共用的生产库里是坑：某个服务把字段名拼错了，或者多写了一列，这个错误就悄悄变成了 schema 的一部分，所有查这个库的人都要绕着走。

3.12 让你可以在建库时锁死 schema：

```bash
influxdb3 create database --schema-mode explicit
```

之后凡是写入了没声明过的表和列，直接**拒绝**。脏数据在写入那一刻就被拦下，而不是等它上了仪表盘再回头查。

注意三点：默认还是 `implicit`（schema-on-write）；库建完之后 schema mode 改不了；Core 不支持，会返回 400。

**RBAC 用户认证正式可用（GA）**

用户名密码登录、单点登录（OAuth）、基于角色的访问控制在 Enterprise 里 GA 了，内置 Admin / Auditor / Member 三种角色。以前权限管理是"追着一堆 token 跑"，现在按人按角色统一治理。

默认是关的（`--user-auth-type` 默认 `none`），现有 token 工作流不受影响。

**Processing Engine 独立进程**

以前自定义 Python 插件和数据库跑在一个进程里，插件写崩了可能拖垮数据库。现在 Processing Engine 可以跑成独立进程，一次有问题的插件更新被隔离在里面，数据库继续运行。

顺带 WAL trigger 的范围也扩大了：写入到**任意一个** ingest 节点的数据，都会在 process 节点上触发，不再只在你写入的那个节点触发。

**Explorer 1.11**

新增六种可视化：面积图、单值、仪表盘、饼图、散点图、排行榜。SQL 编辑器里加了 `EXPLAIN ANALYZE`，能直接看查询在干什么。

> 六张图听起来没什么，但对一个天天盯时序曲线的团队来说，这意味着"不用再为了一个仪表盘去 Grafana 里折腾半天"。

## 初体验：10 分钟跑起来

装 Core 就两条路。

**方式一：Docker（推荐先试这个）**

```bash
docker run -it --rm --name influxdb3-core \
  -p 8181:8181 \
  -v "$PWD/influxdb3-data":/var/lib/influxdb3 \
  influxdb:3-core \
  influxdb3 serve \
    --node-id my-node \
    --object-store file \
    --data-dir /var/lib/influxdb3
```

**方式二：本地安装**

macOS / Linux 用官方脚本：

```bash
curl -O https://www.influxdata.com/d/install_influxdb.sh
sh install_influxdb.sh
```

然后启动：

```bash
influxdb3 serve \
  --node-id host01 \
  --object-store file \
  --data-dir ~/.influxdb3
```

> 开发机上你可以直接敲 `influxdb3` 不带任何参数，它会自动生成 node-id、用本地文件存储、数据目录指向 `~/.influxdb`。但生产环境别这么干，老老实实把参数写全。

**第一步：建 admin token**

服务起来了，另开一个终端：

```bash
influxdb3 create token --admin
```

返回的 token 字符串**只显示一次**，存好，之后查不回来。然后设成环境变量：

```bash
export INFLUXDB3_AUTH_TOKEN=你的token
```

> 安全提醒（官方文档里加粗的那种）：在第一个 admin token 创建出来之前，`/api/v3/configure/token/admin` 接口接受未认证请求，而服务默认监听所有网卡。这个窗口期里任何能访问到端口的人都能抢走 operator token，然后用 Processing Engine 在你的机器上跑代码。要自动化部署，直接用预配置 admin token 启动。

**第二步：写数据**

InfluxDB 用的是 **Line Protocol（行协议）**，人肉可读：

```
表名,标签键=标签值 字段键=字段值 时间戳
```

来个真实点的例子——机房温湿度：

```bash
influxdb3 write \
  --database sensors \
  'home,room=Living\ Room temp=21.1,hum=35.9,co=0i 1791878400
home,room=Kitchen temp=23.0,hum=36.2,co=1i 1791878400
home,room=Kitchen temp=23.3,hum=36.9,co=18i 1791914400'
```

不用先建库建表，写完 schema 自动就有了。

用 HTTP API 也行：

```bash
curl -X POST "http://localhost:8181/api/v3/write_lp?db=sensors&precision=second" \
  --header "Authorization: Bearer $INFLUXDB3_AUTH_TOKEN" \
  --data-raw 'home,room=Kitchen temp=23.1,hum=36.6,co=22i 1791918000'
```

**第三步：查数据**

直接写 SQL：

```bash
influxdb3 query \
  --database sensors \
  "SELECT * FROM home ORDER BY time DESC LIMIT 10"
```

窗口聚合，比如每 3 小时的平均湿度：

```bash
influxdb3 query \
  --database sensors \
  "SELECT
     date_bin(INTERVAL '3 hours', time) AS window_start,
     room,
     AVG(hum) AS avg_humidity
   FROM home
   WHERE time >= now() - INTERVAL '7 days'
   GROUP BY window_start, room
   ORDER BY window_start"
```

老 InfluxQL 用户加个 `--language influxql` 就行。

**第四步：打开 Web UI**

浏览器访问 `http://localhost:8181`，Explorer 界面在里面，写 SQL、建看板、管用户都在这一处。

## Core 还是 Enterprise

这是最常被问的，直接给结论：

| 维度 | InfluxDB 3 Core | InfluxDB 3 Enterprise |
|------|----------------|----------------------|
| **协议** | 开源（MIT/Apache 系） | 商业授权 |
| **定位** | 实时监控 + **近期数据** | 近期 + 历史全量分析 |
| **查询时间范围** | 约 **72 小时**上限 | 无限制 |
| **分布式压缩** | 不支持 | 支持（3.12 beta） |
| **schema 强制** | 不支持（返回 400） | 支持 |
| **RBAC / 用户认证** | 不支持 | 支持（3.12 GA） |
| **高可用 / 只读副本** | 不支持 | 支持 |
| **备份与恢复** | 不支持 | 支持（全量/增量） |
| **行级删除** | 不支持 | 支持 |

> 说实话，Core 那个 72 小时限制挺劝退的——它是官方刻意划的线，为的是把商业版卖出去。但换个角度想：如果你只是做本地监控、原型验证、或者把 InfluxDB 当"最近数据的缓存层"（历史数据落 Parquet 交给 DuckDB/Spark 分析），Core 完全够用，还免费。

## 进阶

InfluxDB 值得知道的，不只是"时序数据库"这四个字。

它的技术路线其实很有代表性：**用 Rust 重写内核 + Arrow 做内存格式 + DataFusion 做查询引擎 + Parquet 做存储格式 + 对象存储做底座**。这一整套不是 InfluxDB 自己造的，而是把开源数据栈的现代组件拼在了一起。RisingWave、GreptimeDB 这些新秀走的是同一条路。

3.12 这一版的信号也很清楚：时序数据库的下半场，拼的不是"能写多快"，而是\*\*"能不能一起长大"\*\*。导入能不能并行、压缩能不能横向扩、schema 能不能管住、权限能不能治理——这些"长大之后才痛"的问题，才是企业级场景掏钱的理由。

如果你手上有传感器、有监控指标、有每秒都在涨的数据，花十分钟 `docker run` 一下，比看十篇文章管用。

更多开源技术干货和学习资料，关注公众号「遇码」，领取专属福利。