DynamoDB 中次要索引的一般準則

Amazon DynamoDB 支援兩種次要索引：

• 全域次要索引 (GSI)：是包含分割區索引鍵或排序索引鍵的索引，這些索引鍵可與基底資料表上的索引鍵不同。全域次要索引之所以視為全域，是因為索引上的查詢可以跨越所有分割區之間基礎資料表中的所有資料。全域次要索引沒有大小限制，也有自己的讀取和寫入活動佈建輸送量設定，而且這些設定與資料表的佈建輸送量設定無關。

• 本機次要索引 (LSI)：與基底資料表擁有相同分區索引鍵但不同排序索引鍵的索引。本機次要索引的「本機」概念是指，本機次要索引的每個分割區都會列入基礎資料表分割區的範圍，其中分割區索引鍵的值皆相同。因此，針對每個分割區索引鍵值，所有已索引項目的大小總計不得超過 10 GB。此外，本機次要索引與其建立索引的資料表共用適用於讀取和寫入活動的佈建輸送量設定。

DynamoDB 中的每個資料表最多可以有 20 個全域次要索引 (預設配額) 以及 5 個本機次要索引。

全域次要索引通常比本機次要索引更實用。決定要使用的索引類型也將取決於應用程式的需求。如需全域次要索引與本機次要索引的比較，以及如何在它們之間進行選擇的詳細資訊，請參閱使用次要索引來改善資料存取。

以下是在 DynamoDB 中建立索引時需要謹記在心的一些常見原則與設計模式：

有效率地使用索引

將索引數量降到最低。請不要在您不常查詢的屬性上建立次要索引。不常使用的索引不僅會增加儲存體和 I/O 成本，而不會改善應用程式的效能。

謹慎選擇投影

由於次要索引會使用儲存體和佈建輸送量，建議您將索引的大小維持得越小越好。此外，相較於查詢完整資料表，索引的大小越小所能帶來的效能優勢越大。若您的查詢通常只會傳回一小部分的屬性，且這些屬性的總大小遠小於整個項目的大小，建議您只投影會定期請求的屬性。

相較於讀取，若您預期資料表上將會有許多寫入活動，遵循這些最佳實務：

• 考慮投影少量的屬性，以將寫入到索引的項目大小減至最小。但是，此作法僅適用於若投影屬性大小大於單一寫入容量單位 (1 KB)。例如，若一個索引項目的大小只有 200 位元組，DynamoDB 會將此大小向上四捨五入為 1 KB。換句話說，只要索引項目很小，您便可以投影更多屬性，而無須支付額外的成本。

• 避免投影您已知在查詢中很少會需要用到的屬性。每次您更新在索引中投影的屬性後，更新索引也不會產生額外的成本。您仍可以更高佈建傳輸量成本在 Query 中擷取非投影屬性，但查詢成本可能會比經常更新索引的成本少很多。

• 只有在您希望查詢傳回不同排序索引鍵排序的整個資料表項目，才指定 ALL。為所有屬性建立投影之後便不再需要擷取資料表，但在大多數的案例中，這樣會讓您的儲存體和寫入活動成本加倍。

如下一區段所述，平衡盡可能將索引大小降到最低的需求來達成將擷取減到最低的需求。

最佳化頻繁查詢，避免擷取

若要在延遲盡可能最低的前提下取得最快速的查詢，請投影所有您預期該查詢要傳回的屬性。特別是，如果您對未投影的屬性查詢本機次要索引，DynamoDB 會自動從需要在資料表讀取整個項目的資料表擷取那些屬性。此引發的延遲與其他 I/O 操作是可以避免的。

請謹記「偶爾」的查詢可能經常是「必要」的查詢。若因為您預計偶爾才會查詢某些屬性，而不打算投影，請考慮可能的結果，否則您可能會後悔沒有投影那些屬性。

如需資料表擷取的詳細資訊，請參閱 本機次要索引的佈建輸送量考量。

在建立本機次要索引時請留意項目集合大小限制

項目集合是資料表和其本機次要索引中所有具有相同分割區索引鍵的項目。由於項目集合的大小不可超過 10 GB，可能會耗盡特定分割區索引鍵值的空間。

當您新增或更新資料表項目時，DynamoDB 會更新任何受到影響的本機次要索引。若建立索引的屬性已在資料表中定義，本機次要索引便會一同成長。

當您建立本機次要索引時，建議您思考會有多少資料寫入索引，以及那些資料項目中有多少具有相同的分割區索引鍵。若您預期具有特定分割區索引鍵值的資料表和索引項目總和可能會超過 10 GB，請考慮是否要避免建立索引。

若您無法避免建立本機次要索引，您必須預計項目集合的大小上限，並在超過之前採取動作。最佳作法是，在撰寫項目時，您應該利用ReturnItemCollectionMetrics參數來監視和警示接近 10GB 大小限制的項目集合大小。超過最大項目集合大小將導致寫入嘗試失敗。您可以在項目收集大小影響您的應用程式之前監視和警示項目集合大小，以減輕項目集合大小問題。

注意

建立之後，您就無法刪除本機次要索引。

如需取得在限制內操作及採取正確動作的策略，請參閱「項目集合大小限制」。