Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 192.168.170.128 317.66 MiB 256 62.4% 45e953bd-5cca-44d9-ba26-99e0db28398d rack1
UN 192.168.170.129 527.05 MiB 256 60.2% e0d2faec-9714-49cf-af71-bfe2f2fb0783 rack1
UN 192.168.170.130 669.08 MiB 256 60.6% eaa1e39b-2256-4821-bbc8-39e47debf5e8 rack1
UN 192.168.170.132 537.11 MiB 256 60.0% 126e151f-92bc-4197-8007-247e385be0a6 rack1
UN 192.168.170.133 417.6 MiB 256 56.8% 2eb9dd83-ab44-456c-be69-6cead1b5d1fd rack1
Datacenter: dc2
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 192.168.170.136 386.12 MiB 256 41.0% 2e57fac6-95db-4dc3-88f7-936cd8038cac rack1
UN 192.168.170.137 518.74 MiB 256 40.9% b6d61651-7c65-4ac9-a5b3-053c77cfbd37 rack1
UN 192.168.170.138 554.43 MiB 256 38.6% f1ba3e80-5dac-4a22-9025-85e868685de5 rack1
UN 192.168.170.134 153.76 MiB 256 40.7% 568389b3-304b-4d8f-ae71-58eb2a55601c rack1
UN 192.168.170.135 350.76 MiB 256 38.7% 1a7d557b-8270-4181-957b-98f6e2945fd8 rack1CREATE KEYSPACE grudb WITH replication = {'class': 'NetworkTopologyStrategy', 'dc1': '3', 'dc2': '2'} AND durable_writes = true;那是我的背景。
cl是一个。
1条答案
按热度按时间sg24os4d1#
一般来说，一个10节点的集群可以维持更高的吞吐量，但这是否真的转化为更高的“Cassandra压力”分数，取决于你到底在做什么：
首先，你需要确保Cassandra压力客户机不是你的瓶颈。例如，如果运行cassandra stress的机器的cpu或网络利用率为100%，那么即使您有100个服务器节点，您也不会得到更好的分数。
其次，您需要确保cassandra stress的并发性足够高。在极端情况下，如果cassandra stress只发送一个又一个请求，那么您所做的只是测量延迟，而不是吞吐量。此外，如果一次只向一个节点发送一个请求，那么如果您有100个节点，则没有帮助。所以，请尝试增加Cassandra的并发性，看看这是否有什么不同。
现在我们已经排除了潜在的cassandra压力问题，让我们看看服务器。您并不是简单地将集群从1个节点增加到10个节点。如果你这么做了，如果性能没有提高，你会很惊讶的。但是你做了一些其他的事情：你增加到了10个节点，但是也大大增加了写操作的工作量——在你的设置中，每一次写操作需要5个节点（！），一个dc上有3个，另一个上有2个（这些是您配置的rfs）。因此，即使在最好的情况下，您也不能期望这个集群上的写吞吐量比单个节点好两倍以上。实际上，由于这种复制的所有开销，您期望的性能甚至不到两倍，因此具有类似的性能也就不足为奇了。
上面的估计是写性能。对于读性能，既然您说您使用的是cl=one（顺便说一下，您可以使用cl=local\u one），那么读吞吐量确实应该与集群的大小成线性关系。如果不是这样，我猜您在上面描述的设置中有问题（客户机瓶颈或使用的并发性太少）。
请尝试分别运行读写基准测试，以更好地了解哪一个是主要的可伸缩性问题。