每个分区键的 Cassandra 大小限制答案

【问题标题】：Cassandra size limit per partition key每个分区键的 Cassandra 大小限制
【发布时间】：2019-06-02 05:58:18
【问题描述】：

我在 cassandra 中有这张桌子：

CREATE TABLE adress (
adress_id uuid,
adress_name text,
key1 text,
key2 text,
key3 text,
key4 text,
effective_date timestamp,
value text,
active boolean,
PRIMARY KEY ((adress_id, adress_name), key1, key2, key3, key4, effective_date)
)

据我所知，cassandra 将根据分区键 (adress_id, adress_name) 分配表地址的数据。

当我尝试在共享相同 (adress_id,adress_name) 的位置插入太多数据时存在风险..

我想在插入数据之前检查一下，检查是这样的：

我已经在 cassandra 中拥有这对夫妇（adress_id、adress_name）的多少数据，假设它是 5MO。
我需要检查我尝试插入的数据大小是否不超过 每个分区键的 Cassandra 限制减去 cassandra 中的现有数据。

我的问题是如何查询 cassandra 以获取 数据大小 与这对夫妇 (adress_id, adress_name)。之后，Cassandra 中的分区键的大小限制是多少。

【问题讨论】：

您可能有非常大的分区（我见过一些损坏的设置，其中一个分区是 60Gb），但最好不要超过 100Mb。但一切都取决于您用于访问数据的查询。
@AlexOtt 谢谢你的回答！任何想法如何计算现有分区的大小？
主要是通过读取数据并将所有内容汇总在一起+元数据的开销......但我建议只花更多时间在数据模型上。 nodetool tablehistograms 将为您提供当前分区大小的分布
分区大小越小，性能越好。如果您的分区太大，Cassandra 必须扫描整个分区才能获取结果。

标签： java database cassandra cloud scylla

【解决方案1】：

正如 Alex Ott 上面提到的，您应该在数据模型上花费更多的时间来避免出现大分区的可能性，方法是通过不同的方式组织数据，或者人为地将分区拆分为更多部分（例如，时间序列例如，data 通常每天都会将数据拆分到一个单独的分区中）。

技术上可以计算出分区的现有大小，但它永远不会有效。要了解原因，您需要回忆一下 Cassandra 是如何存储数据的。单个分区的内容并不总是存储在同一个 sstable（磁盘文件）中——同一个分区的数据可能分布在多个文件中。一个文件可能有几行，另一个文件可能有更多行，第三个文件可能删除或修改一些旧行，依此类推。为了计算分区的长度，Cassandra 需要读取所有这些数据，将它们合并在一起，然后测量结果的大小。 Cassandra 通常不在写入时执行此操作 - 它只是将新的更新写入内存（最终写入新的 sstable），而不先读取旧数据。这就是 Cassandra 写入速度如此之快的原因 - 您在每次写入之前读取整个分区的想法会大大减慢它们。

最后，虽然 Cassandra 不能很好地处理大分区，但如果开发人员想要解决这个问题，它也没有任何内在的原因。 Cassandra 克隆 Scylla 的开发人员担心这个问题，并正在努力改进它，但即使在 Scylla 中，对巨大分区的处理也并不完美。但最终会的。几乎 - 单个分区的大小（根据定义，存储在单个节点上）作为单个磁盘的大小总是有限制的。如果你的数据模型真的被破坏了，那么这个限制也可能会成为一个严重的问题，并且你最终可能会在单个分区中得到一个 TB。

【讨论】：

感谢您的回答，这很有帮助！我需要找出如何重新建模数据的解决方案，这样我就不会陷入大分区的问题。好吧，考虑到数据模型已经投入生产并且与之关联的数据太多，那么我感觉不可能做出改变..我应该如何处理以纠正错误的数据模型？
这当然取决于您的用例。在某些用例中，大多数分区是正常的，但只有极少数 bad 分区很大。例如，如果您的分区代表用户并且大多数用户的活动历史记录不多，但只有少数垃圾邮件机器人每分钟发出 1000 个请求。在这种情况下，您可以有一个 background 进程来查找大分区（在它们变得非常大之前）并删除它们和/或将它们的密钥列入垃圾邮件分区，这样进一步的写入就不会尝试写入他们。