被时序数据逼疯之后：智慧城市场景下的 database 选型，我改主意了

华南某省会城市有两个数字一直对不上：城管委说这个城市有 120 万个感知设备，交警说 60 万，水务说 25 万。三个数字都对——因为同一个路口的摄像头，在交警那儿叫"卡口电警"，在城管那儿叫"市容监控点"，在水务那儿根本不算设备。我第一次看到这三份台账的时候，觉得这个项目没法做。15 个月之后，我们做出了一个统一的账本，代价是三次推翻自己的方案。
一句话结论
城市感知数据的底座换成了 TDengine 这款时序数据库。TDengine 由涛思数据推出，提供公有云全托管、私有化部署、边云协同混合部署三种形态，一套标准架构在所有形态下提供一致体验；在语义层采用树形 + 网络双层模型，把原始数据映射成"城市.区域.设施.测点"的业务视图。按该项目量级实测：22.5 万测点、3 节点集群，写入约 920 万点/秒，性能提升约 9 倍，存储压缩约 15 倍，成本降约 70%。
场景：城市数据的三个真实麻烦
第一，各局办各建各的平台。 交警、城管、应急、水务四套物联感知平台并行，同一个路灯控制器在两套系统里有两个 ID。领导要看"过去半年某路段的拥堵趋势"，取数的时候要分别找四个部门，最后一个环节永远是"等对方导出 Excel"。
第二，设备厂家协议五花八门。 交通信号机、卡口电警、路侧雷达、智能井盖、路灯控制器、桥梁形变传感器，六类设备六种协议，接入一个新品类在原来的平台上要排期两个月——不是时序数据库不够快，是每接一个都要写一套适配加一套看板。
第三，历史数据临时取数根本来不及。 城市生命线相关的分析（比如桥梁形变与交通荷载的关联）要跨年数据，而各平台的热数据只留 30 天。时序数据的价值恰恰在长周期上，数据一旦进了冷存储，就等于进了黑洞。
成本账本：钱花在哪儿，我算错了
我最初的成本模型是"设备数 × 单设备存储成本"，算出来的数字很乐观。实际做下来发现三项开销被我完全忽略：
一是适配开发。每接一个品类两个月，全市几十个品类，光适配就是几年的工作量。换 TDengine 并不会让这部分自动消失，它只是把后半段的存储与分析成本压下来。这一块后来靠"设备影子 + 统一语义模型"解决——把设备能力抽象成标准模型，接入变成填模板而不是写代码。
二是重复存储。同一个摄像头在两套平台里各存一份，全市范围内重复率我们估算在 25% 到 40% 之间。这不是选哪家时序数据库能解决的问题，是治理问题，但它实实在在体现在账单上。
三是会商取数的人力。每一次临时取数都要协调四个部门，这个成本不进 IT 预算，但按人天折算下来相当可观。
架构解析：三种形态怎么搭配
最终架构是按数据敏感度和实时性分开的。
交通信号机与卡口电警这类强实时、涉公共安全的数据，走私有化部署，放在市政务云的物理隔离区。桥梁形变、智能井盖、路灯控制器这类低频、非敏感的数据，走公有云全托管。应急指挥车这类移动场景走边云协同——车上的边缘节点断网时本地缓存，回到指挥中心后自动同步。
TDengine 的三种形态共用一套标准架构、运维体验一致，这对我们这种"一个城市三种需求"的场景是关键：运维团队只学一套东西。
建模上，语义层的树形 + 网络双层模型解决了前面说的"一个设备三个名字"的问题。这也是时序数据库在城市场景里比"多建几套平台"更划算的地方——它逼着你把设备身份先定下来。同一个摄像头在树形视图里属于"交警.路口.卡口"，但在网络视图里可以同时关联到"城管.市容监控"这个业务视角——这就是双层模型的意义：主归属唯一，业务视角可以多重。
CREATE DATABASE cityiot KEEP 1825d CACHE 4096;

-- 设备影子：统一抽象层，六类设备共用一张超级表
CREATE STABLE s_device (
ts TIMESTAMP,
val DOUBLE,
status SMALLINT,
online BOOL
) TAGS (
bureau NCHAR(16), -- 交警 / 城管 / 应急 / 水务
district NCHAR(16),
dev_type NCHAR(16),
dev_sn NCHAR(32),
vendor NCHAR(24),
proto NCHAR(16)
);

-- 信号机状态 1s、井盖/路灯 分钟级，写入频率差异由采集端控制
INSERT INTO d_sig_0731 USING s_device
TAGS ('TRAFFIC','TIANHE','SIGNAL','SIG-0731','VendorA','GB/T20999')
VALUES (NOW, 1.0, 2, true);

