一、什么是时序场景？⏳
时序场景的核心的就是围绕时间维度做文章——按指定间隔采集记录数据并存储，就像温度传感器每秒都会记下当前温度一样。而且这类场景往往有明确的查询分析需求，还带着几个鲜明特点：
- 数据量超大：设备多、指标杂、采集频率高，得能支撑海量设备和指标的并发处理；
- 数据持续流入：秒级、分钟级的实时数据不断入库，对接收能力是不小的考验；
- 查询要高效：既要能快速搞定特定时间段的连续聚合查询（比如查过去一周某设备的运行数据），也得支持各类专项分析查询，响应速度得跟上；
- 成本要可控：时序数据有时效性，过了一定时间就没那么大价值了。所以数据压缩、冷热数据分离这些功能必不可少，能大大降低存储成本。
我们的目标，是成为世界卓越的数据库产品与服务提供商！🌟
二、丰富的应用场景 🌐
时序数据库的应用范围广，几乎覆盖了多个关键行业和领域：
（一）核心应用方向
- 实时分析与流式数据处理：金融交易、用户行为事件流、点击流分析这些场景，都需要在数据到达的瞬间就做复杂统计分析。就拿股票交易来说，数百万条行情数据点能被秒级聚合计算指标，直接为实时决策系统提供支撑。根据Gartner报告，到2025年，全球超过80%的金融交易系统都会采用高并发时序数据库；
- 工业控制与大数据存储：工业控制系统里，大量传感器和日志产生的海量数据，既需要可靠存储，也得支持长期趋势分析；
- 高基数型数据管理：智慧城市里成千上万个交通传感器、物流追踪中每件商品的状态变化——这类需要跟踪大量独立实体时间序列数据的场景，时序数据库都能hold住，像智慧城市、车联网、供应链跟踪等领域都能用；
- 混合负载场景：有些场景既要处理事务性写入，又要做分析性查询，比如线上游戏运营。一方面要持续记录玩家在线数、操作日志等行为事件，另一方面还得定时统计在线人数、行为频次，帮运营团队做决策，时序数据库就能完美适配这种边写边分析的需求。
（二）各行业具体用途
| 市场 | 用途 |
|---|
| 金融 | 管理交易数据、市场数据，支撑风险管理、合规监控和投资决策 |
| 电信 | 实时监控分析网络性能、用户行为和设备状态，优化网络资源分配、提升服务质量 |
| 制造 | 监控生产设备状态、分析生产数据，助力智能制造和预测性维护 |
| 能源 | 监测能源消耗、优化能源分配，提高能源利用效率 |
| 其他 | 在智慧城市、医疗健康等领域也有广泛应用 |
三、时序产品市场规模与竞争格局 📈
（一）市场规模
2024年，全球时序数据库市场规模已经达到3.88亿美元。随着物联网和云平台的兴起，时序数据规模正以前所未有的速度爆发式增长——依托海量传感器的智能硬件、智能制造，再加上云数据库本身具备的高成本效益、强大数据处理能力和高灵活性，越来越多客户开始青睐这类解决方案。
（二）全球主流产品市场份额
| 产品 | 应用领域 | 全球市场份额 |
|---|
| InfluxData | 物联网和DevOps | 20% |
| Oracle TimesTen | 金融、电信等行业 | 15% |
| IBM InfoSphere TimeSeries | 金融、电信等行业 | 10% |
| 亚马逊AWS | 云 | 25% |
| 微软Azure | 云 | 15% |
| 谷歌Cloud | 云 | 10% |
（三）竞争格局
时序数据库行业发展势头迅猛，吸引了众多企业入局，市场参与者越来越多。有意思的是，商业模式上呈现出明显的国内外差异：国外以开源为主，国内则偏向商业路线。
- 国内开源时序数据库代表：Tdengine、openGemini、CeresDB等；
- 国内商业时序数据库代表：KaiwuDB、DlhinDB、UTSDB、TimeLyre等。
截止2025年6月，全球时序产品数量为41个，较上年同期减少14个；中国时序产品数量17个，较上年同期有显著增长。
（四）国内主要厂商及产品特点
| 厂商 | 产品 | 部署方式 | 商业模式 |
|---|
| 浪潮云嘉 | - | - | 商业 |
| - | - | 分布式 | 商业 |
| 清华大学 | Apache loTDB | 分布式/集中式 | 商业/开源 |
| 西安索思信息科技有限公司 | SourceDB openGemini | - | - |
| 诺司时空 | CnosDB | 分布式/集中式/云原生 | 商业/开源 |
| 格睿科技 | GrepttimeDB | - | 商业/开源 |
| 四维纵横 | YMatrix | 分布式 | - |
| 紫金桥软件 | RealHistorian | 分布式 | - |
| - | GoldenData | 集中式 | 商业 |
| 优刻得 | UTSDB | 集中式 | 商业 |
| - | - | 集中式 | - |
| 亚控科技 | KingHistorian | - | - |
四、金仓时序数据库（KES）现有产品情况 🚀
（一）强大的数据迁移能力
KES支持多种数据源的迁移，不管是国外主流数据库、国产数据库，还是时序数据库、消息队列、大数据平台、分布式数据库，大多都能实现源端到目标端的顺畅迁移。
1. 主流数据库迁移支持
| 类别 | 数据源 | 源端 | 目标端 |
|---|
| 国外交易型数据库 | Oracle | 支持 | 支持 |
| SQL Server | 支持 | 支持 |
| MySQL/MariaDB | 支持 | 支持 |
| DB2 | 支持 | 支持 |
| Informix | 支持 | 支持 |
| PostgreSQL | 支持 | 支持 |
| Sybase | 支持 | N/A |
| NoSQL | MongoDB | 支持 | N/A |
| ElasticSearch | 支持 | 支持 |
| Redis | 支持 | 支持 |
| 国产交易型数据库 | KinbgaseES | 支持 | 支持 |
| DM | 支持 | 支持 |
| Gbase8s | 支持 | 支持 |
| Oceanbase | 支持 | 支持 |
| PolarDB | 支持 | 支持 |
| openGauss | 支持 | 支持 |
| Vastbase | 支持 | 支持 |
| PanWeiDB | 支持 | N/A |
| AntDB | 支持 | 支持 |
2. 时序数据库、消息队列等迁移支持
| 类别 | 数据源 | 源端 | 目标端 |
|---|
| 消息队列 | Kafka | 支持 | 支持 |
| RabbitMQ | 支持 | 支持 |
| RocketMQ | 支持 | 支持 |
| 时序数据库 | OpenTSDB | 支持 | N/A |
| InfluxDB | 支持 | N/A |
| TDengine | 支持 | N/A |
| 大数据 | 星环 Inceptor/ArgoDB | 支持 | N/A |
| Hive | 支持 | 支持 |
| 分布式数据库 | TDSQL | 支持 | 支持 |
| KADB | 支持 | 支持 |
| Greenplum | 支持 | 支持 |
| Clickhouse | 支持 | 支持 |
| Gbase8a | 支持 | 支持 |
| 华为DWS | 支持 | 支持 |
注：标红为新支持项
（二）全面的工业化接口
KES兼容所有主流工业化接口，支持多种工业级数据传输协议，像OPC-UA、modbus、mqtt、http、Websocket等，能轻松对接终端设备、芯片、采集代理、日志、监控分析平台、程序等各类终端和系统，数据传输无障碍。
（三）亮眼的性能优化
- 集群数据插入速度飙升：支持预定义子表，完美解决集群多节点插入时的分区阻塞问题，多个节点能并行插入数据，实现线性插入效率；
- 数据更新性能大幅提升：数据在压缩状态下也能直接更新，更新性能一下子提升了50%；
- 并行创建时序分区：支持在节点间并行创建时序分区，进一步提升整体处理效率。
（四）实用的冷热数据分离
满足指定条件的数据，会自动移动到不同的表空间，既保证了热点数据的访问速度，又能合理利用存储资源，降低整体存储成本。
（五）完善的sharding集群监控运维
支持单机、RWC部署，还完善了sharding集群监控功能：不仅完成了多节点集群的运维指南，Kemcc也支持sharding和kwc，能实现对sharding集群和kwc集群的全面监控运维。
（六）典型案例：海洋观测监测系统信创升级 🚢
1. 项目基本情况
2024年，该项目对预警报产品制作发布系统、智能网格海上突发应急决策系统进行信创升级改造，以满足海洋观测监测能力使用需求。
2. 业务规模
- 涉及船舶12-15万艘，12-15万台终端定位数据；
- 日峰值写入3000万条数据，预估3年需支持300亿条定位数据的查询分析。
3. 架构升级
- 原系统：Intel芯片 + Redhat操作系统 + 5节点GP数据库；
- 新环境：x86 + 统信UOS操作系统 + 3节点KES Sharding。
4. 用户核心痛点
- 痛点1：新增数据压力大，历史数据容量高，写入和统计都需要横向扩展方案支撑；
- 痛点2：平台未来会接入更多数据，需要灵活的扩展能力。
5. 金仓解决方案
- KES Sharding方案提供数据写入吞吐量、容量和查询的全方位扩展能力；
- 5节点（32VCPU/64G）分片，最高可支持1.5亿/天的1KB数据写入；
- 按年查询涉及5个节点共100亿行数据的某一范围船舶信息，能实现毫秒级响应；
- 总体性能表现超过GP数据库及其他竞争对手。
6. 核心价值呈现
- 高性能：5节点100亿条数据，毫秒级响应；
- 灵活扩展：依托Sharding分片技术，轻松应对业务增长；
- 大数据量写入：1.5亿/天的1KB数据写入能力，满足高并发需求。
五、金仓时序数据库面临的形势 📋
（一）核心能力对比
| 能力 | 描述 | Kingbase表现 |
|---|
| 数据类型 | 支持数值、字符时间、布尔、枚举等数据类型存储；支持GIS | 都支持，包括SQL中所有类型 |
| 数据模型 | 采用国产数据库产品，支持树形物联网模型管理时序数据，支持灵活增删，树形结构的路径不少于20层（尽量测试到极限高于20层），创建设备模板并在数据写入时动态扩展模板 | 不支持 |
| 数据写入 | 1. 写入性能：每秒最大可支持千万级时指标点写入；2. 支持的数据采集容量：支持数据库容量不低于200万点（尽量测试到极限可高于200w点）；3. 支持实时/历史数据并发写入，支持批量数据写入，支持时间随机乱序历史数据写入；4. 支持缓存、断点续传，支持edge版本；5. 支持数据补充 | 1. 单机支持秒级千万行指标；2. 原则上不限制；3. 支持；4. 不支持；5. 支持 |
| 查询 | 1. 提供常用的SQL查询、基于时间的聚合查询；2. 支持关系数据和时序数据混合存储和处理分析，多表关联；3. 支持时空联合查询；4. 支持特定高级查询 | 1. 支持；2. 支持；3. 支持；4. 不支持 |
| 事务 | 支持事务，支持ACID | 支持 |
| 访问接口 | SQL | 支持 |
| 数据存储 | 1. 支持冷热数据分级存储；2. 支持生命周期管理，支持历史数据的滚动删除；3. 支持基于字段类型匹配压缩算法，支持有损和无损压缩，压缩比1:40 | 1. 支持；2. 支持；3. 压缩比可以到5:1到10:1 |
| 可扩展性 | 1. 支持计算/存储分离架构，可根据业务负载在线灵活添加/删除计算节点/存储节点；2. 支持sharding，支持数据分片和负载均衡机制，实现系统数据容量和性能的线性伸缩 | 1. 支持；2. 支持 |
| 支持的工业协议 | OPC DA、OPC AE、OPC UA、MODBUS TCP、Modbus RTU、IEC-101、IEC 104、CDT、BACNet、WebService、SQL、RestAPI、MQTT | 支持较少 |
| 其他 | 1. 支持流批处理，支持流数据、批处理数据的集成；2. 支持数据迁移（支持业界主流时序数据库的迁移：influxdb、tdengine、opentsdb）；3. 安全：支持采集点的策略；4. 支持订阅同步（支持异构数据库集群和时序数据库集群间的数据双向实时同步） | 1. 支持；2. 支持；3. 不支持；4. 支持 |
（二）竞品核心指标对比
| 对比项 | 二级对比项 | KES_TSDB | TDengine | influxdb | IotDB |
|---|
| 监控指标容量 | 采集点 | 亿级 | 亿级 | 百万级 | 千万级 |
| 数据加载 | 每秒多少指标项入库 | 单机千万级 | 单点百万级，集群千万级 | 秒级百万指标 | 单机千万级，集群亿级 |
| 存储-压缩算法 | 一级压缩算法个数 | 7 | 7 | 8 | 9 |
| 二级压缩算法个数 | 1 | 5 | 2 | 5 |
| 时序查询能力 | 聚集查询 | SQL支持完全 | SQL不完整 | SQL不完整 | 类SQL |
| 分析函数 | 45 | 25 | 12 | 23 |
| 时序函数 | 10 | 11 | 5 | 9 |
| 扩展性 | 分布式 | 支持 | 支持 | 支持 | 支持 |
| TSDB性能 | 数据加载吞吐 | 1240892 | 持平 | 261858 | 1340979 |
| 数据读取吞吐 | 2402 | 低一些，还在分析 | 1063 | 3625 |
| AI能力 | 基本机器学习和大模型能力 | 目前最成熟 | 刚起步 | - | - |
| 工业化协议 | Modbus TCP | 支持 | 支持 | 支持 | 支持 |
| OPC UA | 支持 | 支持 | 不支持（老协议） | 支持 |
| OPC DA | 支持 | 支持 | 支持（通过taosExplorer支持） | 支持 |
| Modbus RTU | 支持 | 支持 | 支持 | 支持 |
| Modbus Ascii | 支持 | 支持 | 支持 | 支持 |
| BACnet/CDT | 不支持 | 不支持 | 不支持 | 不支持 |
| IEC101/IEC104 | 不支持 | 支持（支持PI系统作为数据源，PI系统支持IEC） | 不支持 | 不支持 |
（三）竞品性能测试对比
1. 场景一：模拟Tdengine官网公开测试场景
- 服务器配置：x86架构虚拟机，CPU 4核，内存 4G，硬盘 245M HDD；
- 测试工具：TSBS 50 works；
- 数据模型：devops场景模拟10台设备，产生24小时数据，共7776000条记录数据，实际查询中只有cpu（864000 rows）和tags（10 rows）表参与查询。
| 场景说明 | KES执行结果 | Tdengine执行结果 |
|---|
| 所有数据，8标签，查询1个max(字段) | 3843.84ms | 1010ms |
| 所有数据，8标签，1小时为粒度，查询1个max(字段) | 5252.61ms | 12020ms |
| 12h数据，8标签，10min为粒度，查询1个max(字段) | 3705.47ms | 6720ms |
| 1h数据，8标签，1min为粒度，查询1个max(字段) | 565.60ms | 1980ms |
差距说明：场景1在测试环境下KES版本CPU占有率达到满负荷，Tdengine官网测试报告中提到Influxdb也有同样现象。
2. 场景二：模拟第三方测试榜单benchANT官网公开测试场景
- 服务器配置：x86架构虚拟机，CPU 4核，内存 4G，硬盘 245M HDD；
- 测试工具：TSBS 50 works；
- 数据模型：DevOps标签1000，查询类型：single-groupby-1-1-1；
- 数据规模：3天，插入批次：1000。
| 场景说明 | KES | InfluxDB v1.8.10 | IotDB v1.2.1 | Timescale DB v2.7.0 |
|---|
| WRITE THROUGHPT（秒级） | 1240892 | 261858 | 1340979 | 1243999 |
| READ THROUGHPT（秒级） | 2402 | 1063 | 3625 | 116（数据明显不合理，暂不比较） |
结果分析：该场景下KES与IotDB在读写吞吐量上存在一定性能差距，但表现优于InfluxDB。
3. 场景三：插入性能摸底测试
- 服务器配置：x86架构，CPU 64核，内存 512G，硬盘 245T HDD；
- 测试工具：TSBS；
- 数据模型："cpu-only"，标签数=10，固定设备数目scale=100，间隔为1s，连续3天的数据，合计25920000条；
- 测试目标：探究tsbs_load_timescaledb插入工具workers、chunk-time、batch-size这几个变量对插入性能的影响。
（1）chunk-time对写入性能的影响
| chunk-time | 子分区数 | 写入性能 (metrics/sec) |
|---|
| 0.25 | 288 | 4068699.04 |
| 0.5 | 144 | 6785639.00 |
| 1 | 72 | 11952295.53 |
| 10 | 8 | 11735843.34 |
| 100 | 1 | 11949829.53 |
（2）workers对写入性能的影响
| workers | 写入性能 (metrics/sec) |
|---|
| 1 | 2927236.74 |
| 12 | 12380815.40 |
| 24 | 12483463.38 |
| 240 | 4156468.63 |
（3）batch-size对写入性能的影响
| batch-size | 写入性能 (metrics/sec) |
|---|
| 360 | 8870846.32 |
| 3600 | 11158004.53 |
| 36000 | 12195698.97 |
| 360000 | 6457407.20 |
（4）测试结论
- workers：随着workers参数数目增加，写入速度会加快，但设置过多反而会导致性能下降；
- batch-size：随着batch-size参数数目增加，写入速度会加快，但过度设置也会影响性能；
- chunk-time：随着chunk-time参数数目增加，子分区数量减少，每个子分区容纳的数据更多，写入速度也会加快。
当前配置下，当workers为24、插入批次为36000、不建立任何索引时，写入速度最快，可达到千万级别（12740848.69 metrics/sec，即1274084.87 rows/sec）。
（四）竞品AI能力对比
| 产品 | AI能力 | 技术特点 | 用户接口 |
|---|
| KES_TSDB | pgai，需要使用Openai API KEY、postgresML | 支持训练和推断，需要使用SQL函数自己训练模型 | 支持超过47个分类和回归算法，支持大模型，支持NLP任务，支持向量检索 |
| TDengine | TDgpt，taosd适配的外置式时序数据分析智能体 | 内置Statsmodel、Pycularity等经典统计分析模型库，内嵌了Pytorch/Keras等深度学习框架，还可以通过请求转发直接调用涛思时序大模型TDtsfm | 1. 时序数据异常检测；2. 时序数据分析预测；3. 时序数据补全；4. 时序数据分类（文档说明开发中，2025年12月发布）；5. 用户自定义分析算法 |
| IoTDB | 内置AI能力，使用SQL语句能完成机器学习模型管理与推理完整流程 | - | 1. 时间序列预测；2. 时序异常检测；3. 时间序列标注 |
| influxdb2.x | - | - | - |
（五）竞品分析总结
| vs | 应用场景 | 对方优势 | KES优势 | 评价 |
|---|
| influxdb | 监控测量、轻量级数据量 | 生态成熟，WEB界面工具体现好 | 采集点数量不限制，数据加载吞吐高，支持更新和事务，SQL支持更友好 | 可以替代 |
| tdengine | 物联网、工业互联网、车联网、IT运维，轻量级数据量（蔚来汽车、海尔、地震台等） | 一体化架构（内置缓存、流计算、消息队列），云边计算，安全模型，时序大模型 | SQL支持更优化，窗口函数和分析函数更完整，查询效率更高，支持多模态融合查询 | 基本场景可以满足 |
| IoTDB | 原生物联网场景，工业制造、能源电力、高端装备等 | 工业协议集成好，学术界影响力较好，数据加载和读取吞吐都较好 | SQL支持更好，窗口函数和分析函数更完整，查询效率更高，支持多模态融合查询 | 基本场景可以满足 |
六、时序行业技术发展趋势 🔮
- 存储技术持续升级：面对越来越庞大的数据量，分布式存储、内存数据库会得到更广泛的应用，同时更高效的索引和查询优化算法也会不断涌现；
- 预测分析成核心方向：趋势预测、异常检测、模式识别这些预测分析能力，会成为时序数据库技术的重要发展方向。到2025年，超过60%的企业都会用预测分析来指导业务决策；
- 量子计算与边缘计算发力：量子计算有望在数据加密、优化算法等方面带来突破性进展；而边缘计算能把数据处理放到数据产生的源头，大大减少数据传输延迟。根据麦肯锡研究，到2025年，全球超过50%的数据都会在边缘设备上进行处理。
七、金仓时序数据库未来研发规划 🛣️
（一）产品三年规划总览
| 时间 | 产品能力 | 应用场景 | 目标替代市场 | 竞争力变化 | 宣传点（控标点） |
|---|
| 2026年6月 | 分析能力增强，压缩和IotDB持平 | 高基数型数据管理、物联网、工业控制 | tdengine、influxdb、IotDB | 数据加载和数据读取吞吐高 | 加载和查询效率高，分析查询全面 |
| 2026年12月 | 支持云边协同，补充timescaledb 2.18+的功能 | 混合负载场景 | dolphindb、timescaledb | 优化云上集群版本的性能（包括IO优化） | 成本低廉 |
| 2027年 | 实时计算，时序大模型，异常检测、趋势分析 | 实时分析与流式数据处理 | - | 集成流批方案 | 内核级多模数据融合 |
| 2028年 | 采集点权限控制，产品生态成熟，界面易用 | 几千万以上的监控指标，关注存储成本；工业控制、智慧xx厂等有智慧终端的所有场景 | - | - | 无限监控指标 |
（二）产品能力分阶段规划
| 产品能力 | 2026年6月 | 2026年12月 | 2027年 | 2028年 |
|---|
| 存储 | 支持常用压缩算法snappy压缩 | 支持列存 | - | - |
| 写入 | 支持AIO | - | - | - |
| 查询 | - | 支持趋势分析能力、预计算、向量计算 | 时序分析模型 | 实时计算 |
| 部署架构 | - | - | 支持云边协同（项目驱动） | - |
| 生态 | - | 支持hadoop等平台对接，与分析生态产品集成 | - | 支持流批 |
| 安全 | - | - | 支持采集点安全控制 | - |
| 高可用 | sharding整体的备份恢复 | - | - | - |
| 其他 | 1. 增强界面易用性（vs influxdb）；2. 完成插件重构；3. 第三方测试：TSDB读写负载高 | 1. 通过信通院的时序标准测试；2. 第三方测试：成本最低 | - | - |
