如何构建满足FIFO插入顺序的Cassandra表并规避墓碑问题？

一、需求完全可实现 #

Cassandra的设计可以满足带前缀维度（按site-id分区）、FIFO顺序维护、异地冗余存储的需求，同时通过合理的表结构和策略规避墓碑问题。

二、表结构设计（满足FIFO与前缀维度） #

针对你的需求，推荐两种表结构方案，可根据业务对"FIFO"的定义选择：

方案1：按事件插入顺序保证FIFO #

适合需要严格按数据写入顺序返回的场景：

CREATE TABLE event_data (
    site_id TEXT,
    event_type TEXT,
    event_time TIMEUUID,
    event_timestamp TIMESTAMP,
    content TEXT,
    PRIMARY KEY ((site_id), event_time)
) WITH CLUSTERING ORDER BY (event_time ASC)
  AND compaction = {'class': 'TimeWindowCompactionStrategy', 'compaction_window_size': 1, 'compaction_window_unit': 'HOURS'}
  AND replication = {'class': 'NetworkTopologyStrategy', 'DC1': 2, 'DC2': 2}; -- 异地数据中心配置示例

• 分区键：site_id作为前缀维度，每个站点的事件独立存储在一个分区内，10万条记录的分区大小完全在Cassandra的性能承受范围内（单分区建议不超过100MB，常规文本内容的10万条数据远低于此阈值）。
• 聚类键：event_time使用TIMEUUID类型，客户端写入时生成（如Java的UUIDs.timeBased()），既包含时间戳保证顺序，又能避免同一毫秒内的写入冲突，严格保证FIFO顺序。
• 异地冗余：通过NetworkTopologyStrategy配置不同数据中心的副本数，实现异地多活冗余。

方案2：按事件发生时间保证FIFO #

适合需要按事件实际发生顺序返回的场景（即使写入顺序与事件时间不一致）：

CREATE TABLE event_data (
    site_id TEXT,
    event_type TEXT,
    event_timestamp TIMESTAMP,
    event_uuid TIMEUUID,
    content TEXT,
    PRIMARY KEY ((site_id), event_timestamp, event_uuid)
) WITH CLUSTERING ORDER BY (event_timestamp ASC, event_uuid ASC)
  AND compaction = {'class': 'TimeWindowCompactionStrategy', 'compaction_window_size': 1, 'compaction_window_unit': 'HOURS'}
  AND replication = {'class': 'NetworkTopologyStrategy', 'DC1': 2, 'DC2': 2};

• 聚类键：先按event_timestamp排序，同一时间戳的事件用event_uuid保证唯一性和顺序，确保事件按实际发生时间FIFO排列。

三、避免墓碑问题的核心方案 #

墓碑是Cassandra中删除/更新操作遗留的标记，会影响查询性能，以下是针对性解决策略：

1. 避免显式删除，改用分区滚动策略 #

如果需要严格保留每个site_id下最多10万条记录，不要直接删除单条旧数据，而是采用分区滚动：

• 扩展分区键为(site_id, batch_id)，每个batch_id对应一批最多10万条记录；
• 当当前批次的记录数达到10万时，切换到下一个batch_id（如自增整数）；
• 需要清理旧数据时，直接删除整个旧批次的分区（DELETE FROM event_data WHERE site_id = ? AND batch_id = ?），Cassandra删除整个分区不会产生墓碑，压缩时直接移除整个分区的数据。

2. 利用TTL自动过期（适合有时间有效期的场景） #

如果业务允许事件数据在一段时间后自动过期，给表设置TTL：

ALTER TABLE event_data WITH default_time_to_live = 864000; -- 10天过期，可按需调整

结合TimeWindowCompactionStrategy（TWCS），Cassandra会在压缩时自动清理过期的时间窗口数据，不会产生墓碑，同时减少存储压力。

3. 禁止更新操作，只做插入 #

事件数据通常是不可变的，业务上严格只做插入操作，不更新已写入的记录，从根源避免更新产生的墓碑。

4. 优化压缩策略 #

使用TimeWindowCompactionStrategy（TWCS）代替默认的SizeTieredCompactionStrategy（STCS），TWCS针对时间序列数据优化，按时间窗口合并SSTable，自动清理过期数据，减少墓碑的累积和影响。

四、异地冗余注意事项 #

• 配置NetworkTopologyStrategy时，根据异地数据中心的网络延迟调整副本数，建议每个数据中心设置2-3个副本，保证可用性；
• 写入时使用LOCAL_QUORUM一致性级别，确保本地数据中心写入成功，异地数据中心异步同步，兼顾性能和冗余；
• 避免跨数据中心的强一致性写入，减少延迟影响。

内容的提问来源于stack exchange，提问作者giuseppe percuoco