java - Cassandra 每个分区键的大小限制

Question

我在 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的数据。

当我尝试插入太多共享相同(adress_id、adress_name)的数据时，存在风险。

我想在插入数据之前进行检查，检查是这样的:

1. 我在 cassandra 中已有多少数据(adress_id、adress_name)，假设是 5MO。
2. 我需要检查尝试插入的数据大小是否超过每个分区键的 Cassandra 限制减去 cassandra 中的现有数据。

我的问题是如何查询 cassandra 以获取这对(adress_id，adress_name)的数据大小。接下来是 Cassandra 中分区键的大小限制。

Answer 1

正如 Alex Ott 上面指出的那样，您应该在数据模型上花费更多时间，通过以不同方式组织数据或人为地将分区分割为更多部分(例如，时间序列)，从一开始就避免出现巨大分区的可能性例如，data 通常每天将数据分割到一个单独的分区中)。

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

最后，虽然 Cassandra 不能很好地处理巨大的分区，但如果开发人员想解决这个问题，没有什么内在原因说明它永远不能解决这个问题。 Cassandra 克隆版 Scylla 的开发人员担心这个问题，并正在努力改进它，但即使在 Scylla 中，对巨大分区的处理也并不完美。但最终会是这样。几乎 - 单个分区(根据定义，存储在单个节点上)的大小始终与单个磁盘的大小有关。如果您的数据模型确实被破坏并且您最终可能在单个分区中拥有 TB 的数据，那么此限制也可能成为一个严重的问题。