Cassandra READ Where In 性能

Question

我有一个包含 6 个节点的 Cassandra 集群，每个节点有 96 个 CPU/800 个 RAM。

我的性能测试表是:

create table if not exists space.table
(
    id          bigint primary key,
    data        frozen<list<float>>,
    updated_at  timestamp
);

表包含 150.000.000 行。

当我用查询测试它时:

SELECT * FROM space.table WHERE id = X

我什至无法使集群过载，客户端本身已过载，到集群的 RPS 为 350.000。

现在我正在测试第二个测试用例:

SELECT * FROM space.table WHERE id in (X1, X2 ... X3000)

我想从 Cassandra 的每个请求中获取 3000 行随机数据。

本例中的最大 RPS 15 RPS 之后，Cassandra 线程池中出现大量待处理任务，类型为:Native-Transport-Requests。从 cassandra 获得大结果集不是最好的主意吗？最佳做法是什么，当然我可以将 3000 行划分为单独的请求，例如 30 个请求，每个请求有 100 个 ID。我在哪里可以找到有关它的信息，从性能角度来看，WHERE IN operation 可能不好？

更新:

想分享我从 Cassandra 获取 3000 行不同 block 大小的测量结果:

Test with 3000 ids per request

Latency: 5 seconds
Max RPS to cassandra: 20


Test with 100 ids per request (total 300 request each by 100 ids)
Latency at 350 rps to service (350 * 30 = 10500 requests to cassandra): 170 ms (q99), 95 ms (q90), 75 ms(q50)
Max RPS to cassandra: 350 * 30 = 10500

Test with 20 ids per request (total 150 request each by 20 ids) 
Latency at 250 rps to service(250 * 150 = 37500 requests to cassandra): 49 ms (q99), 46 ms (q90), 32 ms(q50)
Latency at 600 rps to service(600 * 150 = 90000 requests to cassandra): 190 ms (q99), 180 ms (q90), 148 ms(q50)
Max RPS to cassandra: 650  * 150 = 97500


Test with 10 ids per request (total 300 request each by 10 ids)
Latency at 250 rps to service(250 * 300 = 75000 requests to cassandra): 48 ms (q99), 31 ms (q90), 11 ms(q50)
Latency at 600 rps to service(600 * 300 = 180000 requests to cassandra): 159 ms (q99), 95 ms (q90), 75 ms(q50)
Max RPS to cassandra: 650  * 300 = 195000


Test with 5 ids per request (total 600 request each by 5 ids)
Latency at 550 rps to service(550 * 600 = 330000 requests to cassandra): 97 ms (q99), 92 ms (q90), 60 ms(q50)
Max RPS to cassandra: 550  * 660 = 363000


Test with 1 ids per request (total 3000 request each by 1 ids)
Latency at 190 rps to service(250 * 3000 = 750000 requests to cassandra): 49 ms (q99), 43 ms (q90), 30 ms(q50)
Max RPS to cassandra: 190  * 3000 = 570000

Answer 1

IN 确实不推荐使用，尤其是对于这么多单独的分区键。问题是当您使用 IN 发送查询时:

1. 查询发送到任何节点(协调器节点)，而不是拥有数据的必要节点
2. 然后协调器节点识别哪些节点拥有特定分区键的数据
3. 将查询发送到已识别的节点
4. 协调节点收集所有节点的结果
5. 合并结果并发回

这会给协调器节点带来很大的负载，并使整个查询与集群中最慢的节点一样慢。

更好的解决方案是使用准备好的查询并为每个分区键发送单独的异步请求，然后在您的应用程序中收集数据。只需考虑到每个连接可以进行多少个飞行中的查询是有限制的。

附言应该可以进一步优化它，通过查看您的值，查找不同的分区键是否在同一 token 范围内，为同一 token 范围内的所有键生成 IN 查询，然后发送查询显式设置路由键。但它需要更高级的编码。