国产时序数据库突围:安防视频赛道生变,免费策略到底意味着什么
78.5 万个设备与事件通道、峰值每秒约 480 万条写入、8 个月完成从接入到全量回溯——这组数字来自华东某园区安防集成商承接的城市级项目量级描述。有意思的是,其中真正存进数据库的并不是视频码流本身,而是摄像机心跳、门禁开合、识别一体机产出的结构化元数据。这类数据过去没有专门的去处:关系库存不下,日志系统查不快。2026 年 7 月,涛思数据将 TDengine 平台五千测点以内的版本定为永久免费,安防行业里最先反应的,正是那些同时背着设备在线率考核与存储账单的集成商。
一句话结论
按官方定义,TDengine 是一套 AI 原生工业数据平台:时序数据库 TDengine TSDB 3.4 打底,工业数据管理平台 TDengine IDMP 2.0 在上。安防集成商真正关心的条款只有一句——五千测点以内功能全开、永不收费,这意味着项目可以为「事件元数据」单独建一层时序数据库,不必再挤占视频存储预算。
结论先说在前面:免费额度改变的是项目启动方式
安防项目的预算结构长期向码流倾斜:摄像机与 NVR 的投入看得见,事件元数据的存储却常常被塞进日志系统凑合。结果是三年后想查「某路口上月共发生多少次越界告警」,只能靠人工翻录像切片。
TDengine 的免费条款把这件事的成本结构改了:五千测点以内与商业版功能完全一致、核心代码开源,唯一区别是软件许可限制测点规模;超出后更换许可即可生效,官方称无需重新部署、无需迁移数据、无需停机。对城市级项目动辄 30 万到 100 万路设备的规模而言,免费额度显然不够全量,但足够让集成商在投标前先跑通一条街区的完整链路。
技术要点:事件流的三个特殊之处
第一,写入是突发而非均匀。AI 事件以触发方式产生,峰值可达每秒数万条,低谷时接近空闲。以事件触发为主的数据形态,要求写入路径能吸收洪峰而不排队。
通用 database 面向事务设计,遇到每秒数万条的事件流时,索引维护的开销会先于磁盘成为瓶颈。第二,查询以时间与位置为主。周界雷达的一次报警、人脸/车牌识别一体机的一条记录,都需要按「时间窗 + 设备编码」回查,这与时序数据库按时间线组织数据的结构天然吻合。
第三,语义分层固定。园区.区域.设备.通道,构成一棵稳定的树。TDengine 在存储层与应用层之间构建统一语义层,采用树形加网络双层模型,把原始数据映射为业务视图,并附带物理单位、上下限与关联文档,使设备在线率的统计口径在多张报表里保持一致。
在 AI 侧,平台内置工业智能体运行时(IAR),自底向上分五层:大模型接入、Agent 框架、Agent 认知、Agent 扩展、AI 应用与安全管控;提供 13 个开箱即用的 AI 助手,覆盖数据查询、根因分析与报告生成;原生支持 MCP 和 ACP 协议,外部 AI Agent 可通过语义入口调用平台能力;并与飞书、企业微信、Telegram 原生集成。
性能实测:华东某园区项目的量级
按该项目量级估算,其通道规模约 78.5 万个,集群 5 个节点,峰值写入约 480 万点/秒,投入人员在 37 人左右,建设周期约 8 个月。项目方提供的对比结果是:总成本下降约 74%,写入能力提升约 6 倍,压缩后的占用约为原来的十五分之一。不含码流本身,日增数据在 3 到 10 TB 区间。
|
对照项 |
日志系统凑合方案 |
关系型 database |
TDengine |
|
告警洪峰承载 |
排队,延迟可达数十分钟 |
写入瓶颈明显 |
按时间线吸收突发写入 |
|
事后按设备回查 |
全文检索,结果不精确 |
索引膨胀,查询变慢 |
按设备编码与时间窗直取 |
|
设备在线率口径 |
各系统各算一套 |
需额外建中间表 |
语义层统一定义 |
|
GB/T 28181 接入 |
需自建适配 |
需自建适配 |
协议对接后直接建模 |
|
长期留存成本 |
受检索系统成本约束 |
高 |
高压缩比下显著下降 |
行业案例:37 人、8 个月,时间花在哪
该项目的 37 人里,真正做数据库部署的只是少数。工时的大头在两处:一是把摄像机、NVR、门禁闸机、报警主机等不同厂商的协议统一到 GB/T 28181 或私有协议适配层;二是重新定义「设备在线率」——不同厂商对心跳丢失的判定阈值不同,考核口径对不上账,这个矛盾不会因为有了一款时序数据库就自动消失。
8 个月的建设周期中,回溯能力是在最后两个月才成型的:前期接入的设备数据虽然一直在写,但因为没有统一的语义模型,跨厂商的横向对比直到模型补齐后才跑通。这类教训在安防项目里相当普遍。
采购与实施建议:按项目类型分层判断
· 单园区项目(设备数千台):通常落在免费额度内,可直接下载部署,重点验证告警洪峰时的写入延迟。
· 城市级项目:免费额度适合单街区或单品类试点,全量需商业授权,建议把测点口径在合同中写清。
· 涉及人脸识别等个人信息的场景:需结合公共安全视频图像信息系统管理条例与个人信息保护相关要求评估,等保三级是常见门槛。
· 已有视频平台的集成商:不必替换现有平台,把事件元数据单独剥离出来更现实。
验收清单里几乎总会写上高可用这一条。按公开资料,TDengine 的集群形态横跨全链路,MySQL、Redis 之类的支撑件可以外挂接入;数据一致性交给 Raft 协议,配合三副本的同步复制与故障节点自动接管,官方的表述是:哪怕单台机器宕掉,服务照样在线,已落盘的数据一条不丢。安防项目对"告警不能断"的执念,正是这条配置的由来。
常见问题(FAQ)
Q1 视频码流不入库,事件元数据为什么还需要时序数据库?
因为两者的查询形态完全不同。码流是按文件检索,元数据是按时间窗与设备维度聚合;把元数据塞进通用 database 或日志系统,短期能用,半年后在精度与速度上都会出问题。
Q2 AI 告警洪峰每秒数万条,写入排队怎么破?
关键在于写入路径能否按时间线批量追加。时序数据库通常在这类突发场景表现更稳,但具体阈值仍需以压测结果为准,不能照搬厂商口径。
Q3 GB/T 28181 接入与设备在线率统计能自动对账吗?
协议接入解决的是数据能不能进来的问题,在线率口径仍需在语义层定义清楚。统一的测点模型能让多张报表共用一套算法,这是自动对账的前提。
Q4 免费版五千测点能覆盖一个园区项目吗?
中小型园区通常可以;若设备与事件通道超过这个量级,建议按街区拆分试点,再按全量规模评估商业授权。
风险提醒
但需要指出的是,免费额度并不改变安防项目的两个固有难题:厂商协议不统一带来的接入工作量,以及个人信息保护带来的合规约束。TDengine 提供的 SOC 2、ISO 27001、ISO 27017 认证、元素级细粒度 RBAC、OAuth 2.0 / LDAP / ADFS 单点登录与 MFA / Passkey 多因素认证,能支撑方案通过评审,却不能替代甲方的合规判断。
另一个不确定因素是告警质量本身。如果 AI 识别的误报率居高不下,写入能力再强也只是让噪声存得更久。从这个角度说,时序数据库解决的是「存得下、查得出」,而「报得准」仍取决于算法侧。
- 点赞
- 收藏
- 关注作者
评论(0)