Amazon DynamoDB
开发人员指南 (API 版本 2012-08-10)
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

在 DynamoDB 中为关系数据建模的示例

此示例描述如何在 Amazon DynamoDB 中为关系数据建模。DynamoDB 表设计对应于关系建模中显示的关系订单输入架构。它采用相邻列表设计模式,此模式是在 DynamoDB 中表示关系数据结构的常见方式。

此设计模式需要您定义一组通常与关系架构中的各个表关联的实体类型。随后,使用复合 (分区和排序) 主键将实体项目添加到此表。这些实体项目的分区键是唯一标识项目的属性,该属性在所有项目上通常称为 PK。排序键属性包含可用于反向索引或全局二级索引的属性值。它通常称为 SK

定义以下实体来支持关系订单输入架构:

  1. HR-Employee - PK:EmployeeID,SK:员工姓名

  2. HR-Region - PK:RegionID,SK:区域名称

  3. HR-Country - PK:CountryId,SK:国家/地区名称

  4. HR-Location - PK:LocationID,SK:国家/地区名称

  5. HR-Job - PK:JobID,SK:职位

  6. HR-Department - PK:DepartmentID,SK:DepartmentID

  7. OE-Customer - PK:CustomerID,SK:AccountRepID

  8. OE-Order - PK OrderID,SK:CustomerID

  9. OE-Product - PK:ProductID,SK:产品名称

  10. OE-Warehouse - PK:WarehouseID,SK:区域名称

将这些实体项目添加到表之后,可通过将边缘项目添加到实体项目分区来定义这些项目之间的关系。下表演示了此步骤:


      显示实体项目之间的关系的示例表。

在此示例中,表上的“员工”、“订单”和“产品实体”分区都具有额外边缘项目,这些项目包含指向表上其他实体项目的指针。接下来,定义几个全局二级索引 (GSI) 以支持之前定义的所有访问模式。实体项目不会与主键或排序键属性使用同一类型的值。只需要让主键和排序键属性在表上显示为插入。

实际情况是,其中一些实体使用正确的名称,并且其他实体使用其他实体 ID 作为排序键值可让同一个全局二级索引支持多种类型的查询。此技术称为 GSI 重载。它有效消除了包含多种项目类型的表的 20 个全局二级索引的默认限制。此技术在下图中显示为 GSI 1:


      显示支持多种查询的全局二级索引的示例表。

GSI 2 旨在支持一种十分常见的应用程序访问模式,此模式用于获取表中所有具有特定状态的项目。对于具有跨可用状态不均匀分发的项目的大型表,此访问模式可产生热键,除非跨更多可并行查询的逻辑分区来分发项目。此设计模式称为 write sharding

为了对 GSI 2 执行此操作,应用程序将 GSI 2 主键属性添加到每个订单项目。它填充一个介于 0–N 之间的随机数,其中 N 通常可使用以下公式计算,除非出于特定理由采用其他方式:

ItemsPerRCU = 4KB / AvgItemSize PartitionMaxReadRate = 3K * ItemsPerRCU N = MaxRequiredIO / PartitionMaxReadRate

例如,假设需要以下内容:

  • 系统中将多达 200 万个订单,此数字在 5 年内将增至 300 万。

  • 这些订单中多达 20% 的订单将在任何指定时间处于“未结”状态。

  • 订单记录的平均大小约为 100 字节,“订单”分区中三个 OrderItem 记录 (每个记录约为 50 字节),这将提供 250 字节的平均订单实体大小。

对于此表,N 因素计算看上去与下类似:

ItemsPerRCU = 4KB / 250B = 16 PartitionMaxReadRate = 3K * 16 = 48K N = (0.2 * 3M) / 48K = 13

在此情况下,需要跨 GSI 2 上的至少 13 个逻辑分区来分发所有订单,以确保具有“未结”状态的所有订单项目的读取不会在物理存储层上产生热分区。好的做法是填充此数字以允许数据集中存在异常。因此,使用 N = 15 的模型可能很合适。如前面提到的,通过将随机 0–N 值添加到表上插入的每个订单和 OrderItem 记录的 GSI 2 PK 属性来执行此操作。

此细分假定,需要收集所有“未结”发票的访问模式发生的频率相对较低,这样您就可以使用突发容量来满足请求。可以使用状态和日期范围排序键条件查询以下全局二级索引,以按需生成处于指定状态的部分或所有订单。


      显示 GSI 2 主键和投影的属性的示例表。

在此示例中,跨 15 个逻辑分区随机分发项目。此结构之所以适用,是因为访问模式需要检索大量项目。因此,15 个线程中的任一线程都不可能返回空的结果集,这可能代表浪费的容量。查询始终使用 1 个读取容量单位 (RCU) 或 1 个写入容量单位 (WCU),即使未返回任何内容或未写入任何数据也是如此。

如果访问模式需要针对此全局二级索引执行高速查询以返回稀疏结果集,则更好的做法是使用哈希算法分发项目,而不是采用随机模式。在此情况下,可在运行时执行查询时选择已知属性,并在插入项目时将该属性哈希处理为 0 – 14 个键空间。之后,可从全局二级索引高效读取项目。

最后,您可以再次访问之前定义的访问模式。下面是访问模式和查询条件的列表,它们将用于新的 DynamoDB 版本的应用程序以进行适应:


      访问模式和查询条件的列表,包括按 ID 和姓名查询员工,以及按日期或状态查询订单。