问题标签 [tombstone]

我知道早期删除墓碑是危险的，因为它可能导致已删除的数据复活，但如果所有副本都已确认删除，那么这种删除应该是安全的。例如，如果一个表的复制因子为 3，并且包含该键的所有 3 个节点都已确认它们具有适当的 tombstone，则执行删除 tombstone 的压缩应该是安全的，因为不会有数据的延迟副本.

在 Cassandra 可以安全地移除墓碑吗？

我宁愿设置gc_grace_seconds为无穷大并依赖这种类型的墓碑安全压缩，而不是担心nodetool repair和的时间gc_grace_seconds。

我最近降低gc_grace_seconds了 CQL 表。我正在跑步LeveledCompactionStrategy。我可以从我的 SSTables 中强制清除旧墓碑吗？

过度简化数据模型，我们有以下表格：

第一个表可以包含数亿条记录，我们使用索引表可以根据一些可查询的参数轻松定位数据。

当我们必须基于foo、bar或baz清除数据时，问题就来了。我们必须从存储表和所有索引表中删除条目。因此，假设我们通过例如foo删除，采取的步骤是：

1. 根据适当的索引表查找 id（在本例中为storage_idx_by_foo）
2. 获取bar和baz并从存储表中删除记录
3. 从剩余的两个索引表中删除记录（我们有bar / baz和id）

第 3 步是因为tombstones的问题- 如果我们从剩余的两个索引表中删除数百万条记录（意味着不是通过分区），Cassandra 将创建数百万条 tombstones，这在压缩发生之前读取数据时会引起很多麻烦。

一些快速的头脑风暴表明我们可以：

1. 清除过程后强制压实
2. 不从这两个表中删除并处理指向代码中不存在的东西的索引条目
3. ？？？

建议的方法是什么？我猜其他 Cassandra 用户也遇到过这个问题，但除了“你做错了 Cassandra”之外，我在网上找不到任何建议。我不认为我们可以对我们的数据进行不同的建模来避免这个问题（或者如果可以的话，我也会很感激对此的反馈）。

目前，我们倾向于选项 2，尽管我不喜欢将垃圾留在数据库中的想法。

所以我在从表中查询数据时遇到了这个异常。我在网上阅读了很多，据我了解，发生这种情况是因为我有很多空行。但是有什么办法可以解决这个问题？我可以轻松摆脱所有这些空值吗？

更新：我跑了nodetool compact，也试过擦洗。在这两种情况下，我都明白了。

这些是最后几行 system.log

我不确定最后一行是什么意思。似乎没有非常大的行（我不知道如何找到是否有）。需要注意的是，压实度仍然停留在 60.33% 并且停留在okcoin_order_book_btc_usd. 我正在运行 Cassandra 2.0.11

Cassandra（版本 2）支持哪些类型的墓碑？根据这篇文章，它支持（用 CQL 术语）：

• 一行的特定列。
• 静态列。
• 分区键的所有行。

我错过了其他类型的墓碑吗？删除特定（CQL）行？是否有任何特殊的墓碑来支持删除集群键或类似的范围？在规划模式以避免过多的墓碑时，了解此信息很有用。

我们正在运行由 Cassandra 支持的 Titan Graph DB 服务器作为持久存储，并且遇到了达到 Cassandra 墓碑阈值限制的问题，这导致我们的查询随着数据的累积而定期失败/超时。似乎压缩无法跟上添加的墓碑数量。

我们的用例支持：

1. 高读/写吞吐量。
2. 读取灵敏度高。
3. Titan中节点值的频繁更新。导致在 Cassandra 中更新行。

鉴于上述用例，我们已经在优化 Cassandra 以积极地执行以下操作：

1. 通过使用水平压实策略进行积极压实
2. 使用 tombstone_compaction_interval 作为 60 秒。
3. 使用 tombstone_threshold 为 0.01
4. 将 gc_grace_seconds 设置为 1800

尽管进行了以下优化，我们仍然在 Cassandra 日志中看到类似于以下内容的警告： [WARN] (ReadStage:7510) org.apache.cassandra.db.filter.SliceQueryFilter: Read 0 live and 10350 tombstoned cells in .graphindex（参见 tombstone_warn_threshold ）。请求了 8001 列，slices=[00-ff]，delInfo={deletedAt=-9223372036854775808，localDeletion=2147483647}

有时，随着时间的推移，我们还会看到故障阈值被突破并导致错误。

我们的 cassandra.yaml 文件的 tombstone_warn_threshold 为 10000，并且 tombstone_failure_threshold 远高于建议的 250000，但没有真正明显的好处。

如果有进一步优化的空间，任何可以为我们指出正确配置的帮助将不胜感激。提前感谢您的时间和帮助。

我正在为 Cassandra 2.1.3 上的时间序列应用程序创建数据模型。我们将为系统的每个用户保留 X 量的数据，我想知道针对此要求进行设计的最佳方法是什么。

选项1：

在分区键中使用“桶”，因此 X 周期的数据进入同一行。像这样的东西：

我可以一次删除一行，但要以维护这个存储桶概念为代价。它还限制了我可以查询的范围timestamp，可能会导致多个查询。

选项2：

将所有数据存储在同一行中。N 删除是每列。

范围查询再次变得容易。但是删除许多列后性能如何？

鉴于我们计划使用 TTL 让数据过期，这两种模型中哪一种会提供最佳性能？Option1 << Option2 的墓碑开销还是两种模型上的每列都有一个墓碑？

我尽量避免把自己埋在墓碑墓地里。

当我从 cassandra 中删除一行并且数据仍然存在于 memtable 中（尚未创建 SSTable）时，看起来已删除的行永远不会在 memtable 中被清理，因为墓碑清理仅通过压缩完成，而压缩仅适用于SSTables。无论如何，在将其刷新到 SSTable 之前，我是否可以完全清除 memtable 本身中已删除的行？更新已经到位，但似乎没有删除。

我们正在使用 Cassandra 2.0.8。

谢谢

由于数据量和速度的原因，在我们的案例中，将数据写入 Cassandra 而不导致其创建墓碑至关重要。目前我们只写了一次行，然后再也不需要更新行，只需要再次获取数据。

现在出现了一种情况，我们实际上需要写入数据，然后用更多的数据完成它，过一段时间就完成了。它可以由任何一种制造；

1. 使用 INSERT 再次覆盖一行中的所有数据（所有数据都可用），或者

2. 仅对新数据执行更新。

最好的方法是什么，记住速度而不是创建墓碑很重要？

扫描 100k 墓碑后，cassandra 将出错查询，我尝试对表进行主要压缩，但它不会删除其二级索引的墓碑。查询仍然无法完成。

我搜索了一段时间，一个建议是rebuild_index，但我认为重建时会导致许多查询失败，并且我没有估计重建索引需要多长时间。

有什么建议吗？