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

【问题标题】：Cassandra 2.0.2 CQL Long Row Limitation / Performance ImpactCassandra 2.0.2 CQL 长行限制/性能影响
【发布时间】：2014-01-02 22:08:45
【问题描述】：

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

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

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

【问题讨论】：

标签： cassandra cql

【解决方案1】：

首先，我认为不正确。

我知道在早期版本的 Cassandra 中，宽行是必需的，但 CQL 似乎鼓励我们放弃这一点。

宽行得到很好的支持。 Jonathan Ellis Does CQL support dynamic columns / wide rows? 发了一个帖子：

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

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

根据mail thread 中的 Aaron Morton 所说：

当行数超过几十 MB 时，速度会变慢，当它们超过 50 MB 可能会很痛苦，当它们超过 100 MB 时，这是一个警告信号。和当它们超过 1GB 时，你不想知道那时会发生什么。

及以后：

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

恕我直言，在 MB 的几个 10 中，所有事情都是平等的，效果更好。

【讨论】：

感谢您的回答亚历克斯，实际上我想我的问题可能措辞不当。我最关心的是 CQL 表中有数十亿行是否会对性能产生影响，而不是行的大小。
一张表数十亿行还是一张表数十亿列？
表中有数十亿行，我将编辑问题。

【解决方案2】：

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

将此答案留作参考，但不选择“与比我了解更多的人交谈”并不是特别科学。

【讨论】：