Cassandra Where子句中的IN查询

Question

我有一个Scylla群集，其中包含3个节点和1个表，并通过以下查询创建

CREATE TABLE id_features (
    id int PRIMARY KEY,
    id_feature_1 int,
    id_feature_2 int,

)

我正在从应用程序中发出以下查询SELECT * FROM product_vectors where id in (1,2,3,4...120);该查询最多可以包含120个ID。

此查询是否会根据id的令牌值联系所有3个节点，以在最坏的情况下获取120个id的数据？否则将仅联系1个节点以获取所有id的数据，并且多个节点仅用于高可用性

复制因子，一致性级别和负载平衡策略将在决定节点时发挥任何作用吗？

Answer 1

此查询将基于id s的令牌值联系所有3个节点以获取数据

复制因子，一致性级别和负载平衡策略将在决定节点时发挥任何作用吗？

这在很大程度上取决于复制因子（RF），查询一致性和负载平衡策略。具体来说，如果RF id的哈希标记值和主要分配给这些标记范围的节点，联系多个节点。

但是，鉴于此声明：

或者将仅联系一个节点来获取所有标识的数据，并且多个节点仅用于高可用性

...在这种情况下，我感觉到RF = 3。

如果应用程序配置为使用（默认）TokenAwarePolicy，则可以，仅对于单键查询，可以将请求发送到各个节点。

但是在这种情况下，查询使用的是IN运算符。基于120个潜在条目，查询

cannot确定要发送查询的单个节点。在这种情况下，TokenAwarePolicy只是充当其子策略（DCAwareRoundRobinPolicy）的传递对象，它将选择LOCAL距离的节点作为“协调者”。然后，协调器节点将承担路由副本请求和编译结果集的其他任务。

关于在查询计划中是否使用非主要副本，答案还是“取决于”。尽管负载均衡策略在实现上有所不同，但通常所有负载均衡策略都计算query plans，其中：

每个查询都各不相同，以便平衡整个集群的负载；

仅包含已知能够处理查询的主机，即既不忽略也不关闭；
• 偏爱本地主机而不是远程主机。
• 来自：https://docs.datastax.com/en/developer/java-driver/3.6/manual/load_balancing/#query-plan

因此，在RF =节点数的情况下，单个节点有时

可用于返回所有请求的副本。

专业提示

：

[尽量不要将IN运算符与120个分区键条目一起使用。这迫使Cassandra执行random

读取，而在[[sequential reads上确实表现出色。如果这是应用程序真正需要执行的查询，请尝试：

建立新表以更好地支持该查询模式。

不超过IN条目的两位数。