跳到主要内容

时序数据库概述

数据湖的存储层是 针对工业时序工作负载优化的 Aster TSDB(apache-cassandra-timeseries) 。它是 Apache Cassandra cassandra-6.0 的内部派生版本，CQL 语法和磁盘格式与 上游保持一致——可以直接读取现有的 6.0 数据，所有新功能都需要启用才能生效。

「时序引擎（TSE）」和「其他东西」是不同的

由于名称相似，这是最容易混淆的地方。存储的内容不同。

时序数据库 (本文档)时序引擎 (TSE)
存储内容传感器值 — 从现场采集的标签点(pp.tm_tag_point)指标 — PLANTPULSE.JMX.* · PLANTPULSE.EDGE.* 这种 系统自身的指标
特性通用时序数据库仅限指标
端口9042 (CQL)7800(明文) · 7801(TLS)
查询CQL — time_bucket_gapfill 这种内置函数TQL
文档本小节时序引擎

「设备温度怎么样」查询这里，「昨天采集器处理了多少条」查询引擎。

引擎最终也写入同一个 Aster TSDB 集群，但 键空间和模式不同，因此存入 引擎的指标，即使通过 CQL 搜索标签表也不会出现。

有什么改进​

现场时序数据有其固有的特性。每个标签以秒为单位不断累积，由于法规要求需要保留数年， 通信中断的边缘设备会一次性推送多天的数据（延迟加载），而查询几乎总是 「这个标签，这段时间」。使用原生 Cassandra 也可以实现，但 压缩、保留、聚合全部需要由应用程序 处理。此派生版本将这些工作转移到数据库内部。

想要完成的任务此数据库所做的文档
在服务器端完成分桶、聚合、插值21个CQL函数 + 间隙填充时序函数
自动压缩旧数据分层存储 — 查询方式不变分层存储
保留期过后自动删除时序压缩 (TSCS)时序压缩
对日志、事件正文进行子字符串搜索全文检索 — 包含韩文全文检索

同时启用三项​

쓰기 ──▶ [ 핫 구간 ]           최근 데이터. 평소대로 행으로 저장·질의
              │
              │  hot_window 를 지나면 (계층형 저장)
              ▼
         [ 콜드 청크 ]          컬럼 지향으로 압축. SELECT 가 알아서 합쳐 읽는다
              │
              │  cold_window / retention 이 지나면
              ▼
           통째로 삭제          컴팩션 없이 창 단위로 (TSCS)

TSCS 和分层存储相互独立。可以单独启用，但风险较低的是先启用 TSCS。

实测数据 — 运营表结构，2000万行​

tm_tag_point（普通列8个），234号主机，基于chunk格式 v4。

项目分层前分层后效果
存储容量237.8 MB33.3 MB缩小7.1倍 (每行11.9 → 约1.7字节)
count(*) (4万行分区)303 ms50 ms快6.1倍
time_bucket + 聚合150~270 ms31~64 ms快3~6倍
间隙填充(locf · interpolate)162~284 ms30~53 ms快5.4倍
90个标签每小时平均值(360万行)14.9 s4.2 s快3.5倍
压缩也加快查询速度

通常压缩是牺牲速度来换取容量，但在这里 所有测试查询都变快或持平 —— 因为读取的字节数减少了。无范围扫描也是按查询顺序逐个解压窗口，直到 LIMIT 填满就停止，所以不会变慢。

两点注意事项
  • 没有分区键的全表扫描聚合 在分层表上会返回 错误的值。该路径 不会合并chunk。
  • 容量节省 取决于表结构。没有常量列和全null列的最小结构 （高熵 double 只有一个）不适用以上数值。请根据自身表重新测量 后再做决定。

在哪里​

通过 $PP_HOME/plantpulse-storage/db/cassandra 下的 apache-cassandra-timeseries-<version>.jar 进入。可以通过以下方式检查运行进程的版本。

docker exec plantpulse-datalake nodetool version

版本、来源、更新流程属于运维文档，本手册不包含。

更多信息​

想要执行的任务文档
使用分桶、间隙填充、插值时序函数
将旧值移至更便宜的存储分层存储
理解压缩时序压缩 (TSCS)
搜索正文全文检索
直接使用 CQL 查询数据查询

如果您正在寻找指标（系统指标），这里不是正确的地方 → 时序引擎