我在测试cassandra时遇到了一个非常奇怪的问题。我有一个非常简单的列族存储视频数据（键指向时间段，在此期间只有一列包含~2MB视频）。
使用案例
我开始使用Hector API（循环法）将数据加载到6个空节点（Cassandra为8GB RAM） - 加载在4个线程中运行，每个线程为第二行添加4行。
一段时间（运行负载大约一小时左右）将近100-200 GB添加到节点（取决于复制因子），然后一个或多个节点变得无法访问。 （没有ping只需重启帮助）
为什么要压缩
我确实使用分层级压缩和监视系统（Debian）我可以看到它实际上不是写入但是压缩占用了几乎所有资源（磁盘，内存）并导致服务器拒绝写入而不是失败。
经过30-40分钟的测试压缩任务后，无法处理并排队等待。有趣的是，没有删除和更新 - 所以压缩只是一次又一次地读取/写入数据而不会给我带来实际价值（就像它可以在晚上压缩一次）。
当我放慢速度时 - 即运行2个线程，延迟1秒，事情变得更好但是当我在节点上有20TB而不是100 GB时是否仍然有效。
Cassandra是否针对此类工作负载进行了优化？如何在压缩和读/写之间正常分配资源？
更新 更新网络驱动程序解决了无法访问群集的问题
谢谢， 塞吉。
答案 0 :(得分：4)
Cassandra将使用最多in_memory_compaction_limit_in_mb个内存来进行压缩。在同时提供读取和写入的同时运行压缩是常规的。如果你继续尽可能快地向它写入写入，压缩可能会落后也是正常的;如果您的读取工作负载要求压缩是最新的或始终接近它，那么您将需要一个更大的集群来分散更多机器的负载。
在线查询的每个节点的推荐磁盘数量最多为500GB，如果你推动它可能是1TB。请记住，如果节点出现故障，则必须重建此数量的数据。典型的Cassandra工作负载受CPU限制或iops限制，而不受磁盘空间限制，因此无论如何都无法充分利用该空间。
（也可以对Cassandra进行批量分析，我们使用Cassandra Filesystem进行批量分析，在这种情况下需要更高的磁盘：cpu比率，但我们也使用自定义压缩策略。）< / p>
从您的报告中不清楚为什么服务器无法访问。这实际上是操作系统级别的问题。 （你交换了吗？禁用交换将是一个很好的第一步。）