設計分割區索引鍵以分配您的工作負載

資料表主索引鍵的分割區索引鍵部分，決定了已儲存資料表資料的邏輯分割區。因此會影響底層的實體分割區。不能有效分配 I/O 請求的分割區索引鍵設計可能會造成「經常性」分割區，因此導致限流並且無法有效地使用已佈建的 I/O 容量。

資料表已佈建傳輸量的最佳使用情況，不僅取決於各個項目的工作負載模式，還取決於分割區索引鍵設計。這並不表示您必須存取所有分割區索引鍵值才能達到有效率的傳輸量層級，也不表示所存取之分割區索引鍵值的百分比必須很高。這表示您的工作負載存取的分割區索引鍵值越獨特，這些請求將越多地分佈在已分割區空間中。一般而言，隨著所存取的分割區索引鍵值與分割區索引鍵值總數的比率成長，您會更有效率地利用已佈建的傳輸量。

以下是一些常用分割區索引鍵結構描述的已佈建傳輸量效率比較。

分割區索引鍵值	一致性
使用者 ID，其中應用程式有許多使用者。	好
狀態碼，其中只有一些可能的狀態碼。	不好
項目建立日期，捨入到最接近的時間週期 (例如日期、小時、分鐘)。	不好
裝置 ID，其中每部裝置會依相當類似的間隔存取資料.	好
裝置 ID，其中即使追蹤多個裝置，其中一部裝置也會明顯比其他所有裝置更熱門。	不好

如果單一資料表只有少量的分割區索引鍵值，請考慮在更多相異分割區索引鍵值之間分佈您的寫入操作。換句話說，請結構化主索引鍵元素，以避免某個「經常性」(高度請求) 的分割區索引鍵值使整體效能變慢。

例如，請考慮使用具有複合主索引鍵的資料表。分割區索引鍵代表項目的建立日期，已捨入到最接近的日期。排序索引鍵是項目識別符。在指定的日期 (假設是2014-07-09)，所有新項目都會寫入單一分割區索引鍵值 (和對應的實體分割區)。

如果資料表完全符合單一分割區 (考慮到資料會隨時間成長)，而且您應用程式的讀取與寫入輸送量需求不超過單一分割區的讀取與寫入能力，則您的應用程式應不會遇到由於分割所造成的非預期調節。

若要使用適用於 DynamoDB 的 NoSQL Workbench 來協助視覺化您的分割區索引鍵設計，請參閱 使用 NoSQL Workbench 建立資料模型。