Cassandra在什么程度上需要非规范化?

时间:2015-01-09 20:41:47

标签: mysql database optimization cassandra database-normalization

我负责将应用程序从MySQL迁移到Cassandra。我很好奇,在这个过程中反规范化到什么程度?

例如,如果程序在表A中搜索索引,那么在表B中查找该值的信息,这在Cassandra中是不允许的,还是只是不是最优的?应用程序中没有连接,只有几个这样的查找。

我在网上找到的资源让我很困惑。我是否需要通过将这些表组合在一起来对数据进行非规范化,或者这只是加快Cassandra性能的因素?

2 个答案:

答案 0 :(得分:2)

通常在像MySQL这样的关系型数据库中,您可以设计表以有效地存储数据,然后对这些表进行规范化以消除冗余信息,节省存储空间,并防止数据不一致(例如为一个人设置不同的地址)在不同的行)。然后几乎作为事后的想法,你可以通过连接和在任何列上添加索引来确定你想对这些规范化表做什么查询,以便快速地进行这些查询。

使用Cassandra,您首先要弄清楚需要执行哪些查询,然后设计架构以有效地执行这些查询。 Cassandra中的查询选项远比MySQL更有限,因为您真正需要处理的只是分区键和聚类列。你不能轻易做到加入,你不能轻易聚合,而且搜索选项非常有限。您可以创建二级索引,但使用它们不像RDBMS索引那样高效,因此通常您希望避免使用它们并主要依赖复合主键。

所以不,你没有需要来完全反规范化你的数据,但它是工具箱中一个有用的工具,可以使常用查询高效。它基本上是一种将大量相关信息分组到一个桶中的方法,您可以通过密钥快速访问该桶。存储被认为是便宜的,因此通常我们不关心我们是否在多个表中有一些冗余信息(在合理范围内)。

当你说程序“搜索”表A中的索引时,这听起来效率低,因为你无法在Cassandra表中轻松搜索。你想要的是让程序知道它所寻找的关键,这样Cassandra就可以直接进入存储信息的地方。例如,如果用户登录系统,您可以使用他们的用户ID访问一大堆信息,告诉他们所有相关信息。

现在在表A中有一个外键可以完全接受,用于在表B中查找其他相关信息,因为这只是两个键读取,一个用于表A,另一个用于表B.但是如果为了生成一个报告,你实际上需要连接表A和B的所有行,而不是偶尔查找单个行的两个步骤,然后你最好将它们组合成一个非规范化表。

答案 1 :(得分:1)

Cassandra中的数据建模有点超过"非正规化你的表"在你开始任何迁移之前,我建议你就这个问题进行更详细的讨论。

那就是说,绝对必要你重新评估你拥有的任何模式,以便它适合Cassandra的工作参数。分区和群集密钥的选择将决定您的用例。您必须确保对查询建模,并且每个要执行的查询都有一个包含相应密钥的表。

相关问题