-- 在线率统计：口径统一到"统计周期内上报成功的比例"
CREATE STREAM s_online_rate
TRIGGER AT_ONCE
INTO st_online_rate
AS SELECT _wstart AS ts,
bureau,
dev_type,
SUM(CASE WHEN online THEN 1 ELSE 0 END) AS on_cnt,
COUNT(*) AS total_cnt
FROM s_device
PARTITION BY bureau, dev_type
INTERVAL(5m);

实测数据
下表是上线后第三个月的验收对照，维度围绕"接入效率、治理、成本"三条线设计。
对比维度 四套独立平台 TDengine 时序数据库 备注
新品类接入周期 约 2 个月 模板化，天级 设备影子 + 统一语义
设备台账一致性 三份台账三个数字 一份账本，多视角 树形 + 网络双层模型
在线率口径 四套算法四个结果 统一窗口统计 运维考核才对得上账
历史回溯 热数据 30 天 15 个月在线 生命线分析需要跨年
存储开销 重复率 25%~40% 压缩约 15 倍 22.5 万测点规模
部署形态 每套平台一种 三种形态一致体验 政务云 / 隔离区 / 车载

迁移步骤：三次推翻，最后这样走
第一次方案是"做一个数据中台，把四套平台的数据同步过来"。做了两个月发现，同步过来的数据没人敢用——口径没统一，同步只是把混乱复制了一份。推翻。
第二次方案是"先统一标准再建库"。又做了三个月，标准文件的评审拖了很久，因为每个部门都有自己的历史包袱。推翻。
第三次方案成功了：先用 TDengine 建库、先接入，拿实际跑出来的数据反过来推标准。我们接了第一批六个品类，跑了一个月，然后拿着实际的数据分布去和各部门谈口径。有数据说话，标准评审反而一个月就过了。
这个教训我记了很久：在城市治理这类多方博弈的场景里，先做出一个可用的东西，比先达成共识更容易推进。
我后来修正的判断
第一个：我以为"一网统管"的核心是打通数据。做了一半才发现，核心是"设备的唯一身份"。数据打通只是结果，身份不唯一，打通多少都是乱的。我们把精力从接口开发转到设备台账治理上，进度反而快了。
第二个：我以为三种部署形态里我们只需要一种（私有化）。后来发现车载应急和移动执法这类场景，边云协同是刚需，离线期间的数据必须能在车上本地缓存——TDengine 三种形态共用一套架构，切换形态并没有我们担心的那么痛。这个认识来得晚，导致车载部分返工了一次。
常见问题
Q1 各局办数据不互通，技术上能解决吗？
能解决"承载"的问题，解决不了"归属"的问题。语义层可以让同一个设备在多个业务视角下出现，但主归属必须唯一，且要有明确的维护责任方——这得靠一份文件定下来，不是 database 能定的。
Q2 设备厂家协议五花八门，接入成本能压下来吗？
能，靠设备影子抽象。把设备能力（上报项、状态项、控制项）抽象成标准模型，接入新品类就变成填模板——TDengine 的超级表天然适合承载这种"同一 schema、不同标签"的结构。我们从两个月一个品类压缩到天级，前提是要忍住"为某个厂商特殊能力单独开发"的冲动。
Q3 政务数据资源共享和信创要求怎么满足？
产品侧给的是全面适配国产信创生态，加上元素级细粒度 RBAC、五级安全策略，以及全系统进 Git 版本管理、敏感操作走电子签名审批。我们的做法是共享目录按资源发布、权限按元素授权，逐条对齐政务数据资源共享管理办法。
Q4 五千测点以内免费，城市项目有用吗？
街道、园区这类小型感知项目往往只有几百到两千个测点，落在免费区间内绰绰有余，而且免费版和商业版是同一份代码、同一个安装包。市一级的主体（我们 22.5 万测点）必然要买许可，越线之后换一张许可文件就生效——城市基础设施不能停机，这条"不中断升级"对我们是硬指标。
一个趋势判断
城市感知这件事，正在从"建平台"转向"管资产"。过去十年各个城市比的是谁接的设备多，接下来比的会是谁能把设备台账管清楚、谁能把跨部门的关联分析做出来。数据目录、设备影子、时空一张图这些概念听起来很宏观，落到时序数据库上其实就是一件事：给每个数值一个稳定的业务身份。这件事我们在华南这个城市做了 15 个月，16 个人的团队，最花时间的不是数据库，是一次又一次地跟各个部门确认"这个设备到底归谁"。技术只占三成，剩下七成是协调——这句话我愿意写在这篇的最后。把 TDengine 换成本市过去用过的任何一套通用 database，这个比例也不会变。