模块 2：规划数据模型
构建实体关系图，预先规划访问模式
概述
数据建模是设计应用程序在特定数据库中的数据存储方式的过程。DynamoDB 等 NoSQL 数据库的数据建模与关系型数据库的建模不同。关系型数据库的特点是灵活性，非常适合分析型应用程序。在关系型数据建模中，首先从实体入手。有了规范化关系模型后，就可以实现应用程序中需要的一切查询模式。
NoSQL 数据库（非关系型数据库）的特点是速度和规模，而非灵活性。关系型数据库的性能可能会随着扩展而下降，但 DynamoDB 等横向扩展的数据库在任何规模下都能保持一致的性能。您的 DynamoDB 表可能大于 100 TB，但表的读写性能仍然能保持与小于 1 GB 时的同等读写性能。
要充分利用 DynamoDB 等 NoSQL 数据库，就需要与使用典型关系型数据库时不一样的思维方式。在使用 DynamoDB 进行数据建模时，可采用以下最佳实践。
1.重点关注访问模式
无论进行哪种类型的数据建模，首先都要建立实体关系图，描述应用程序中的不同对象（实体）以及它们之间的联系（实体之间的关系）。
在关系型数据库中，需要直接将实体放入表中，并使用外键指定关系。在实现了数据表之后，关系型数据库会提供一种灵活的查询语言，以所需的形式返回数据。
在 DynamoDB 中，需要在对表建模之前考虑访问模式。NoSQL 数据库的优势是速度，而非灵活性。您首先要思考如何访问数据，然后根据访问数据的方式进行数据建模。
在设计 DynamoDB 表之前，清楚了解并记录应用程序中需要进行的数据读写。务必详尽无遗，并考虑到应用程序中的所有流程，因为您需要根据访问模式优化您的表。
2.优化对 DynamoDB 的请求数量
在记录了应用程序的访问模式需求之后，您就可以设计表了。设计表时，应尽量减少每个访问模式下对 DynamoDB 的请求数量。理想情况下，每个访问只需对 DynamoDB 发起一次请求，因为网络请求速度受限，会限制您在应用程序中的网络请求数量。
优化 DynamoDB 的请求数量之前，您需要理解一些核心概念：
3.不要伪造关系模型
刚开始使用 DynamoDB 的用户经常会试图在非关系 DynamoDB 上实现关系模型。如果这样做，将享受不到 DynamoDB 的大部分优势。
使用 DynamoDB 时最常见的反模式如下：
- 规范化：在关系型数据库中，您要将数据规范化，以便减少冗余和占用的存储空间，然后要使用连接来组合多个不同的表。然而，大规模数据表连接会导致速度慢、成本高。DynamoDB 不支持数据表连接 (join)，因为随着表数据增长，性能会变慢。
- 每个表只包含一种数据：在 DynamoDB 表中，单个表通常包含不同类型的数据。在我们的示例中，我们将在单个表中包含 User、Friend、Photo 和 Reaction 实体。在关系型数据库中，这将建模为四个独立的表。
- 二级索引太多：人们经常尝试为所需的每个额外访问模式创建一个二级索引。DynamoDB 是无模式的，其索引也是无模式的。您可以利用属性的灵活性，为同一个表中的多种类型数据引用同一个二级索引。这种方法称为索引重载。
在以下步骤中，我们将构建实体关系图，预先规划访问模式。在使用 DynamoDB 时，应始终需要先完成这些步骤。然后，在后续模块中，我们要在表设计中实现这些访问模式。
时长
20 分钟
操作步骤
-
构建实体关系图
在所有数据建模实践中，第一步都是构建实体关系图，展示应用程序中的实体以及实体之间的关系。
我们的应用程序中有以下实体：- User
- Photo
- Reaction
- Friendship
一个 User 可以有多个 Photo，而一个 Photo 可以有多个 Reaction。Friendship 实体表示 User 之间的多对多关系，因为一个 User 可以关注多个 User，也可以被多个其他 User 关注。
了解这些实体以及实体之间的关系后，就能构建出以下实体关系图。
-
规划用户个人资料访问模式
现在，我们有了实体关系图，下面将规划实体的访问模式。我们先从用户开始。
我们的移动应用程序用户需要创建用户个人资料。这些个人资料包括指定用户的用户名、头像、位置、当前状态和兴趣等信息。
用户能够浏览其他用户的个人资料。用户可能想浏览另一用户的个人资料，看看该用户是否值得关注，或者想了解一下现有好友的背景信息。
随着时间的推移，用户可能希望更新自己的个人资料，显示最新的状态或更新他们的兴趣爱好。
根据这些信息，我们将有三种访问模式：
- 创建用户个人资料（写）
- 更新用户个人资料（写）
- 获取用户个人资料（读）
-
规划照片访问模式
现在，我们来看一下照片的访问模式。
我们的移动应用程序允许用户上传照片并与好友分享，类似于 Instagram 或 Snapchat。当用户上传照片时，需要存储照片上传时间和文件在内容分发网络 (CDN) 上的位置等信息。
用户也可能不上传照片，他们可能只想浏览好友的照片。如果他们访问好友的个人资料，就会看到好友的照片，最新的照片会显示在最前面。如果他们非常喜欢某张照片，可以使用四种预定义互动中的一种对照片做出互动 - 爱心、笑脸、竖大拇指或太阳镜。查看照片时应显示照片的当前互动。
这部分包含以下访问模式：
- 上传用户的照片（写）
- 查看用户最近的照片（读）
- 添加照片互动（写）
- 查看照片和互动（读）
-
好友访问模式
最后，我们来规划一下好友的访问模式。
许多流行的移动应用程序都有社交网络功能。您可以关注好友，查看好友活动更新，接收您可能想要关注的其他推荐好友。
在您的应用程序中，好友是一种单向关系，就像 Twitter 一样。一个用户可以选择关注另一用户，后者也可以选择关注前者。在我们的应用程序中，我们将关注某个用户的用户称为“关注者”，将被某个用户关注的用户称为“被关注者”。
根据这些信息，我们将有以下访问模式：
- 关注用户（写）
- 查看用户的关注者（读）
- 查看用户的被关注者（读）
总结
我们现在已为我们的移动应用程序规划了所有访问模式。在后续模块中，我们将使用 DynamoDB 实现这些访问模式。
请注意，规划阶段可能需要几次迭代更新。首先对应用程序所需的访问模式有一个大致了解。然后规划表中的主键、二级索引和属性。接着返回开始阶段，确保所有访问模式都得到实现。在确认规划没有问题后，才可以开始实现访问模式。
