我们使用Cassandra 2.0.10，并拥有一个5节点集群。有时，我们在Cassandra中获取大量SliceQueryFilter.java (line 225) Read 2 live and 1056 tombstoned cells ...个消息，登录一个特定节点，该节点降低了整个数据库的性能。我们必须在该节点上重新启动cassandra服务以解决性能问题。
有谁知道这可能是什么原因，以及如何解决？
答案 0 :(得分：3)
阅读2个实时和1056个墓碑单元
听起来你正在处理一个糟糕的数据模型。当您拥有支持大量DELETE操作的模型时会发生这种情况。对于上面提到的消息，该查询必须对1056个逻辑删除进行排序，只返回应用程序实际关注的2个值。 Cassandra与DELETE的关系并不好。因此，如果您计划支持DELETE，那么您的模型需要设计为减少墓碑放置。
解决这个问题的方法是让应用程序团队以支持不可变写入的方式为这些查询建模表。这通常意味着将表重新处理为时间序列。当然，在没有看到违规模型的情况下，我只能推测。
在一个特定节点上
这是否总是发生在同一个节点上？如果是这样，那么听起来您可能会陷入另一个数据建模陷阱，其中太多数据被写入单个分区，从而在您的集群中创建“热点”。
如果它不总是在同一个节点上，那么它听起来像一个节点被用作协调器来执行太多请求。确保您的应用程序团队在其驱动程序代码中使用TokenAwareLoadBalancingPolicy，并且他们没有错误地使用BATCH语句。
您如何知道BATCH的使用是否错误？
如果BATCH用于跨单个分区提供原子更新，那么它正在被正确使用。如果在单次网络旅行中应用一系列更新时使用BATCH来提高性能，那么它将被错误地使用。如果您使用的是Spring Data Cassandra，那么当持久化对象列表时，它实际上会在幕后执行 。