DynamoDB Index Projeksiyonları: KEYS_ONLY, INCLUDE & ALL

Bir secondary index oluşturduğunda, DynamoDB tüm öğeyi otomatik olarak onun içine kopyalamaz. Neyin kopyalanacağını sen seçersin — index'in projeksiyonu. Çok az seçersen sorguların geri kalanını getirmek için ikinci bir okuma öder; her şeyi seçersen her güncellemede ekstra depolama ve yazma maliyeti ödersin. Bu, index oluşturma sırasında bir kez ayarladığın ve birlikte yaşadığın bir ödünleşimdir.

(Bunu, tek bir okumanın döndürdüğü öznitelikleri kırpan bir projeksiyon ifadesiyle (projection expression) karıştırma. Bu sayfa bir index'in fiziksel olarak neyi sakladığıyla ilgilidir — diğeri için bkz. projeksiyon ifadeleri.)

DynamoDB index projeksiyonu nedir?

Bir projeksiyon, DynamoDB'nin temel tablodan bir secondary index'e kopyaladığı özniteliklerin kümesidir. Üç türden birini seçersin: KEYS_ONLY (yalnızca anahtarlar), INCLUDE (anahtarlar artı adlandırılmış bir öznitelik listesi) veya ALL (öğenin tamamı). Daha fazla projeksiyon, daha az temel-tablo getirme işlemi demektir; ama daha yüksek depolama ve yazma maliyeti getirir.

• Bir projeksiyon, bir secondary index'e kopyalanan özniteliklerin kümesidir.
• KEYS_ONLY — yalnızca tablo ve index anahtarları. En küçük, en ucuz.
• INCLUDE — anahtarlar artı seçtiğin adlandırılmış ekstra öznitelikler listesi.
• ALL — öğenin her özniteliği. En büyük; sorgular asla temel tabloya ihtiyaç duymaz.
• Projekte edilmemiş bir özniteliği okumak, bir GSI için temel tablodan bir getirme işlemini zorlar — sessiz bir ekstra maliyet. (Bir LSI, projekte edilmemiş öznitelikleri senin için getirebilir, ekstra okuma maliyetiyle.)
• Daha fazla projeksiyon = daha fazla depolama + daha fazla yazma maliyeti, çünkü her temel-tablo yazması index'e yayılır.

Sorun: seni iki kez okutan index

Diyelim ki açık biletleri önceliğe göre listelemeni sağlayan bir GSI'li bir destek masası işletiyorsun. Onu hafif tutmak için KEYS_ONLY projekte ediyorsun. Sorgu hızlı döner — ama sana yalnızca bilet ID'lerini verir, oysa kuyruk ekranın her biletin konusuna, atanmış kişisine ve yaşına ihtiyaç duyar.

Yani şimdi kodun, her sonucu doldurmak için temel tabloya karşı ikinci bir okuma turu yapar. Tasarladığın "tek sorgu", aslında bir sorgu artı N getirme işlemidir ve kazanmaya çalıştığın gecikme ile maliyet geri gelir. Projeksiyon, erişim deseni için fazla inceydi.

Her projeksiyon türünün neyi kopyaladığı

• KEYS_ONLY yalnızca temel-tablo anahtarını ve index anahtarını saklar. Sorgu yalnızca hangi öğelerin eşleştiğini bilmesi gerektiğinde ve ayrıntıları başka yerde getireceğinde — ya da hiç getirmeyeceğinde — kullan.
• INCLUDE anahtarları artı adlandırdığın sabit bir öznitelik listesini saklar. En tatlı nokta: sorgunun render etmek için ihtiyaç duyduğu alanları tam olarak projekte et, daha fazlasını değil.
• ALL tüm öğeyi kopyalar. Sorgular index'ten tamamen kendi kendine sunulur, öğenin tüm depolamasını ve yazma kapasitesini index'e kopyalama pahasına.

Destek-masası kuyruğu için, subject, assignee ve age ile INCLUDE doğru tercihtir — kuyruk yalnızca index'ten render edilir, ikinci bir getirme olmadan ve biletin büyük body özniteliğini index'e kopyalamadan.

Takas ettiğin maliyet

Projekte ettiğin her öznitelik ikinci kez saklanır ve temel öğe değiştiğinde index'te yeniden yazılır. Yani sık güncellenen bir tabloda cömert bir ALL projeksiyonu hem depolamayı hem de yazma kapasitesini çarpar. Disiplin şudur: "ne olur ne olmaz diye her şeyi" değil, sorgunun okuduğunu projekte et.

Bilinmeye değer bir incelik: bir sparse index ile, projeksiyon yine yalnızca index anahtarını taşıyan öğeleri tutar — bu yüzden bir sparse index üzerinde INCLUDE/ALL, index'in kendisi küçük olduğu için küçük kalır. Projeksiyonun için depolama ve yazma çarpanını DynamoDB fiyatlandırma hesaplayıcısı ile tart ve index sorgularının kendisini DynamoDB ifade oluşturucusu ile bir araya getir.

DynoTable'da bir projeksiyonu görmek

DynoTable, bir tablonun secondary index'lerinin her birini listeler ve doğrudan biri üzerinden sorgu yapmana izin verir. Aynı erişim desenini temel tabloya ve bir GSI'ye karşı çalıştır ve sonuçları karşılaştır — index sonucunda eksik olan öznitelikler, tam olarak onun projekte etmediği özniteliklerdir, böylece bir projeksiyonun etkisi tablo tanımını yeniden okumadan görünür.

Tuzaklar ve sonraki adımlar

• Bir GSI'de projekte edilmemiş bir öznitelik, bir temel-tablo getirme işlemi demektir — projeksiyonu, sorgunun render ettiği şeyin etrafında tasarla.
• ALL nadiren bedavadır — depolama ve yazma maliyetini kopyalar; index'in gerçekten her alana ihtiyacı yoksa varsayılan olarak INCLUDE kullan.
• Projeksiyonlar çoğunlukla sabittir. Bir GSI'nin projeksiyonunu daha sonra index'i yeniden oluşturmadan serbestçe düzenleyemezsin — baştan bilinçli seç.
• İlgili: GSI ve LSI ve sparse index'ler, bir projeksiyonun gerçekte ne kadar sakladığını şekillendirir.

Tablolarını yeniden tasarlamadan önce her bir index'inin gerçekte ne döndürdüğünü görmek mi istiyorsun? DynoTable'ı indir ve tablolarını doğrudan sorgula.