Cassandra - 避免墓碑的动态模式设计

Question

我正在编写一个需要跟踪“对象”的应用程序。具体来说，当一个“对象”（一个 1k 的 blob）到达应用程序级别时，它会保存在 C* 中以备将来使用。说到数字，我预计会获得 10-500 亿个不同对象，因此预期数据大小在 10-50TB 之间。

应用程序可以在可变时间窗口（例如一天或一个月）内多次看到完全相同的对象。应用程序在某些条件适用时“使用”这些对象（它们不会立即使用），因此应用程序级别的计数器与每个对象相关联。我不能容忍计数不足/过度计数，所以 C* 计数器是一个很大的问题，我依赖于应用程序级别的适当“锁定”。我基本上确保正确计算每个对象，达到“正确”数量的“全局锁”和惩罚，但我对此很好。当应用程序完成处理一个对象时，关联的计数器会达到零，我确信这个对象将永远不会再被使用，因此可以安全地删除它（从应用程序的角度来看）。

但是，问题是我绝对不能保证：

1. 如果对象 X 在一个月内出现 5 次，则所有这 5 个对象将连续处理。

2. 如果对象 X 在一个月内被看到 5 次，则此对象将被连续处理 5 次。

真的，这两个语句是一样的：我不能将处理减少到一个队列，一个经典的 Cassandra 反模式，因为计数器不会转到立即归零。

确实，这 5 个对象将（更实际地）一次处理一个，中间有一些未确定的延迟。因此，如果对象 X 有 5 个“计数”，当处理一个对象 X 时，我必须更新计数器并将其设置为 4，然后“等待”直到处理完所有剩余的 4 个对象 X，一次一个。

这是迄今为止我见过的最糟糕的“混合”模型，从某种意义上说，它需要两个世界中最糟糕的一个：频繁更新的列模型和队列 反模式模型。

我想删除所有这些对象以回收存储空间，并且我正在尝试找到一个不会受到应用程序写入模式太多影响的模型。

---

从我目前看到的情况来看，如果我能找到一种方法来收集表中可能最终被删除的对象，我将只执行频繁更新，因为删除会完全删除表并避免所有删除和墓碑混乱（假设删除表时没有拍摄快照）。然后，我将创建一个新表来处理下一组数据（类似于一个常量表名，后跟一个递增的单调数字，以避免随着时间的推移重复使用相同的表名，例如TBLNAME0、TBLNAME1 等。） .

这显然会给应用程序带来一些好处，但它会在架构中引入一些潜在的不一致。考虑一个分布式的东西，如果一个或多个节点出现故障，我会得到很多混乱的数据，显然这是我想避免的事情。

另一方面，如果我不删除整个表并坚持删除，则墓碑可能会给应用程序带来巨大的读取损失。

谈到删除/删除频率，我希望平均每天或两次删除一个表，并且我希望每天有超过 1000 万次删除。

---

Q1：放弃还是不放弃？（我投票赞成放弃）。

Q2：Cassandra 真的适合这个吗？还有什么可以使用的建议吗？

Answer 1

...我预计会获得 10-500 亿个不同的对象，因此预期数据大小 介于 10-50TB...

有了这个大数据集，您如何能够在任何合适的时间范围内将数据重新洗牌到新表？

我建议您删除对象。如果这些墓碑不是排成一排，那么读取活细胞的惩罚就不会那么多。所以用合理的分区键创建表肯定是加分项。

根据我的经验，对于频繁更新列，增加 commitlog_total_space_in_mb 和 memtable_total_space_in_mb 有助于避免频繁的 memtable 到 sstable 刷新。这会降低压缩和 gc 压力。

如果您提供有关建议架构的更多详细信息以及您希望执行的最常见 CQL 语句的示例，人们可能会更好地了解您打算做什么。