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)时插入太多数据时存在风险.
我想在插入数据之前检查,检查发生如下:
我的问题是如何查询cassandra来获取这对夫妇的数据大小(adress_id,adress_name).之后,Cassandra中分区键的大小限制是多少.
正如Alex Ott上面提到的,你应该花更多时间在数据模型上,以避免首先出现大分区的可能性,通过不同地组织数据,或者通过人为地将分区拆分成更多部分(例如,时间序列数据经常分裂)例如,每天将数据放入一个单独的分区中.
从技术上讲,可以确定分区的现有大小,但它永远不会有效.要了解原因,您需要回忆一下Cassandra如何存储数据.单个分区的内容并不总是存储在同一个sstable(磁盘上文件)中 - 同一个分区的数据可能分布在多个文件中.一个文件可能有几行,另一个文件可能有几行,第三个文件可能删除或修改一些旧行,依此类推.为了计算分区的长度,Cassandra需要读取所有这些数据,将它们合并在一起,并测量结果的大小.卡桑德拉并没有通常做到这一点就写-它只是将新更新的内存(并最终导致新的SSTable),而无需首先读取旧数据.这就是使Cassandra中的写入速度如此之快的原因 - 您在每次写入之前读取整个分区的想法将大大减慢它们的速度.
最后,虽然Cassandra没有很好地处理大分区,但如果开发人员想要解决这个问题,就没有固有的原因.Cassandra克隆Scylla的开发人员担心这个问题,并正在努力改进它,但即使在Scylla中,巨大分区的处理还不完善.但最终会是.几乎 - 对于单个磁盘的大小,单个分区(根据定义,存储在单个节点上)的大小总是有限制的.如果您的数据模型确实被破坏并且您可以在单个分区中最终获得TB级,则此限制也可能成为严重问题.
| 归档时间: |
|
| 查看次数: |
630 次 |
| 最近记录: |