我应该根据所使用的查询来取消具有1B行的Cassandra表的规范化吗

Question

我知道在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

我总是使用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));

Answer 1

快速答案是YES，您应该取消数据的规范化，并始终从应用程序查询开始。那些来自关系数据库背景的人倾向于关注数据的存储方式(表模式(，而不是首先列出所有的应用程序查询。

通过首先关注应用程序查询，然后为每个查询设计一个表，可以优化表的读取。如果您尝试将应用程序查询调整为现有表，则该表将永远不会得到优化，而且查询几乎总是很慢。

附带说明一下，详细的答案是1B行!=1B在您发布的模式中进行分区。表定义在行和分区之间没有1:1的映射。表中的每个分区都可以有一行或多行。干杯