本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
No design 的主要区别和SQL设计原则
没有像 Amazon Keyspaces 这样的SQL数据库系统使用其他模型进行数据管理，例如键值对或文档存储。当您从关系数据库管理系统切换到像 Amazon Keyspaces 这样的无SQL数据库系统时，了解主要区别和具体的设计方法非常重要。
关系数据设计和 “否” 之间的区别 SQL
关系数据库系统 (RDBMS) 和 No SQL 数据库有不同的优缺点：
-
在中RDBMS，可以灵活地查询数据，但是查询相对昂贵，在高流量情况下无法很好地扩展（参见数据建模最佳实践：设计数据模型的建议）。
-
在诸如 Amazon Keyspaces 之类的 No SQL 数据库中，可以通过有限的多种方式高效查询数据，除此之外，查询可能既昂贵又缓慢。
这些区别使得这两个系统的数据库设计不同：
-
在中RDBMS，您可以灵活地进行设计，而不必担心实现细节或性能。查询优化通常不会影响架构设计，但标准化很重要。
-
在 Amazon Keyspaces 中，对模式进行专门设计，以尽可能地加快最常见和最重要的查询的速度并尽可能降低其成本。根据业务使用案例的具体要求定制数据结构。
No d SQL esign 的两个关键概念
没有哪个SQL设计需要与RDBMS设计不同的思维方式。对于RDBMS，您可以继续创建标准化数据模型，而无需考虑访问模式。以后出现新问题和查询要求后，进行扩展。可以将每种类型的数据整理到各自的表中。
No d SQL esign 有何不同
-
相比之下，在了解需要解答的问题之前，您不应开始设计 Amazon Keyspaces 的模式。事先了解业务问题和应用程序使用案例十分重要。
-
应在 Amazon Keyspaces 应用程序中保留尽可能少的表。使用较少的表可以提高事物的可扩展性、减少权限管理需求以及降低 Amazon Keyspaces 应用程序的开销。此外还可以帮助降低总体备份成本。
接近没有SQL设计
设计 Amazon Keyspaces 应用程序的第一步是确定系统必须满足的具体查询模式。
具体来说，开始前务必了解应用程序访问模式的三个基本属性：
-
数据大小：了解一次存储和请求的数据量将有助于确定对数据进行分区的最有效方法。
-
数据形状：“否” 数据库不是在处理查询时重塑数据（像RDBMS系统那样），而是组织数据，使其在SQL数据库中的形状与将要查询的内容相对应。这是加快速度并增强可扩展性的一个关键因素。
-
数据速度：Amazon Keyspaces 通过增加可用于处理查询的物理分区数量，并在这些分区高效分配数据来进行扩展。事先了解峰值查询负载可能有助于确定数据分区方式，从而最高效地使用 I/O 容量。
确定具体查询要求后，可以根据管理性能的一般原则整理数据：
-
将相关数据放在一起。 对 20 年前的路由表优化研究发现，“参考局部性”是加速响应时间的最重要因素：将相关数据集中放置到一个位置。在当今的 No systems 中也是如此，在这些SQL系统中，将相关数据保存在近距离会对成本和性能产生重大影响。与其将相关数据项分布在多个表中，不如将 No SQL 系统中的相关项目尽可能靠近。
作为一般规则，应在 Amazon Keyspaces 应用程序中保留尽可能少的表。
例外情况是指涉及大量时间序列数据，或数据集具有明显不同访问模式的情况。具有反向索引的单个表通常支持简单查询创建和检索应用程序所需的复杂层次数据结构。
-
使用排序顺序。 如果键设计能够一起排序，可以将相关项目组织在一起，高效查询。这是一项重要的 “无SQL设计” 策略。
-
分发查询。 大量查询不能集中在数据库的某个部分，这样可能超出 I/O 容量，这一点也很重要。应设计数据键，在尽可能多的分区均匀分布流量，从而避免“热点”。
这些一般准则将转化为可用于在 Amazon Keyspaces 中为数据高效建模的一些常见设计模式。
