gpt4 book ai didi

cassandra - 如何让节点并发执行读操作?

转载 作者:行者123 更新时间:2023-12-01 11:29:13 27 4
gpt4 key购买 nike

我正在 6 节点集群上试验 Cassandra 3.0.2,发现“不直观”的读取缩放/工作负载模式。

查询:

select count(*) from dvds

其中 dvd 有 28 万条记录。

使用默认 vnode 设置(num_tokens:256),我发现将节点数从 1 增加到 2 可将读取性能提高约 35%,但超过 2 个节点后每增加一个节点,性能就会降低约 30%。

在禁用 vnode-s(num_tokens:1 和 initial_token-s 手动设置)的情况下,6 节点集群的性能比 num_tokens:256 高约 35%,但可以清楚地观察到以下模式:协调节点的 CPU 消耗为大约 50%(一个 CPU 内核的总容量)或大约 110-120%,而其他节点消耗大约 0% 或 60-70% 的单个内核容量。不直观的部分是:当一个节点忙时,其他节点空闲。 (当协调器 CPU 消耗在 110-120% 时,所有其他节点都非常空闲。当协调器的 CPU 为 50% 时,其他节点之一很忙。)

我能想到的最强假设是集群无法处理网络流量,但协调器的网络流量(我假设网络可扩展性问题最严重)似乎没有超过 1Mb/在任何时间点。 (节点上网络接口(interface)的吞吐量为 10/100 Mbps。)此外,由于网络可扩展性问题,我希望“num_tokens:1”设置在所有节点上显示最初的高 CPU 负载(协调器除外) ) -- 或者至少一些均匀分布的同时负载。

拜托,任何人都可以对此有所了解吗?

最佳答案

count(*) 有它的用处,但是非常昂贵。协调器本质上必须从所有节点上拉下所有内容,合并并对它们进行计数。与“读取所有内容”和本地计数相比,它提供的唯一功能是减少协调器和您的应用程序之间的一些网络负载。

如果您经常需要这个指标,我会建议使用计数器或 lwt 来保持对单个读取操作的计数(围绕查询而不是数据抽象创建数据模型)。如果只需要一次或很少使用,hadoop/spark 是一个不错的选择。您还可以根据您的数据模型从 EstimatedPartitionSize 指标(尽管每个节点)获得一个不错的估计值。

关于cassandra - 如何让节点并发执行读操作?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/34577749/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com