本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 資料建模最佳實務：設計資料模型的建議
<a name="data-modeling"></a>

使用 Amazon Keyspaces （適用於 Apache Cassandra) 時，有效的資料建模對於最佳化效能和降低成本至關重要。本主題涵蓋設計適合您應用程式資料存取模式之資料模型的重要考量和建議。
+ **分割區索引鍵設計 ** – 分割區索引鍵在判斷資料如何在 Amazon Keyspaces 中的分割區之間分佈時扮演重要角色。選擇適當的分割區索引鍵可能會大幅影響查詢效能和輸送量成本。本節討論設計分割區索引鍵的策略，以促進跨分割區均勻分佈讀取和寫入活動。
+ **重要考量事項：**
  + **統一活動分佈** – 旨在統一所有分割區的讀取和寫入活動，以將輸送量成本降至最低，並有效利用高載容量。
  + **存取模式** – 將您的分割區金鑰設計與應用程式的主要資料存取模式保持一致。
  + **分割區大小** – 避免建立過大的分割區，因為這可能會影響效能並增加成本。

若要更輕鬆地視覺化和設計資料模型，您可以使用 [NoSQL Workbench](workbench.md)。

**Topics**
+ [如何在 Amazon Keyspaces 中有效使用分割區金鑰](bp-partition-key-design.md)

# 如何在 Amazon Keyspaces 中有效使用分割區金鑰
<a name="bp-partition-key-design"></a>

可唯一識別 Amazon Keyspaces 資料表中每一列的主索引鍵可以包含一或多個分割區索引鍵資料欄，這些索引鍵欄決定要存放資料的分割區，以及一或多個選用的叢集資料欄，定義如何在分割區中叢集和排序資料。

由於分割區索引鍵會建立資料存放於 中的分割區數量，以及資料在這些分割區間的分佈方式，因此您選擇分割區索引鍵的方式可能會對查詢的效能產生重大影響。一般而言，您應該針對磁碟上所有分割區的統一活動來設計應用程式。

將應用程式的讀取和寫入活動平均分散到所有分割區，有助於將輸送量成本降至最低，這適用於隨需和佈建的讀取/寫入容量模式。例如，如果您使用的是佈建容量模式，您可以判斷應用程式所需的存取模式，並預估每個資料表所需的總讀取容量單位 (RCU) 和寫入容量單位 (WCU)。只要針對特定分割區的流量不超過 3，000 RCUs 和 1，000 個 WCUs，Amazon Keyspaces 就會使用您佈建的輸送量來支援您的存取模式。

當分割區經歷持續的高讀取或寫入輸送量時，根據流量模式，Amazon Keyspaces 可能會自動將分割區分割成兩個新的分割區。每個新分割區都包含原始分割區列的子集，將輸送量平均分散到兩個分割區。

Amazon Keyspaces 透過提供高載容量，為您的每個分割區輸送量佈建提供額外的彈性，如需詳細資訊，請參閱 [在 Amazon Keyspaces 中有效使用高載容量](throughput-bursting.md)。

**Topics**
+ [使用寫入碎片跨分割區平均分配工作負載](bp-partition-key-sharding.md)

# 使用寫入碎片跨分割區平均分配工作負載
<a name="bp-partition-key-sharding"></a>

在 Amazon Keyspaces 中跨分割區更好地分配寫入的一個方法是擴展空間。您可以數種不同的方式來執行此動作：您可以新增額外的分割區索引鍵資料欄，您可以將隨機數字寫入其中，以在分割區之間分配資料列。或者，您可以使用根據您查詢內容計算的數字。

## 使用複合分割區索引鍵和隨機值的碎片
<a name="bp-partition-key-sharding-random"></a>

跨分割區更平均地分配負載的一個策略是新增一個額外的分割區索引鍵資料欄，您可以將其寫入隨機數字。如此您就能在較大的空間中將寫入隨機化。

例如，請考慮下表，其具有代表日期的單一分割區索引鍵。

```
CREATE TABLE IF NOT EXISTS tracker.blogs (
   publish_date date,
   title text,
   description int,
   PRIMARY KEY (publish_date));
```

若要跨分割區更平均地分配此資料表，您可以包含存放`shard`隨機數字的額外分割區索引鍵資料欄。例如：

```
CREATE TABLE IF NOT EXISTS tracker.blogs (
   publish_date date, 
   shard int, 
   title text, 
   description int, 
   PRIMARY KEY ((publish_date, shard)));
```

插入資料時，您可以在 `1`和 之間`200`為資料`shard`欄選擇隨機數字。這會透過 產生複合分割區索引鍵值，例如 `(2020-07-09, 1)`、 `(2020-07-09, 2)`等`(2020-07-09, 200)`。因為您隨機化了分割區索引鍵，每天對資料表的寫入會平均分配在多個分割區中。這可帶來更優良的平行處理與更高的整體輸送量。

不過，若要讀取指定日期的所有資料列，您必須查詢所有碎片的資料列，然後合併結果。例如，您會先發出分割區索引鍵值 的`SELECT`陳述式`(2020-07-09, 1)`。然後`(2020-07-09, 2)`，透過 為 發出另一個`SELECT`陳述式，以此類推`(2020-07-09, 200)`。最後，您的應用程式必須合併所有這些`SELECT`陳述式的結果。

## 使用複合分割區索引鍵和計算值的碎片
<a name="bp-partition-key-sharding-calculated"></a>

隨機化的策略可大幅改善寫入輸送量。但是，讀取特定資料列並不容易，因為您不知道在資料列寫入時將哪個值寫入資料`shard`欄。若要更輕鬆地讀取個別資料列，您可以使用不同的策略。不是使用隨機數字在分割區之間分配資料列，而是使用您可以根據要查詢的內容計算的數字。

考量先前的範例，其中資料表會使用分割區索引鍵中的今天日期。現在假設每一列都有可存取的資料`title`欄，而且除了日期之外，您通常還需要依標題尋找資料列。在應用程式將資料列寫入資料表之前，它可以根據標題計算雜湊值，並使用它來填入資料`shard`欄。計算應會產生介於 1 到 200 之間的數字，此分佈非常平均，與隨機策略產生的結果相當類似。

簡單計算可能就足夠了，例如標題模數 200、\$1 1 中字元的 UTF-8 程式碼點值乘積。然後，複合分割區索引鍵值會是日期和計算結果的組合。

有了這項策略，即可在分割區索引鍵值之間，以及實體分割區之間平均分配寫入。您可以輕鬆為特定資料列和日期執行`SELECT`陳述式，因為您可以計算特定值的分割區索引鍵`title`值。

若要讀取指定日期的所有資料列，您仍然必須`SELECT`每個`(2020-07-09, N)`金鑰 （其中 `N`為 1–200)，然後您的應用程式必須合併所有結果。好處是您能避免讓單一「經常性」分割區索引鍵值承受所有工作負載。