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

在 DynamoDB 为关系数据建模的最佳实践

传统的关系数据库管理系统 (RDBMS) 平台将数据存储在一种规范化的关系结构,以将层次数据结构缩减至一组跨多个表存储的常见元素。以下架构是通用订单输入应用程序的示例,该应用程序具有支持的 HR 架构,可支持理论制造商的运营和业务支持系统。

示例 RDBMS 架构。

RDBMS 平台使用即席查询语言 (通常倾向于 SQL) 来生成或具体化规范化数据的视图以支持应用程序层访问模式。

例如,要生成在可发运每个项目的所有仓库的库存中按数量排序的采购订单项目的清单,您可针对上述架构发送以下查询请求:

SELECT * FROM Orders INNER JOIN Order_Items ON Orders.Order_ID = Order_Items.Order_ID INNER JOIN Products ON Products.Product_ID = Order_Items.Product_ID INNER JOIN Inventories ON Products.Product_ID = Inventories.Product_ID ORDER BY Quantity_on_Hand DESC

这种一次性查询提供用于访问数据的灵活的 API,但它们需要大量的处理工作。您必须经常从多个位置查询该数据,而且查询结果必须进行汇编才能进行演示。上述查询跨多个表启动复杂查询,然后对生成的数据进行排序并集成。

可减慢 RDBMS 系统速度的另一个因素是需要支持与 ACID 兼容的事务框架。大多数联机事务处理 (OLTP) 应用程序使用的层次数据结构必须在其存储在 RDBMS 中时跨多个逻辑表进行分解和分布。因此,需要一个与 ACID 兼容的事务框架,以避免在应用程序尝试读取正位于被写入的进程中的对象时可能发生的争用情况。此类事务框架必定会向写入进程增加大量开销。

这两个因素是传统 RDBMS 平台进行扩展的主要障碍。NewSQL 社区是否可以成功提供分布式 RDBMS 解决方案还有待观察。但是,这将解决先前所述的两个限制是不太可能的。无论如何提供该解决方案,规范化和 ACID 事务的处理成本必须还是非常高。

为此,当您的业务需要低延迟响应高流量查询时,利用 NoSQL 系统通常具有技术和经济意义。Amazon DynamoDB 有助于解决限制关系系统可扩展性的问题,方式是避免这些问题。

关系数据库系统出于以下原因无法正常扩展:

  • 它规范化数据并将其存储在需要多个查询以写入磁盘的多个表中。

  • 它通常会产生与 ACID 兼容的事务系统的性能成本。

  • 它使用成本高昂的联接来重组查询结果的所需视图。

DynamoDB 出于以下原因正常扩展:

  • 架构灵活性让 DynamoDB 存储单个项目内的复杂层次数据。

  • 复合键设计让其将相关项目靠近存储在相同表中。

针对数据存储的查询变得简单得多,通常采用以下形式:

SELECT * FROM Table_X WHERE Attribute_Y = "somevalue"

与前面示例中的 RDBMS 相比,DynamoDB 可更为轻松地返回请求的数据。