5个cassandra节点中的一个降低了整个集群的性能

我们使用Cassandra2.0.10，并有一个5节点集群。有时，我们会在一个特定节点上的Cassandra日志中收到大量

SliceQueryFilter.java（第225行）读取2个活动单元格和1056个逻辑删除单元格…

消息，而该节点会降低整个数据库性能。我们必须在该节点上重新启动cassandra服务以解决性能问题

有没有人知道这其中的根本原因是什么，以及如何解决

阅读2个实时和1056个墓碑单元

听起来你正在处理一个糟糕的数据模型。当您的模型支持大量删除操作时，就会发生这种情况。对于上面提到的消息，该查询必须对1056个逻辑删除进行排序，才能返回应用程序实际关心的2个值。卡桑德拉不擅长删除。因此，如果您计划支持删除，那么您的模型需要设计为减少墓碑放置

解决方法是让您的应用程序团队以支持不可变写入的方式为这些查询的表建模。这通常意味着将表作为时间序列重新处理。当然，没有看到令人不快的模型，我只能猜测

在一个特定节点上

这是否总是发生在同一个节点上？如果是这样的话，那么听起来您可能陷入了另一个数据建模陷阱，在这个陷阱中，太多的数据被写入单个分区，从而在集群中创建了一个“热点”

如果它不总是同一个节点，那么听起来像是一个节点被用作协调器来执行太多的请求。确保您的应用程序团队在其驱动程序代码中使用了

TokenawarReloadBalancingPolicy

，并且没有错误地使用批处理语句

您如何知道批次是否使用不当

---

若使用批处理跨单个分区提供原子更新，那个么它的使用是正确的。如果在一次网络旅行中应用一系列更新时，使用批处理来提高性能，则该批处理的使用不正确。如果您使用的是Spring Data Cassandra，则在持久化对象列表时，它实际上会在幕后执行此操作。

如果不查看您的数据模型，很难说，但我已经根据我以前看到的问题提供了一些想法。我只会使用批处理来保持两个或多个表的同步，即使跨越多个分区，并因此得到正确的惩罚（没有原子性）。然后，我将在应用程序级别处理这个问题。我不认为这是一个糟糕的批处理用法，是吗？@xmas79你是对的，保持少量表与批处理同步是可以的，即使分区键不精确。我只是想提供一个通用的指南，作为“坏”批处理使用的示例。在您的情况下，协调器节点只需要进行2次（或更多…只要“more”是个位数）网络旅行，所以这不是什么大问题。