Orta6 dakikalık okuma

DynamoDB Dizin Projeksiyonları

Bir ikincil dizin oluşturduğunuzda, DynamoDB tüm item'ı otomatik olarak ona kopyalamaz. Neyin kopyalanacağını sen seçersiniz — dizinin projeksiyonunu. Çok az seçin, sorgularınız geri kalanı getirmek için ikinci bir okuma öder; her şeyi seçin, her güncellemede ekstra depolama ve yazma maliyeti ödersiniz. Bu, dizin oluşturmada bir kez ayarlayıp birlikte yaşadığınız bir takastır.

(Bunu, tek bir okumanın döndürdüğü attribute'ları kırpan bir projeksiyon ifadesiyle karıştırmayın. Bu sayfa bir dizinin fiziksel olarak neyi depoladığıyla ilgilidir — diğeri için bkz. projeksiyon ifadeleri.)

DynamoDB dizin projeksiyonu nedir?

Bir projeksiyon, DynamoDB'nin temel tablodan bir ikincil dizine kopyaladığı attribute'lar kümesidir. Üç türden birini seçersiniz: KEYS_ONLY (yalnızca anahtarlar), INCLUDE (anahtarlar artı adlandırılmış bir attribute listesi) ya da ALL (tüm item). Daha fazla projeksiyon, daha az temel tablo getirme ama daha yüksek depolama ve yazma maliyeti demektir.

  • Bir projeksiyon, bir ikincil dizine kopyalanan attribute'lar kümesidir.
  • KEYS_ONLY — yalnızca tablo ve dizin anahtarları. En küçük, en ucuz.
  • INCLUDE — anahtarlar artı seçtiğiniz adlandırılmış bir ekstra attribute listesi.
  • ALL — item'ın her attribute'u. En büyük; sorguların asla temel tabloya ihtiyacı olmaz.
  • Projeksiyonlanmamış bir attribute, bir GSI'den basitçe erişilemezdir — uygulamanız kendi temel tablo okumalarını yayınlamalıdır. (Yalnızca bir LSI, ekstra okuma maliyetiyle projeksiyonlanmamış attribute'ları senin için getirir.)
  • Daha fazla projeksiyon = daha fazla depolama + daha fazla yazma maliyeti, çünkü her temel tablo yazması dizine yayılır.

Sorun: sizi iki kez okutan dizin

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

Bu yüzden artık kodunuz her sonucu doldurmak için temel tabloya karşı ikinci bir okuma turu yapar. Tasarladığınız "tek sorgu" aslında bir sorgu artı N get'tir ve tasarruf etmeye çalıştığınız gecikme ve maliyet geri gelir. Projeksiyon, erişim deseni için fazla inceydi.

Her projeksiyon türü neyi kopyalar

Temel öğe: anahtarlar + subject +assignee + age + bodyKEYS_ONLY: yalnızca anahtarlarINCLUDE: anahtarlar + subject,assignee, ageALL: her öznitelik
  • KEYS_ONLY yalnızca temel tablo anahtarını ve dizin anahtarını depolar. Sorgunun yalnızca hangi item'ların eşleştiğini bilmesi gerektiğinde ve ayrıntıları başka bir yerden getireceğinizde — ya da hiç getirmeyeceğinizde — kullanın.
  • INCLUDE anahtarları artı adlandırdığınız sabit bir attribute listesini depolar. Tam nokta: sorgunuzun render etmek için ihtiyaç duyduğu tam alanları projeksiyonlayın, daha fazlasını değil.
  • ALL tüm item'ı kopyalar. Sorgular, item'ın tüm depolama ve yazma verimliliğini ona kopyalama pahasına, dizinden tamamen kendi kendine sunulur.

Destek masası kuyruğu için subject, assignee ve age ile INCLUDE doğru seçimdir — kuyruk yalnızca dizinden render edilir, ikinci bir getirme olmadan ve biletin büyük body'sini dizine kopyalamadan.

Takas ettiğiniz maliyet

Projeksiyonladığınız her attribute ikinci kez depolanır ve temel item her değiştiğinde dizinde yeniden yazılır. Bu yüzden sık güncellenen bir tabloda cömert bir ALL projeksiyonu hem depolamayı hem de yazma kapasitesini çarpar. Disiplin şudur: sorgunun okuduğunu projeksiyonlayın, "ne olur ne olmaz diye her şeyi" değil.

Bilmeye değer bir incelik: bir seyrek dizinde projeksiyon yine yalnızca dizin anahtarını taşıyan item'ları tutar — bu yüzden bir seyrek dizinde INCLUDE/ALL, dizinin kendisi küçük olduğu için küçük kalır. Projeksiyonunuzun depolama ve yazma çarpanını DynamoDB fiyatlandırma hesaplayıcısı ile tartın ve dizin sorgularının kendisini DynamoDB expression builder ile kurun.

