根据 Cassandra 官方博客，ALLOW FILTERING 的效率非常低。但是如果由于某种原因必须使用这样的查询，会对其他使用 Cassandra 获取数据的应用程序产生什么影响？是只有忙于为我的查询获取行的线程会变慢，还是整个 Cassandra 都会变慢，因此，所有其他从 Cassandra 获取数据的应用程序的响应都会变慢？
最佳答案
它可能会影响整个节点。围绕它的一个问题是，您的一个限制为 10 的查询不仅会读取 10 条记录并返回，而且(可能)会返回大量数据。可以进行高效的 ALLOW FILTERING 查询，像 spark 驱动程序(每个 token 范围或分区内的 token 限制查询)可以做的事情。我强烈建议不要尝试。一开始它可能会奏效，但你糟糕的运营团队会诅咒你的名字。
使用更快的磁盘，obj 分配，因为这是不受限制的，将导致 严重 GC 开销。这与使用队列或大量墓碑时看到的问题非常相似，JVM 构建和丢弃行超出了垃圾收集器可以跟上的分配速率而无需更长的暂停(早期提升、cms 中的碎片、分配尖峰困惑提高 g1 年轻一代比率)。
如果跨分区，就像正常范围查询一样，协调器将尝试估计它需要读取的范围和副本，以便它们以一些有限的并发散开。这是一个粗略的估计，因为它只有自己的数据可以推断，但是当数据被进一步过滤而不仅仅是“范围内的分区数”时，它可能会出错并被低估。它很可能一次查询一个范围，如果不满足则查询下一个副本集范围。对于 vnode，这可能是一个非常长的列表，并且按顺序遍历它们可能不会在超时内完成。幸运的是，这主要只会影响一个查询，但它本质上仍然是从 1 查询的集群中的每个副本集中从磁盘读取整个数据集。如果您达到 100/秒，集群可能会被清理。
关于cassandra - 允许过滤对 Cassandra 有什么影响？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49613382/