Cassandra 2.0.2 CQL长行限制/性能影响

Question

给定一个存储ID和Blob的简单CQL表，是否存在可能存储数十亿行的任何问题或性能影响？

我知道早期版本的Cassandra宽行是必须的，但CQL似乎鼓励我们摆脱它。我没有任何特殊要求确保数据聚集在一起或能够以任何顺序过滤。我想知道CQL表中的很多行是否会出现问题。

我正在考虑对我的数据进行分箱，即 - 创建一个分区键，它是ID的哈希％n，并将数据限制为n'箱'（数百万？）。在我添加开销之前，我想验证它是否真的值得。

Answer 1

首先，我认为不正确。

  

我知道早期版本的Cassandra宽行是必须的，但CQL似乎鼓励我们远离它。

支持宽行并且很好。 Jonathan Ellis发表了一篇帖子Does CQL support dynamic columns / wide rows?：

  

一个常见的误解是CQL不支持动态列或宽行。相反，CQL旨在支持您可以使用Thrift模型执行的所有操作，但使其更容易，更易于访问。

关于“存储可能数十亿行的性能影响”的部分，我认为要记住的重要部分是这些行的大小。

根据Aaron Morton的说法mail thread：

  

当行数超过10的MB时，当它们达到上限时，事情就会变慢   50 MB它们可能是一种痛苦，当它们超过100MB时，这是一个警告信号。和   当他们达到1GB以上时，你就不想知道接下来会发生什么。

以后：

  

较大的行需要更长的时间来完成压缩，往往会导致更多的JVM GC和   修理期间有问题。请参阅in_memory_compaction_limit_in_mb注释   yaml文件。在修复期间，我们检测行和流的范围的差异   它们在节点之间。如果您有宽行，则单个列是我们的同步   我们将在节点上创建该行的新副本，然后必须对其进行压缩。   我已经看到非常宽行的节点上的负载下降了150GB   减少压实设置。

     

恕我直言，所有事情都在几十MB的MB中工作得更好。

Answer 2

在与Aaron Morton（最后一次泡菜）聊天时，他表示每张桌子数十亿行不一定有问题。

留下这个答案作为参考，但不是选择它作为“与一个比我了解得多的人谈过”并不是特别科学。