DynoTable'da bir projeksiyonu görme

DynoTable, bir tablonun ikincil dizinlerinin her birini listeler ve birinin üzerinden doğrudan sorgu yapmanızı sağlar. Aynı erişim desenini temel tabloya ve bir GSI'ye karşı çalıştırın ve sonuçları karşılaştırın — dizin sonucunda eksik olan attribute'lar tam olarak onun projeksiyonlamadıklarıdır, böylece bir projeksiyonun etkisi tablo tanımını yeniden okumadan görünür olur.

DynoTable'ın dizin seçicisinde, bir sorgunun hangi DynamoDB dizini üzerinden çalışacağını seçmek.
DynoTable'ın dizin seçicisinde, bir sorgunun hangi DynamoDB dizini üzerinden çalışacağını seçmek.

Tuzaklar ve sonraki adımlar

  • Bir GSI'de projeksiyonlanmamış bir attribute, bir temel tablo getirme demektir — projeksiyonu sorgunun render ettiği şeyin etrafında tasarlayın.
  • ALL nadiren bedavadır — depolama ve yazma maliyetini kopyalar; dizin gerçekten her alana ihtiyaç duymadıkça INCLUDE'a varsayılan yapın.
  • Projeksiyonlar çoğunlukla sabittir. Bir GSI'nin projeksiyonunu dizini yeniden oluşturmadan sonradan serbestçe düzenleyemezsiniz — baştan bilinçli seçin.
  • İlgili: GSI ile LSI ve seyrek dizinler, bir projeksiyonun gerçekte ne kadar depoladığını şekillendirir.

Dizinlerinizi yeniden tasarlamadan önce her birinin gerçekte ne döndürdüğünü görmek mi istiyorsunuz? DynoTable'ı indirin ve tablolarınızı doğrudan sorgulayın.

Hidrasyon maliyeti: KEYS_ONLY + N get

Destek masası kuyruğu örneğine dönün: subject, assignee ve age ile görüntülenen 50 açık talep.

ProjeksiyonDizin sorgusuTakip okumalarıNT RCU taslağı (2 KB'lık temel item'lar)
KEYS_ONLY50 anahtar döner50 × GetItem~50 dizin RCU + ~50 temel RCU
INCLUDE subject, assignee, age50 satır kendi kendine yeteryokyalnızca ~50 dizin RCU
ALL50 tam kopyayok~50 dizin RCU; daha yüksek depolama + yazma amplifikasyonu

Tam sayılar projeksiyonlanan attribute boyutlarına bağlıdır — örnek bir talebi item boyutu hesaplayıcısına yapıştırın ve kuyruk derinliğiyle çarpın. body attribute'u büyük olduğunda ve liste görünümünde nadiren gösterildiğinde, yalnızca arayüz alanlarını listeleyen INCLUDE çoğu zaman ALL'ı yener.

LSI projeksiyon getirme davranışı

Yalnızca LSI'ler, bir sorgu sırasında temel tablodan projeksiyonlanmamış attribute'ları isteğe bağlı olarak getirebilir (ek okuma maliyetiyle). GSI'ler bunu asla yapmaz — eksik attribute'lar, uygulamanızın temel tabloda GetItem çağırmasını gerektirir. Bu fark, birçok GSI tasarımını baştan biraz daha geniş INCLUDE projeksiyonlarına iter.

Projeksiyonları sonradan değiştirmek

GSI projeksiyonları oluşturma zamanında sabitlenir. KEYS_ONLY'yi INCLUDE'a genişletmek yeni bir dizin oluşturmayı, geri doldurmayı, trafiği devretmeyi ve eski dizini silmeyi gerektirir — alanları lansmandan önce planlayın. LSI'ler aynı sınırlamayı paylaşır.

Yeni bir erişim desenini değerlendirirken, aday dizini DynoTable'da sorgulayın ve hangi attribute'ların göründüğünü listeleyin — boşluklar eksik projeksiyon girdileriyle 1:1 eşleşir.

Seyrek dizinlerle eşleştirin

Yalnızca status = open talepleri dizinleyen seyrek bir GSI, yalnızca açık satırlar için projeksiyon saklar. Temel tablo milyonlarca kapalı talep tutsa bile o dizindeki INCLUDE ucuz kalır — dizin onları hiç kopyalamadı.

Filtrelenen alt küme tabloya göre küçük olduğunda seyrek dizin desenleriyle birleştirin.

Önce erişim desenini oluşturun

CloudFormation'ı değiştirmeden önce GSI sorgusunu — anahtar koşulu, projeksiyon expression'ı ve filtre — prototiplemek için query builder'ı kullanın. Tasarım tartışmasında projeksiyon türlerini, arayüzün hangi kolonları render ettiğini sorarak değiştirin; diğer her şey temel tabloda kalır.

Güncellendi