Cassandra数据模型设计指南_技术

摘要：本文通过一个简单的实例详细介绍了Cassandra数据建模的五个步骤。以下是译文。

我们最近在Instaclustr发表了一篇有关在Cassandra中经常出现的数据建模错误的文章。这篇文章非常受欢迎，并促使我思考如何设计出高质量的Cassandra数据模型，以避免在设计的过程中掉入陷阱。

在互联网上，你可以找到很多有关适配数据模型设计规则和设计模式的优秀文章，例如：Apache Cassandra数据建模指南和数据建模优秀实践。

然而，我们并没有一个详细的 *** 作步骤来指导你对数据进行分析，并适配相应的规则和模式。但这份白皮书正尝试着填补这方面的空白。

第一阶段：了解数据

这个阶段有两个步骤，这两个步骤都是为了更好地理解你正在建模的数据和所需的访问模式。

定义数据域

第一步是深入理解数据域。作为一个非常熟悉关系数据建模的人，我倾向于通过绘制ER图来理解这些实体、主键和互相之间的关系。但是，如果你熟悉另一种标记法，你也可以用一下试试。你需要在逻辑层面理解以下关键点：

数据模型中的实体（或对象）是什么？

实体的主要关键属性是什么？

实体之间有哪些关系（即从一个到另一个的引用）？

关系的相对基数是多少（例如，假设存在一对多的关系，那么平均是1对10，还是1对10000）？

定义所需的访问模式

下一步，弄清楚你自己需要如何访问数据：

列出需要访问数据的路径，例如：

以客户ID为索引，在某个日期范围内搜索交易记录，然后从搜索结果中搜索特定交易的详细信息。按某个特定的服务器和度量标准搜索，检索x度量值，按年龄升序排列。

按某个特定的服务器和度量检索，从特定时间点开始检索x度量值。

对于给定的传感器，检索给定日期的多个度量的所有读数。

对于给定的传感器，检索当前值。

请记住，对记录的任何更新 *** 作都是一个访问路径，都需要仔细考虑。

从性能的角度来确定哪些访问最关键。是否有一些访问需要尽可能快的速度，而其他一些访问则需要花一定的时间进行多次读取或在一定范围内进行检索？

请记住，在这个阶段，你需要非常全面地了解如何访问数据，在Cassandra的性能、可靠性和可伸缩性之间做出权衡。

第二阶段：了解实体

这个阶段有两个具体的步骤，旨在了解与数据相关的主要和次要实体。

确定主要访问实体

现在，我们开始从分析数据域和应用需求转为开始设计数据模型了。在进入这个阶段之前，你需要把上面两个步骤的工作做得扎实一点。

这一阶段主要的想法是根据你所使用的访问模式将数据去规范化到尽可能少的表中。对于每一次按键进行的查询，需要有一张表来满足查询需求。我创造了一个术语“主要访问实体”来描述用于查询的实体（例如，按客户ID进行的查找将使用客户表作为主要访问实体，按服务器和度量名称的查找将使用服务器-度量实体作为主要访问实体）。

主要访问实体定义了去规范化结果表的分区级别（即表会为每个主要访问实体的实例提供一个分区）。

你可以选择使用二级索引来满足一些访问模式，而不是使用不同的主要访问实体来实现数据复制。请记住，包含在辅助索引中的列应比被索引的表的基数更低，并且你要对索引值的更新频率了如指掌。

对于上面举的访问模式的例子，我们将定义以下主要访问实体：

客户和交易（从客户实体获取交易清单，然后从交易实体查找交易详情）

服务器-度量

传感器

分配次要实体

下一步是寻找一个地方用来存储那些没有被选为主要访问实体的实体数据（这些实体被称为次要实体）。你可以这样做：

通过从一对多关系的父级次要实体获取数据并在主要访问实体级别存储它的多个副本（例如，将客户的电话号码存储在客户的订单记录中）。

通过从一对多关系的子次要实体获取数据并通过使用聚集键或通过使用多值类型（列表和映射）将其存储在主要访问实体级别上（例如，将记录项列表添加到交易表中）。

对于一些次要实体，只有一个相关的主要访问实体，所以不需要选择在哪个方向推入数据。对于其他实体，你需要选择将数据推入哪些主要访问实体。

为了获得最佳的读取性能，需要将数据副本推送到用作次要实体中数据访问路径的每个主要访问实体中。