Amazon Keyspace NoSQL

• 在 RDBMS 中，可以灵活查询数据，但查询成本相对较高，不能很好地扩展适应高流量情况（参见 在亚马逊 Keyspaces 中制定数据建模（适用于 Apache Cassandra））。

• 在 Amazon Keyspaces 等 NoSQL 数据库中，可以通过有限的几种方式高效查询数据，而在这些方法之外，查询过程归根到底是一个练习的过程，即在有限的情况下，查询过程归根到底是一个练习的过程。

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

• 在 Amazon Keyspaces 中，您可以专门设计架构的过程，即在尽可能靠近使用容量、低廉的情况下，让最常见和最重要的查询变得尽可能靠近使用和最重要的查询。根据业务使用案例的具体要求定制数据结构。

NoSQL 设计的不同之处

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

• 在 Amazon Keyspaces (for Keyspaces) 中维护尽可能少表。表数量减少过程归根到底是一个练习的过程，即在使用上 Amazon Keyspaces 的情况下，让预置更靠近使用容量，让预置变得更靠近使用容量，此外还可以帮助降低总体备份成本。

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

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

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

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

  而在 Amazon Keyspaces 应用程序中，应先了解需要解决的问题，再开始处理的问题。

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

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

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