每个分区键的Cassandra大小限制

lar*_*uch 0 java database cloud cassandra scylla

我在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)
) 
Run Code Online (Sandbox Code Playgroud)

据我所知,cassandra将根据分区键(adress_id,adress_name)分发表格地址的数据.

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

我想在插入数据之前检查,检查发生如下:

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

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

Nad*_*'El 5

正如Alex Ott上面提到的,你应该花更多时间在数据模型上,以避免首先出现大分区的可能性,通过不同地组织数据,或者通过人为地将分区拆分成更多部分(例如,时间序列数据经常分裂)例如,每天将数据放入一个单独的分区中.

从技术上讲,可以确定分区的现有大小,但它永远不会有效.要了解原因,您需要回忆一下Cassandra如何存储数据.单个分区的内容并不总是存储在同一个sstable(磁盘上文件)中 - 同一个分区的数据可能分布在多个文件中.一个文件可能有几行,另一个文件可能有几行,第三个文件可能删除或修改一些旧行,依此类推.为了计算分区的长度,Cassandra需要读取所有这些数据,将它们合并在一起,并测量结果的大小.卡桑德拉并没有通常做到这一点就写-它只是将新更新的内存(并最终导致新的SSTable),而无需首先读取旧数据.这就是使Cassandra中的写入速度如此之快的原因 - 您在每次写入之前读取整个分区的想法将大大减慢它们的速度.

最后,虽然Cassandra没有很好地处理大分区,但如果开发人员想要解决这个问题,就没有固有的原因.Cassandra克隆Scylla的开发人员担心这个问题,并正在努力改进它,但即使在Scylla中,巨大分区的处理还不完善.但最终会是.几乎 - 对于单个磁盘的大小,单个分区(根据定义,存储在单个节点上)的大小总是有限制的.如果您的数据模型确实被破坏并且您可以在单个分区中最终获得TB级,则此限制也可能成为严重问题.

  • 这当然取决于你的用例.在某些用例中,大多数分区都是正常的,但只有极少数*坏*分区是巨大的.例如,如果您的分区代表用户并且大多数用户具有适度的活动历史记录,但只有少数垃圾邮件程序每分钟生成1000个请求.在这种情况下,您可以使用*background*进程查找大型分区(在它们变得非常庞大之前)并删除它们和/或将它们的密钥列为黑名单,因此进一步写入不会尝试写入它们. (4认同)