GridDB中Collection与TimeSeries容器的差异及适用场景

1. 主要差异 #

• 数据模型与排序逻辑：
  • Collection是无固定顺序的关系型容器，类似传统数据库表，记录靠主键唯一标识，存储顺序无强制规则。
  • TimeSeries是时间优先的有序容器，必须指定TIMESTAMP/DATE类型的主键字段，记录会自动按时间戳升序存储，支持同一时间点存储多版本数据。
• 主键规则：
  • Collection支持任意类型（除数组）的单字段或复合主键，无强制时间字段要求。
  • TimeSeries的主键必须包含时间字段，可搭配其他字段组成复合主键（如设备ID+时间戳，实现多设备时序数据隔离）。
• 生命周期管理：
  • TimeSeries原生支持自动TTL（数据过期），可按时间范围配置自动清理旧数据，无需手动维护。
  • Collection无原生TTL机制，需通过SQL或自定义脚本手动清理数据。

2. 性能考量因素 #

• 写入性能：
  • TimeSeries针对时序写入做了顺序存储优化，批量写入同时间维度数据时，吞吐量远高于Collection，适合高频率连续写入场景（如IoT传感器每秒上报数据）。
  • Collection为随机写入模式，高并发写入时性能稳定性不如TimeSeries。
• 读取性能：
  • 按时间范围查询时，TimeSeries依托有序存储的时间索引，能快速定位数据区间，延迟极低。
  • Collection若要做时间范围查询，需单独为时间字段建索引，否则会触发全表扫描，性能远逊于TimeSeries；但针对非时间维度的精准查询（如按用户ID查详情），两者性能相近。
• 存储效率：
  • TimeSeries采用列式存储优化，相同时间维度的字段会批量压缩，存储空间利用率更高，尤其适合数值型时序数据。
  • Collection为行式存储，适合字段类型多样、多字段联合查询的场景，但存储压缩率低于TimeSeries。

3. 查询行为区别 #

• 默认排序：
  • Collection查询结果无固定顺序，必须手动指定ORDER BY子句才能排序。
  • TimeSeries查询结果默认按时间戳升序返回，无需额外排序语句。
• 专属查询能力：
  • TimeSeries支持时序专属函数，如ROLLUP（时间窗口聚合）、LAG/LEAD（前后值对比）、INTERPOLATE（缺失数据插值），这些逻辑在Collection中需手动实现。
  • Collection支持完整标准SQL语法，包括JOIN、子查询等，复杂关联查询的灵活性更强。
• 数据版本处理：
  • TimeSeries允许同一时间点存储多条记录（多版本），可通过版本号或时间范围获取历史数据，适合保留数据修改轨迹的场景。
  • Collection主键唯一，同一主键的记录更新会直接覆盖旧数据，无版本保留能力。

4. 推荐适用场景 #

优先选择Collection的场景： #

• 用户/客户记录：无强时间关联性，查询多围绕用户ID、姓名等非时间维度展开，需支持复杂关联查询（如关联订单、地址表），且无需自动过期机制。
• 业务主数据：如商品信息、权限配置、组织结构等，数据更新频率低，查询以精准匹配或多条件筛选为主，关系型模型更贴合需求。
• 非时序事件记录：如用户操作日志，若仅需偶尔按用户或操作类型查询，无需高频时间窗口统计，Collection足够满足需求。

优先选择TimeSeries的场景： #

• IoT传感器数据：高频率连续时序数据，需按时间范围快速查询、聚合（如统计设备日平均温度），且需要自动清理过期数据。
• 日志/事件存储：系统日志、服务器监控数据等，核心查询场景为时间范围检索、时间窗口统计分析，TimeSeries的存储与查询优化能大幅提升效率。
• 金融时序数据：股票价格、交易记录等，需按时间排序、做时序分析（如移动平均、波动率计算），专属函数可简化开发。

内容的提问来源于stack exchange，提问作者Tarpinder Singh