Cassandra 查询性能 : Using IN clause for one portion of the composite partition key

Question

我目前在 Cassandra 中设置了一个表，该表具有文本、小数或日期类型列，并具有 Business_date 和 account_number 的复合分区键。对于对此表的查询，我需要能够支持在给定日期查找单个帐户或帐户列表。

示例:

select x,y,z from my_table where business_date = '2019-04-10' and account_number IN ('AAA', 'BBB', 'CCC')
//Note: Both partition keys are provided for this query

我一直在努力解决与访问此数据相关的性能问题，因为我注意到我无法理解/解释延迟模式。

在许多情况下，客户端应用程序可以在短时间内运行完全相同的查询总共 3 次。对于这些场景，我发现三分之二的请求的响应时间非常糟糕(800 毫秒)，其中一个请求的响应时间非常快(50 毫秒)。起初我认为这是由于键或行缓存造成的，但是，我不太确定，因为我相信如果这是真的，那么三个请求中的第三个请求应该总是最快的，但事实并非如此.

我认为我面临的第二个问题是实际的数据模型本身。尽管提交查询时提供了所有分区键，但由于它是 IN 子句，因此结果将是单独的分区并且可以分布在整个集群中，因此，这将是一种不好的访问模式。但是，即使运行单个帐户查询，我也会看到这些延迟问题。此外，我发现 15 - 20 个帐户的查询性能非常好(低于 50 毫秒)，因此我不确定数据模型是否确实是一个问题。

集群设置:

• 数据中心:2 个
• 每个数据中心的节点数量:3
• 键空间复制:local_dc = 2，remote_dc = 2

Java驱动程序集:

• 负载平衡:DCAware 与 LatencyAware
• 协议(protocol):v3
• 查询仍设置为使用“IN”子句，而不是异步单独查询
• 读取一致性:LOCAL_ONE

有人对我应该关注什么以真正确定此问题的根本原因有任何想法/线索吗？

Answer 1

在分区键上使用 IN 始终是个坏主意，即使对于复合分区键也是如此。分区键的值定义了数据在集群中的位置，不同的分区键值很可能会将数据放到不同的服务器上。在这种情况下，协调节点(接收查询的)将需要联系保存数据的节点，等待这些节点交付结果，然后才将结果发送回给您。

如果您需要查询多个分区键，那么异步发出单个查询并在客户端收集结果会更快。

此外，请注意，当您使用 PreparedStatement 时，TokenAware 策略效果最佳 - 在这种情况下，驱动程序能够提取分区键的值，并查找哪些服务器为其保存数据。