能够重新创建更简单的方案，请参阅底部附近的更新
首先回到问题的一些背景。我在Amazon EC2上做了一些Cassandra实验。东部有4个节点，一个集群有4个西部节点。为了模拟我的用例，我使用在单独的East-EC2实例上运行的cassandras内部压力工具来发布：
./ stress -d us-eastnode1，...，us-eastnode4 --replication-strategy NetworkTopologyStrategy --strategy-properties us-east：3，us-west：3 -e LOCAL_QUORUM -c 200 -i 10 -n 1000000
接下来我运行相同的写操作，同时也开始在另一个单独的West-EC2实例上读取相应的local_quorum：
./ stress -d us-westnode1，...，us-westnode4 -o read -e LOCAL_QUORUM -c 200 -i 10 -n 1000000
在第一次300k左右读取之后，其中一个西节点开始阻塞~80％iowait cpu并将总读取速度降低~90％。与此同时，写入在接近正常速度时完成得很好。为了弄清楚导致这个单节点到iowait阻塞的原因，我只启动了读者，并立即遇到了同样的问题。
我的令牌是这样的，它在东方节点周围平衡，每个西节点+1在每个相应的东节点上，即。 us-eastnode1：0，us-westnode1：1，us-eastnode2：42535295865117307932921825928971026432等。实际负载最终在整个集合中平衡，所以我从中找出了可能的原因。
我最终进行了一次重大压缩（尽管CF只有10个sstables，并且没有轻微的压缩已经开始了>小时）。一旦我再次尝试压力读取，节点就很好......但是下一个顺序节点就有了同样的问题。这是我发现的最大线索，但我不知道它在哪里。
我在cassandra IRC中问过，但从那里得不到任何想法。任何人对我可以尝试的新事物有任何想法，试图弄清楚这里出了什么问题？
第二天更新 通过简单地运行写入压力两次，然后运行读取，我能够重现这一点。第一次写入后，nodetool cfstats显示每个节点负责~750k密钥，这对于1,000,000个密钥和RF：3个DC中的4个节点是有意义的。然而，在第二次压力写入之后，us-westnode1具有~1,500,000个键，而us-westnode1-3具有~875,000个键。然后当它尝试读取时，具有两倍于其应有的负载的节点正在停滞。 这让我觉得问题在于压力工具。它使用相同的c0-c199列覆盖相同的0000000-0999999行。然而，不知何故，没有一个节点保持与第一次运行时大致相同的数据负载。
简单娱乐 通过删除第二个DC作为变量来缩小问题范围。现在运行1个DC，4个节点，每个节点拥有25％的所有权，RandomPartitioner，以及下面的代码：
./ stress -d node1，...，node4 --rerelication-factor 3 -e QUORUM -c 200 -i 10 -n 1000000
在一次写入（和次要压缩）之后，每个节点都有~7.5gb的负载 在两次写入（和次要压缩）之后，每个节点都有~8.6gb的负载，节省了〜15gb的node2。 在所有节点上运行主要压缩之后，每个节点都恢复到~7.5gb的负载。
这是一个奇怪的压缩问题，当像压力工具那样有效地覆盖整个数据集时会出现吗？
答案 0 :(得分：1)
Is this simply a weird compaction issue that crops up when effectively overwriting the entire dataset like the stress tool does?
是的，压缩存储器会在某种程度上随机运行，某些节点不像其他节点那样紧凑是正常的。 （也就是说，听起来像node2基本上没有完成压缩可能只是落后了。）
如果您的实际工作量也涉及大量覆盖，您应该测试Leveled Compaction，它旨在在该场景中做更好，更可预测的工作：http://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandra