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