我知道在Cassandra表中,使用相同分区键的插入将覆盖前面的值。因此,如果我们也用相同的主键插入10条记录,它也会这样做,这意味着只覆盖并存储第10个值。正当
因此,我在我的Cassandra数据库中有下表,它有大约10亿行,约4800个分区键:
CREATE TABLE tb(
parkey varchar, //this is a UUID converted to String.
pk1 text,
pk2 float,
pk3 float,
pk4 float,
pk5 text,
pk6 text,
pk7 text,
PRIMARY KEY ((parkey),pk1, pk2, pk3, pk4, pk5, pk6, pk7));
这意味着我有大约10亿个主键!!我有这么大的主键,因为每个记录只有在具有所有值时才是唯一的。然而,我有一种感觉,这可能不是最好的表模式,因为spark查询所有这些数据也需要5分钟的时间,而在从内存中取消持久化一个表之前,它还要再挂起10分钟,我不知道为什么!
我应该根据所使用的查询以某种方式分解和反规范化表吗?这会缩短查询时间吗我的想法是,即使我分解了这个表,对于将要创建的每个非规范化表,我仍然有大约10亿个主键。这样会有效吗?查询新创建的表不会再花15分钟吗?
编辑1
我总是使用一个查询来选择分区键。因此有一张表。这会缩短时间吗?
CREATE TABLE tb(
parkey varchar, //this is a UUID converted to String.
pk1 varchar, //also a UUID but completely unique for every record
c1 text,
c2 float,
c3 float,
c4 float,
c5 text,
c6 text,
c7 text,
PRIMARY KEY ((parkey),pk1));
1条答案
按热度按时间qxsslcnc1#
快速回答是“是”,您应该取消数据的规范化,并始终从应用程序查询开始。那些来自关系数据库背景的人倾向于关注数据的存储方式(表模式),而不是首先列出所有应用程序查询。
通过首先关注应用程序查询,然后为每个查询设计一个表,该表针对读取进行了优化。如果尝试将应用程序查询调整为现有表,则该表将永远不会优化,并且查询几乎总是很慢。
作为补充说明,长话短说的答案是1B行
!=
您发布的模式中的1B分区。表定义在行和分区之间没有1:1Map。表中的每个分区都可以有一行或多行。干杯