适用于 DynamoDB 的 NoSQL 设计

• 在 RDBMS 中，可以灵活查询数据，但查询成本相对较高，不能很好地扩展适应高流量情况（参见 在 DynamoDB 中为关系数据建模的初始步骤）。

• 在 NoSQL 数据库（如 DynamoDB）中，高效查询数据的方式有限，此外查询成本高且速度慢。

• 在 RDBMS 中，针对灵活性设计，不必担心实现细节或性能。查询优化通常不会影响架构设计，但标准化很重要。

• 在 DynamoDB 中，对架构进行专门设计，尽可能快速低成本实现最常见和最重要的查询。根据业务使用案例的具体要求定制数据结构。

NoSQL 设计的不同之处

• 相比之下，应该先了解需要解答的问题，然后再开始设计 DynamoDB 架构。事先了解业务问题和应用程序使用案例十分重要。

• 应在 DynamoDB 应用程序中保留尽可能少的表。使用较少的表可以提高事物的可扩展性，减少权限管理需求，并降低 DynamoDB 应用程序的开销。此外还可以帮助降低总体备份成本。

• 数据大小：了解一次存储和请求的数据量将有助于确定对数据进行分区的最有效方法。

• 数据形状：NoSQL 数据库处理查询时不会改变数据形状（RDBMS 系统会这样做），而是整理数据，使数据库中的数据形状与查询内容对应。这是加快速度并增强可扩展性的一个关键因素。

• 数据速度：DynamoDB 通过增加可用于处理查询的物理分区数量，并在这些分区高效分布数据来进行扩展。事先了解峰值查询负载可能有助于确定数据分区方式，从而最高效地使用 I/O 容量。

• 将相关数据放在一起。   研究表明，将相关数据保存在一个地方的“引用局部性”原则是提高 NoSQL 系统性能和缩短响应时间的关键因素，就像许多年前人们发现它对优化路由表很重要一样。

  通常应在 DynamoDB 应用程序中保留尽可能少的表。

  例外情况是指涉及大量时间序列数据，或数据集具有明显不同访问模式的情况。具有反向索引的单个表通常支持简单查询创建和检索应用程序所需的复杂层次数据结构。

• 使用排序顺序。   如果键设计能够一起排序，可以将相关项目组织在一起，高效查询。这是一个重要的 NoSQL 设计策略。

• 分发查询。   大量查询不能集中在数据库的某个部分，这样可能超出 I/O 容量，这一点也很重要。应设计数据键，在尽可能多的分区均匀分布流量，从而避免“热点”。

• 使用全局二级索引。   通过创建特定全局二级索引，可以实现与主表支持的查询不同的查询，并且仍然快速，成本低。