本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# NoSQL 設計的主要差異和設計原則
Amazon Keyspaces 等 NoSQL 資料庫系統使用替代模型進行資料管理，例如鍵/值對或文件儲存。當您從關聯式資料庫管理系統切換到 Amazon Keyspaces 等 NoSQL 資料庫系統時，請務必了解主要差異和特定設計方法。
**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))。
+ 在 Amazon Keyspaces 等 NoSQL 資料庫中，可以透過有限數量的方式有效率地查詢資料，在其中查詢可能昂貴且緩慢。
這些差異導致兩種系統之間的資料庫設計不同：
+ 在 RDBMS 中，您會針對靈活性而進行設計，而不需擔心實行詳細資訊或效能。查詢最佳化通常不會影響結構描述設計，但標準化相當重要。
+ 在 Amazon Keyspaces 中，您可以專門設計結構描述，讓最常見和重要的查詢盡可能快速且經濟實惠。系統會打造您的資料結構，以符合企業使用案例的特定要求。
## NoSQL 設計的兩個主要概念
NoSQL 設計思維與 RDBMS 設計不同。針對 RDBMS，您可以直接建立標準化的資料模型，而不需考量存取模式。您可以在稍後有新問題與查詢要求時擴展此模型。您可以將每種資料整理至其資料表。
**NoSQL 設計的不同之處**
+ 相反地，在您知道需要回答的問題之前，您不應該開始設計 Amazon Keyspaces 的結構描述。必須事先了解企業問題和應用程式使用案例。
+ 您應該在 Amazon Keyspaces 應用程式中盡可能維持最少的資料表。擁有較少的資料表可讓物件更具可擴展性、需要較少的許可管理，並減少 Amazon Keyspaces 應用程式的額外負荷。它還可以幫助降低整體備份成本。
## NoSQL 設計方法
*設計 Amazon Keyspaces 應用程式的第一步是識別系統必須滿足的特定查詢模式。*
特別是，請務必了解應用程式存取模式的三種基本屬性，再開始進行：
+ **資料大小**：了解一次要儲存和請求的資料量，有助於判斷分割資料的最有效方式。
+ **資料形狀**：NoSQL 資料庫會組織資料，而非在資料處理時重新改造資料 (如 RDBMS 系統)，如此其在資料庫中的狀態就會與將受到查詢的項目相對應。此為提升速度與可擴展性的關鍵因素。
+ **資料速度**：Amazon Keyspaces 透過增加可用於處理查詢的實體分割區數量，以及有效率地將資料分散到這些分割區來擴展。事先了解尖峰查詢負載，將可能有助於判斷如何分割資料以有效使用輸入/輸出容量。
在您識別特定查詢要求後，您可以根據管理效能的一般原則來組織資料：
+ **將相關的資料保持在一起。** 20 年前針對路由表最佳化的研究發現，「參照本地性」是提升回應時間的最重要的單一因素，也就是將相關資料放在同一個位置。這在 NoSQL 系統也同樣適用，將相關資料保持在鄰近位置對成本與效能有重大影響。您應盡可能將 NoSQL 系統中的相關項目放置在靠近的位置，而非在多個資料表之間分配相關的資料項目。
一般而言，您應該在 Amazon Keyspaces 應用程式中盡可能維持最少的資料表。
例外狀況包含大量時間序列資料涉及其中的案例，或存取模式極為不同的資料集。含反轉索引的單一資料表通常可以啟用簡單查詢，來建立並擷取您應用程式所需的複雜階層資料結構。
+ **使用排序。** 若相關項目的索引鍵設計為能一起排序，則可以一起分組，以更有效地進行查詢。此為重要的 NoSQL 設計策略。
+ **發布佇列。** 亦請注意不要針對資料庫的一部分集中進行大量查詢 (這會超過輸入/輸出容量)。而您應盡可能將資料索引鍵平均分配到這些分割區，避免「熱點」。
這些一般原則會轉換為一些常見的設計模式，您可以用來在 Amazon Keyspaces 中有效率地建立資料模型。