Cassandra 在多大程度上需要非规范化？
To what extent is denormalization necessary in Cassandra?
我负责将应用程序从 MySQL 迁移到 Cassandra。而且我很好奇，在这个过程中，去规范化到什么程度是必要的？
例如，如果程序在 table A 中搜索索引，然后在 table B 中查找该值的信息，这在 Cassandra 中是不允许的，还是不是最优的？应用程序中没有连接，只是像这样的几次查找。
我在网上找到的资源让我很困惑。我 需要 通过将这些 table 组合在一起来对数据进行非规范化，还是这只是为了加快 Cassandra 的性能？
Cassandra 中的数据建模比 "Denormalizing your tables" 多一点，我建议您在开始任何迁移之前仔细阅读有关该主题的更详细的讨论。
也就是说，绝对有必要重新评估您拥有的任何模式，使其适合 Cassandra 的工作参数。围绕分区和集群键的选择将决定您的用例成败。您必须确保您对查询进行建模，并且有一个 table 和一个适合您要执行的每个查询的键。
通常在像 MySQL 这样的关系数据库中，您设计 tables 来有效地存储数据，然后规范化这些 tables 以消除冗余信息，以节省存储空间space，并防止数据不一致（例如不同行中的人的地址不同）。然后几乎是事后的想法，您可以通过在任何列上进行连接和添加索引来加快这些查询的速度，从而找出要对那些规范化的 table 执行哪些查询。
使用 Cassandra 时，您首先要弄清楚需要执行哪些查询，然后设计架构以高效地执行这些查询。 Cassandra 中的查询选项比 MySQL 中的查询选项要有限得多，因为您真正需要使用的只是分区键和集群列。您不能轻易地进行联接，不能轻易地聚合，而且搜索选项非常有限。您可以创建二级索引，但使用它们不像 RDBMS 索引那样高效，因此通常您希望避免使用它们并主要依赖复合主键。
所以不，您不需要完全非规范化您的数据，但它是工具箱中的一个有用工具，可以提高常用查询的效率。它基本上是一种将大量相关信息分组到一个桶中的方法，您可以通过密钥快速访问该桶。存储被认为是便宜的，所以通常我们不关心我们是否在多个 tables 中有一些冗余信息（在合理范围内）。
当您说程序 "searches" 用于 table A 中的索引时，这听起来效率很低，因为您无法轻松地在 Cassandra table 中搜索内容。您想要的是让程序知道它要查找的内容的密钥，以便 Cassandra 可以直接转到存储该信息的位置。例如，如果用户登录到系统，您可以使用他们的用户 ID 来访问有关他们的所有信息的信息桶。
现在完全可以接受table在tableA中有一个外键用于在tableB中查找其他相关信息，因为那只是两个键读取，一个用于 table A，然后一个用于 table B。但是如果不执行这两个步骤偶尔查找单独的行，您实际上需要加入 table 的所有行A 和 B 用于生成报告，那么你最好将它们组合成一个非规范化 table.
我负责将应用程序从 MySQL 迁移到 Cassandra。而且我很好奇，在这个过程中，去规范化到什么程度是必要的？
例如，如果程序在 table A 中搜索索引，然后在 table B 中查找该值的信息，这在 Cassandra 中是不允许的，还是不是最优的？应用程序中没有连接，只是像这样的几次查找。
我在网上找到的资源让我很困惑。我 需要 通过将这些 table 组合在一起来对数据进行非规范化，还是这只是为了加快 Cassandra 的性能？
Cassandra 中的数据建模比 "Denormalizing your tables" 多一点，我建议您在开始任何迁移之前仔细阅读有关该主题的更详细的讨论。
也就是说，绝对有必要重新评估您拥有的任何模式，使其适合 Cassandra 的工作参数。围绕分区和集群键的选择将决定您的用例成败。您必须确保您对查询进行建模，并且有一个 table 和一个适合您要执行的每个查询的键。
通常在像 MySQL 这样的关系数据库中，您设计 tables 来有效地存储数据，然后规范化这些 tables 以消除冗余信息，以节省存储空间space，并防止数据不一致（例如不同行中的人的地址不同）。然后几乎是事后的想法，您可以通过在任何列上进行连接和添加索引来加快这些查询的速度，从而找出要对那些规范化的 table 执行哪些查询。
使用 Cassandra 时，您首先要弄清楚需要执行哪些查询，然后设计架构以高效地执行这些查询。 Cassandra 中的查询选项比 MySQL 中的查询选项要有限得多，因为您真正需要使用的只是分区键和集群列。您不能轻易地进行联接，不能轻易地聚合，而且搜索选项非常有限。您可以创建二级索引，但使用它们不像 RDBMS 索引那样高效，因此通常您希望避免使用它们并主要依赖复合主键。
所以不，您不需要完全非规范化您的数据，但它是工具箱中的一个有用工具，可以提高常用查询的效率。它基本上是一种将大量相关信息分组到一个桶中的方法，您可以通过密钥快速访问该桶。存储被认为是便宜的，所以通常我们不关心我们是否在多个 tables 中有一些冗余信息（在合理范围内）。
当您说程序 "searches" 用于 table A 中的索引时，这听起来效率很低，因为您无法轻松地在 Cassandra table 中搜索内容。您想要的是让程序知道它要查找的内容的密钥，以便 Cassandra 可以直接转到存储该信息的位置。例如，如果用户登录到系统，您可以使用他们的用户 ID 来访问有关他们的所有信息的信息桶。
现在完全可以接受table在tableA中有一个外键用于在tableB中查找其他相关信息，因为那只是两个键读取，一个用于 table A，然后一个用于 table B。但是如果不执行这两个步骤偶尔查找单独的行，您实际上需要加入 table 的所有行A 和 B 用于生成报告，那么你最好将它们组合成一个非规范化 table.