适用于 Amazon Keyspaces 的 NoSQL 设计

• 在 RDBMS 中，可以灵活查询数据，但查询成本相对较高，不能很好地扩展适应高流量情况（参见 Amazon Keyspaces（Apache Cassandra 兼容）中的数据建模）。

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

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

• 在 Amazon Keyspaces 中，对模式进行专门设计，以尽可能地加快最常见和最重要的查询的速度并尽可能降低其成本。根据业务使用案例的具体要求定制数据结构。

NoSQL 设计的不同之处

• 相比之下，在了解需要解答的问题之前，您不应开始设计 Amazon Keyspaces 的模式。事先了解业务问题和应用程序使用案例十分重要。

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

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

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

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

• 将相关数据放在一起。   对 20 年前的路由表优化研究发现，“参考局部性”是加速响应时间的最重要因素：将相关数据集中放置到一个位置。这一点对于今天的 NoSQL 系统同样成立，将相关数据保留在最接近的位置，将对成本和性能产生重大影响。不应在多个表分布相关数据项目，而应保持 NoSQL 系统中的相关项目尽可能靠近。

  作为一般规则，应在 Amazon Keyspaces 应用程序中保留尽可能少的表。

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

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

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