一、90%的企业都踩过的选型误区​

当业务涉及传感器数据、设备日志、交易流水等**时间序列数据（Time-Series Data）**时，许多团队会惯性选择传统的实时数据库（如Oracle TimesTen）。但实测数据显示：在写入吞吐量超过10万数据点/秒的场景中，时序数据库的硬件成本仅为实时数据库的1/5，且查询响应速度提升20倍以上。​

这种性能差异源于两者的底层设计逻辑：​

• 实时数据库：优先保障ACID事务和强一致性，适用于银行转账、证券交易等低延迟、高精确度场景，但面对时间戳数据时，其行式存储结构会导致存储膨胀和查询缓慢。​
• 时序数据库：专为时间维度优化，采用列式存储+时间线分区，例如TDengine对物联网设备数据的压缩率可达95%，且支持毫秒级时间窗口聚合计算，在工业监控、车联网等场景中已成技术标配。​

二、六大核心维度硬核对比（附打分表）​

我们基于20个真实企业案例的测试结果，整理出关键选型评估体系：​

​场景化结论：​

• 选择实时数据库：当业务要求毫秒级事务锁（如股票撮合交易）、需要严格保证数据一致性时​
• 必用时序数据库：当面临高频数据写入（>5万点/秒）、需按时间维度聚合分析（如设备故障预测）、或存储成本超过预算50%时​

三、时序数据库的“降维打击”案例​

​案例：某车联网项目数据库改造​

痛点：存储车联网设备的轨迹点，支持对轨迹进行查询。使用关系型数据库，存储成本高，不适合轨迹存储这种低价值的数据，而且不能解决行业客户轨迹数据存储周期定制化的需要​

用时序库方案：目前我们共有 102 万张子表，已经累积的总数据量已经达到了 2000 亿行，3 副本，磁盘占用 3.1TB。在迁移到 TDengine 3.0 之后，各方面的表现依然非常不错：业务的写入峰值达到了 1.2-1.3w 行/s ，数据迁移的过程中可以达到 20w 行/s，这些情况下 TDengine 都可以轻松处理；存储大约只有 MySQL 的 1/7；读取数据性能也很突出，我们最常用的单设备单日查询，可以在 0.1s 内返回结果。

*文章部分内容来源于网络