我知道这不是使用Cassandra的最佳方式，但我的数据类型需要读取上周的所有数据。但是，当在CQL3中使用Collection-types时，我遇到了某些限制，导致我无法进行正常的日期范围查询。
所以我使用下表设置了Cassandra（目前单节点，将来可能更多）
CREATE TABLE cache (tag text, id int, tags map<text,text>,
PRIMARY KEY (tag, id) );
ALTER TABLE cache WITH GC_GRACE_SECONDS = 0;
我使用一周的TTL插入以自动从缓存中删除项目。
我尝试遵循this article中提到的建议，以避免通过选择＆＃34;最小ID＆＃34;来阅读许多墓碑，我坚持在其他地方避免阅读旧数据：
SELECT * FROM cache WHERE tag = ? AND id >= ?
id基本上是某种不断增加的时间戳，即我只会随着时间的推移插入更高的值并不断从表中删除旧的ID。
但我仍然会收到有关达到阈值的警告
WARN 08:59:06,286 Read 5001 live and 5702 tombstoned cells in cache (see tombstone_warn_threshold)
如果我不定期运行手动压缩/清理，我会遇到异常并且查询失败。
然而，基于我对文章和文档的理解，我应该避免大多数（如果不是全部）墓碑，因为我查询标签的相等性，这允许Cassandra只查找那些区域并且我使用允许的最小id Cassandra只能在大部分墓碑之后开始阅读，那么为什么还会报告墓碑警告/例外？
答案 0 :(得分：2)
映射k / v对实际上是一个列（名称，值和时间戳）：所以，如果你发布了很多地图元素的删除（也是TTL到期） - 这就是这个的来源警告。因为你还在阅读完整的地图（里面有很多墓碑）。此外，地图上的TTL设置是基于每个元素应用的。
其次，在您的选择查询中乘以＆gt; =谓词。
如果是这种情况，您应该重新构建数据访问模式，以便在SELECT查询中仅使用EQ关系并更频繁地使用id。此外，此访问模式将允许您摆脱PRIMARY KEY的群集部分。
因此，如果您没有在该地图上发布大量删除，您可以尝试使用tag text, time timeuuid, name text, data text模型并按时间精确切片。