我用下面的查询创建了一个有3个节点和1个表的scylla集群
CREATE TABLE id_features (
id int PRIMARY KEY,
id_feature_1 int,
id_feature_2 int,
)我对申请表提出以下质疑 SELECT * FROM id_features where id in (1,2,3,4...120); 查询最多可以有120个ID。
在最坏的情况下，这个查询是否会根据id的token值联系所有3个节点以获取120个id的数据？或者只联系1个节点获取所有ID的数据，多个节点仅用于高可用性
复制因子、一致性级别和负载平衡策略是否在决定节点时起到任何作用？
1条答案
按热度按时间hxzsmxv21#
此查询是否会基于的令牌值联系所有3个节点
ids获取数据复制因子、一致性级别和负载平衡策略是否在决定节点时起到任何作用？
这在很大程度上取决于复制因子（rf）、查询一致性和负载平衡策略。具体地说，如果rf<节点数，那么将基于的哈希令牌值联系多个节点
id以及主要分配给这些令牌范围的节点。但是，鉴于这种说法：
或者只联系1个节点获取所有ID的数据，多个节点仅用于高可用性
…我觉得在这种情况下rf=3。
如果应用程序配置为使用（默认）
TokenAwarePolicy然后是的，仅对于单键查询，可以将请求发送到各个节点。但在本例中，查询使用
IN接线员。根据120个潜在条目，查询无法确定要发送查询的单个节点。在这种情况下TokenAwarePolicy只是充当其儿童政策的传递者(DCAwareRoundRobinPolicy)，它将在LOCAL然后，协调节点将承担路由副本请求和编译结果集的额外任务。至于查询计划中是否使用了非主副本，答案同样是“视情况而定”。虽然负载平衡策略在实现上有所不同，但通常所有策略都计算查询计划，其中：
对于每个查询都是不同的，以平衡集群中的负载；
只包含已知能够处理查询的主机，即既不被忽略也不停机；
偏爱本地主机而不是远程主机。
摘自：https://docs.datastax.com/en/developer/java-driver/3.6/manual/load_balancing/#query-计划
因此，在rf=节点数的场景中，有时可以使用单个节点返回所有请求的副本。
专业提示：
尽量不要使用
IN具有120个分区键条目列表的运算符。这就迫使cassandra执行随机读取，它在顺序读取方面真的很出色。如果这是应用程序确实需要执行的查询，请尝试：构建新表以更好地支持该查询模式。
不超过两位数的条目
IN.