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）的地方插入太多数据时，存在风险。

我想在插入数据之前进行检查，检查过程如下：

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

我的问题是如何查询cassandra以与夫妻（adress_id，adress_name）获得数据大小。之后，在Cassandra中分区键的大小限制是什么。

Answer 1

正如Alex Ott上面指出的那样，您应该花更多的时间在数据模型上，从而避免通过使用不同的数据组织方式或人为地将分区分为更多部分（例如，时间序列）来避免巨大分区的可能性。例如，数据通常每天都会将数据分成一个单独的分区。

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

最后，尽管Cassandra不能很好地处理巨大的分区，但是没有内在的原因，如果开发人员想要解决此问题，它将永远无法解决。 Cassandra的开发人员克隆了Scylla，对此问题感到担忧，并正在努力加以改进，但是即使在Scylla中，对大型分区的处理也不是完美的。但是最终会。几乎-单个分区（根据定义，存储在单个节点上）的大小始终会受到单个磁盘大小的限制。如果您的数据模型确实损坏，并且最终在单个分区中可以达到TB，那么此限制也可能会成为一个严重的问题。

每个分区键的Cassandra大小限制

1 个答案: