Genel İkincil Dizinler ve Yerel İkincil Dizinler

DynamoDB'nin birincil anahtarı, bir tablo üzerindeki tek verimli sorgu yolunu tanımlar. Verileri farklı bir özniteliğe göre sorgulamanız gerekiyorsa; örneğin tablonun bölüm anahtarı CustomerId iken bir ürün kimliğine ait tüm siparişleri bulmak istiyorsanız, ikincil bir dizin olmadan maliyetli bir Scan gerçekleştirmeniz gerekir.

İkincil dizinler, verilerin farklı bir anahtar etrafında yapılandırılmış, ayrı ve otomatik olarak güncellenen bir kopyasını tutarak bu sorunu çözer. DynamoDB iki tür sunar: Global Secondary Indexes (GSI) ve Local Secondary Indexes (LSI). Bu türlerin ödünleşimleri birbirinden farklıdır.

Global Secondary Index, temel tablodakinden tamamen farklı bir bölüm anahtarı (ve isteğe bağlı olarak bir sıralama anahtarı) tanımlamanıza olanak tanır. GSI gerçekten geneldir; temel tablonun tüm bölümlerini kapsar. GSI bölüm anahtarı olarak tanımladığınız herhangi bir özniteliğe göre öğeleri bulmak için GSI üzerinde sorgu çalıştırabilirsiniz.

GSI'lerin temel tablodan bağımsız kendi sağlanan iş hacimleri vardır (veya isteğe bağlı modu devralırlar). Her tablo için en fazla 20 GSI oluşturabilir ve mevcut bir tabloya istediğiniz zaman GSI ekleyebilir veya silebilirsiniz.

Local Secondary Index, temel tabloyla aynı bölüm anahtarını paylaşır ancak farklı bir sıralama anahtarı kullanır. LSI'ler 'yerel'dir; çünkü yalnızca tek bir bölüm içinde, yani aynı bölüm anahtarına sahip öğeler arasında sorgulama yaparlar. Bu nedenle LSI'ler, belirli bir müşterinin siparişlerini farklı özniteliklere göre sıralayarak sorgulamak için idealdir.

LSI'ler tablo oluşturulurken tanımlanmalıdır; sonradan eklenemez veya kaldırılamazlar. Her tabloda en fazla 5 LSI bulunabilir. LSI'ler temel tablonun sağlanan kapasitesini paylaşır (ayrı iş hacimleri yoktur) ve temel tablo ile LSI verilerinin birleşimi için bölüm anahtarı başına 10 GB depolama sınırına tabidir.

Sınavı daha iyi anlamanız için yan yana bir karşılaştırma aşağıda verilmiştir:

• Partition key: GSI, temel tablodakinden farklı olabilir; LSI, temel tablodakiyle aynı olmalıdır
• Sort key: her ikisi de temel tablodakinden farklı bir sıralama anahtarını destekler
• Oluşturulma zamanı: GSI herhangi bir zamanda; LSI yalnızca tablo oluşturulurken oluşturulabilir
• Kapasite: GSI'ın kendine ait kapasitesi vardır; LSI, temel tablonun kapasitesini paylaşır
• Tutarlılık: GSI okumaları yalnızca nihai olarak tutarlıdır; LSI okumaları güçlü tutarlılığa sahip olabilir
• Sınırlar: en fazla 20 GSI; tablo başına en fazla 5 LSI

Bir dizin oluştururken, hangi özniteliklerin dizine yansıtılacağını (kopyalanacağını) seçersiniz:

• KEYS_ONLY: yalnızca temel tablonun birincil anahtarı ve dizin anahtarı—en küçük dizindir; anahtar olmayan öznitelikler için ek GetItem çağrıları gerekir
• INCLUDE: anahtar özniteliklerine ek olarak belirttiğiniz belirli özniteliklerin listesi—boyut ile erişim düzeni arasında denge sağlar
• ALL: tüm öznitelikler dizine yansıtılır—en esnek seçenektir, ancak depolama ve yazma maliyeti daha yüksektir

Yansıtma türünü, sorgularınızın gerçekte ihtiyaç duyduğu özniteliklere göre seçin. Gereğinden fazla öznitelik yansıtmak her yazma işleminde WCU'ları boşa harcar; gereğinden az öznitelik yansıtmak ise dizinde bulunmayan öznitelikleri almak için ek GetItem çağrılarını zorunlu kılar.

GSI ile sorgulama, aynı Query API'sini kullanır; ancak --index-name parametresini belirtir. Sorgu, temel tablonun anahtar şeması yerine GSI'ın anahtar şemasına karşı çalışır. GSI sorguları her zaman nihai olarak tutarlıdır—GSI, temel tabloya yapılan yazma işlemlerinden sonra eşzamansız olarak güncellendiği için kısa bir gecikme yaşanır.

Temel tablodaki bir öğede GSI'ın bölümleme anahtarı özniteliği yoksa bu öğe GSI'a hiç dahil edilmez (seyrek dizin modeli). Bu, yalnızca öğelerin bir alt kümesini dizine almak için güçlü bir tekniktir; örneğin GSI bölümleme anahtarı Status ise durumu PENDING olan tüm siparişleri dizine alabilirsiniz.

Seyrek dizin, DynamoDB'nin öğeleri yalnızca GSI'ın bölümleme anahtarı için bir değere sahip olmaları durumunda GSI'a yansıtması özelliğinden yararlanır. GSI bölümleme anahtarını yalnızca bazı öğelerin sahip olduğu bir öznitelik olarak tanımlayarak yalnızca bu alt kümeden oluşan bir dizin oluşturursunuz.

Örnek: bir Orders tablosunda yalnızca gönderilmemiş siparişlerde PendingShipmentDate özniteliği bulunur. PendingShipmentDate üzerinde oluşturulan bir GSI doğal olarak yalnızca gönderilmemiş siparişleri içerir; böylece tüm bekleyen siparişleri tablonun tamamını taramadan sorgulamak için son derece verimli bir yöntem sağlar.

GSI aşırı yüklemesi, farklı varlık türlerini tek bir tabloda depoladığınız ve genel bir GSI anahtarı özniteliğini (ör. GSI1PK ve GSI1SK) öğe türüne göre farklı düzenlerle doldurduğunuz gelişmiş bir tek tablo tasarımı tekniğidir. Bu sayede her varlık türü, tek bir GSI üzerinden kendine ait verimli bir sorgu yoluna sahip olur.

Örnek: User öğeleri için GSI1PK = 'COUNTRY#US' ve GSI1SK = username değerlerini ayarlayın; Order öğeleri için GSI1PK = 'STATUS#PENDING' ve GSI1SK = orderDate değerlerini ayarlayın. GSI'ı uygun ön ekle sorgulamak, hedef varlık türünü verimli şekilde getirir.

GSI kısıtlaması, temel tablodan bağımsız olarak gerçekleşir. GSI'ın sağlanan WCU'ları çok düşükse GSI'a yansıtılan öğelere yapılan yazma işlemleri kısıtlanır—even temel tabloda yeterli kapasite olsa bile. Her GSI için ConsumedWriteCapacityUnits ve ThrottledRequests değerlerini ayrı ayrı izleyin.

Yaygın bir hata, GSI için temel tablodan daha düşük kapasite sağlamak ve ardından yazma düzeni GSI yazma hızını aniden artırdığında kısıtlamayla karşılaşmaktır. Bunu önlemek için GSI'larda Otomatik Ölçeklendirme kullanın veya İhtiyaca Göre modunu seçin.

SAA-C03 sınavı için karar verme yönergeleri:

• Tamamen farklı bir özniteliğe göre sorgulama yapmanız gerekiyorsa → GSI
• Aynı bölüm içinde, ancak farklı bir sıralamayla sorgulama yapmanız gerekiyorsa ve bunu oluşturma sırasında biliyorsanız → LSI
• Alternatif bir sıralama anahtarında güçlü tutarlılığa sahip okumalar gerekiyorsa → LSI (GSI'lar nihai olarak tutarlı olduğu için tek seçenek)
• On veya daha fazla farklı sorgu düzeniniz varsa → çok sayıda ayrı tablo yerine GSI aşırı yüklemeli tek tablo tasarımını değerlendirin
• Yalnızca analiz için tüm öğeleri almanız gerekiyorsa → DynamoDB'nin doğru veritabanı olup olmadığını yeniden değerlendirin

Temel tabloyu etkilemeden bir GSI'ı istediğiniz zaman silebilirsiniz. Mevcut bir tabloya yeni bir GSI eklediğinizde DynamoDB, temel tabloyu tarayarak dizini eşzamansız biçimde geriden doldurur—büyük tablolarda bu işlem dakikalardan saatlere kadar sürebilir. Geriden doldurma sırasında temel tablo okuma ve yazma işlemleri için tamamen kullanılabilir durumda kalır.

Geriden doldurma ilerlemesini konsoldan veya dizinin IndexStatus alanını kontrol ederek DescribeTable API'si aracılığıyla izleyebilirsiniz—geriden doldurma sırasında CREATING, tamamlandığında ise ACTIVE olur. ACTIVE durumuna gelene kadar GSI'ı sorgulamayın.

Bu derste AWS Solutions Architect (SAA-C03) kavramlarını ne kadar anladığınızı test edin.

Bu derste şunları öğrendiniz: GSI'lar alternatif bölümleme anahtarları sağlar ve her zaman eklenebilir, LSI'lar temel bölümleme anahtarını paylaşır ve oluşturma sırasında tanımlanmalıdır ve yansıtma türleri hangi özniteliklerin dizine kopyalanacağını belirler. GSI'lar, gelişmiş sorgu esnekliği için seyrek dizin ve aşırı yükleme modellerini destekler. Sırada DynamoDB Streams ve Global Tables konularını inceleyeceğiz.