StarRocks 中的数据删除

在 StarRocks 主键表中，标记删除的数据不会立即物理删除，而是通过后台的 Compaction（数据合并） 机制逐步清理。以下是详细说明：

一、删除标记的底层机制

主键表采用 “Delete+Insert” 策略：

1. 逻辑删除：执行 DELETE 或 UPDATE 时，通过主键索引定位旧数据，在 DelVector（删除标记向量） 中标记为删除，而非立即删除数据文件。
2. 物理存储：旧数据仍存在于磁盘的 Segment 文件中，但查询时会通过 DelVector 过滤掉标记的行，确保只返回最新数据。

二、物理删除的触发条件

标记删除的数据需通过 Compaction 合并 才能物理删除，触发场景包括：

1. 自动 Compaction：
   • StarRocks 后台定期合并小 Rowset（数据片段），合并时会扫描 DelVector，跳过或移除已标记删除的行。
   • 合并后生成的新 Rowset 不包含已删除数据，旧 Rowset 在引用计数为 0 时被删除。
2. 手动触发：
   通过 ALTER TABLE ... COMPACT 命令强制合并分区，加速旧数据清理（谨慎使用，可能影响查询性能）。
3. 分区 TTL 策略：
   若表配置了分区 TTL（如 dynamic_partition.time_unit = day 且 dynamic_partition.end 为 -3），过期分区会被移至 Trash（默认保留 1 天），之后物理删除整个分区的数据（包括标记删除的行）。

三、物理删除的时机与影响

• 延迟性：标记删除的数据可能在 数分钟到数天 后物理删除，具体取决于：
  • Compaction 配置（如 update_compaction_num_threads_per_disk 线程数、update_compaction_per_tablet_min_interval_seconds 间隔）。
  • 数据热度：热分区（高频更新）的 Compaction 更频繁，旧数据清理更快。
  • 分区 TTL：若启用分区过期策略，过期分区会被批量删除。
• 性能影响：
  • 未清理的删除标记会增加查询时的过滤开销（需扫描 DelVector），但主键表的查询性能仍优于更新表（无需合并多版本）。
  • 过度延迟的 Compaction 可能导致存储膨胀，需通过监控（如 be_http_port/mem_tracker）调整 Compaction 资源。

四、最佳实践建议

1. 合理配置 Compaction：
   • 实时性要求高的场景：增加 compact_threads（存算分离）或 update_compaction_num_threads_per_disk（存算一体），缩短 update_compaction_per_tablet_min_interval_seconds（如 60 秒）。
   • 资源有限的场景：适当降低频率，避免影响写入性能。
2. 利用分区 TTL：
   对历史数据（如超过 7 天的订单）启用分区 TTL，自动删除过期分区，减少手动维护成本。
3. 避免高频小批次更新：
   批量写入（如批次大小 10 万行以上）可减少 DelVector 条目，降低 Compaction 压力。

总结

主键表中标记删除的数据会在 Compaction 合并 或 分区 TTL 过期 时物理删除，而非立即清除。这一设计在保证实时查询性能的同时，通过异步清理平衡了存储效率。用户可根据业务需求调整 Compaction 策略和 TTL，控制物理删除的时机与资源消耗。