Orta6 dakikalık okuma

Değişen Bir Öznitelikte DynamoDB Sıralama

Öğeleri sırasına göre sorgulayabilmeniz için bir öznitelik etrafında bir sıralama anahtarı modelleyebilirsiniz; nitelik değişiklikleri. Bir bildirimin durumu, bir siparişin durumu, bir görevin önceliği. DynamoDB'lar kural: bir anahtar niteliğini yerinde güncelleyemezsiniz.Birincil anahtar, aşağıdakiler için değiştirilemez: öğenin ömrü. Anahtarın parçası olan bir değeri değiştirin ve bir değeri düzenlemiyorsunuz. öğe — onu hareket ettiriyorsunuz ve bunu açıkça yapmanızı sağlıyor.

DynamoDB sort key değiştirilebilir mi?

Hayır. Sıralama anahtarı birincil anahtarın bir parçasıdır ve DynamoDB anahtar nitelikleri değişmez — UpdateItem bir bölümü düzenleyemez veya sıralama anahtarı değerini düzenleyemez ve "öğeyi taşıma" işlemi yoktur. Bunu değiştirmek için eski öğeyi silin ve yenisini koyun veya bunun yerine uçucu değeri GSI sıralama anahtarında tutun.

  • Anahtar özellikler değişmezdir.Bir bölümü veya sıralama anahtarını oluşturamazsınız değer — DynamoDB'da "öğeyi taşıma" işlemi yoktur.
  • Bir anahtar değerini değiştirmek için eski öğeyi silip yenisini koyarsınız— ideal olarak transaction yani atomiktir.
  • Daha iyi: uçucu değeri temel tablo anahtarından uzak tutunve onu bir anahtara koyun GSI bunun yerine sıralama tuşu — GSI anahtarlar can değişebilir, çünkü güncelleme temel öğe yalnızca dizin girişini yeniden çoğaltır.
  • Erişim her gerçekleştiğindedeğişmeyen sıralama anahtarlarını seçin(zaman damgaları, değişmez kimlikler) desen izin verir.

Sorun: sıralamak istediğin ama sürekli değişen bir durum

Diyelim ki bir destek masası işletiyorsunuz ve bir takımın destek taleplerini duruma göre sıralayarak listelemek istiyorsunuz. durumu sıralama anahtarına koyun:

PK: TEAM#7   SK: STATUS#open#TICKET#8842

Artık bilet pending’e geçiyor. Sıralama anahtarını yalnızca UpdateItem yapmak istiyorsunuz. STATUS#pending#TICKET#8842 — ancak DynamoDB anahtarı değiştiren her türlü yazmayı reddeder özellik. Anahtar, öğenin adresidir; adresi yerinde düzenleyemezsiniz. sıralamayı seçtiğiniz durum tam olarak yerinde durmayacak olan şeydir.

Seçenek 1: sil ve yeniden oluştur (atomik)

Değerin temel tablo anahtarında bulunması gerekiyorsa, bunu değiştirmek eski öğenin kaldırılması anlamına gelir ve yenisini yazıyorum:

1. DeleteItem  PK=TEAM#7  SK=STATUS#open#TICKET#8842
2. PutItem     PK=TEAM#7  SK=STATUS#pending#TICKET#8842  (same attributes)

Bunu bir TransactWriteItems içinde yapın, böylece silme ve koyma ya her ikisi de başarılı olur ya da her ikisi de başarısız olur - aksi takdirde aralarındaki bir çarpışma, oyunu kaybeder bilet alın veya çoğaltın. Bu işe yarar, ancak her durum değişikliği artık iki yazma artı bir işlem; ara sıra yapılan değişiklikler için iyi, sıcak olanlar için pahalı.

Seçenek 2: değişebilir değeri base key'den uzak tut (tercih edilen)

temel tablo anahtarını değişmezbir şey haline getirin (bilet kimliği) ve uçucu, sıralanabilir değeri bir GSIsıralama anahtarına yerleştirin.

Base:  PK: TICKET#8842   status: "open"   teamId: TEAM#7
GSI:   GSI1PK: TEAM#7    GSI1SK: STATUS#open#TICKET#8842

Artık durum değişikliği, temel öğenin status özelliğinde basit bir UpdateItem'dir — DynamoDB izin verir, çünkü status bir temel tablo anahtarı değildir. DynamoDB o zaman GSI girişini otomatik olarak yeni sıralama konumuna yeniden yayar. Tek bir API çağrısı, atomite senin için halledilir — işlem yok, silme dansı yok (başlangıçta DynamoDB yine de eski indeks girişini siler ve yenisini yazar, dolayısıyla indekslenmiş bir değişikliğin maliyeti ~3 işlemsel silme ve koymanın ~4'üne karşılık birimleri yazın).

YesNo, GSI sort keyDurum open'dan pending'edeğişirDeğer base-table anahtarındamı?Transaction içinde sil + yenidenoluşturNormal UpdateItem; GSI yenidenyayar

Takas: GSI eventually consistent ve ekstra depolama/yazma maliyetine sahiptir - ancak sık sık değişen bir değer için bu biraz daha ucuzdur (~3'e karşı 4 yazma birimi) ve her değişiklikte silip yeniden oluşturmaktan çok daha basittir.

DynoTable'da anahtarları tasarlamak

Hem temel okuma hem de GSI okuması için anahtar koşullarını DynamoDB ifade oluşturucusunda kurun ve önizleyin.

DynoTable'da, bir sorgunun hangi dizinden geçeceğini seçersiniz ve değişkenliği izlersiniz. temel öğe değişmez anahtarını korurken değer sıralaması GSI üzerinde yapılır; her ikisi de yan yana okunur gerçek verilere dayalıdır.

Temel öğe DynoTable'de değişmez bir anahtar tutarken durum sıralamalı GSI'u sorgulamak.
Temel öğe DynoTable'de değişmez bir anahtar tutarken durum sıralamalı GSI'u sorgulamak.
## Tuzaklar ve sonraki adımlar - Asla bir anahtar niteliği bulmaya çalışmayın— reddedilir; anahtar değerler sabittir öğenin ömrü boyunca. - Taşımanız gerekiyorsa, silin+bir işlem yapın— asla korumasız iki kişi olmayın yazıyor. - _ve_ değiştirme ölçütüyle sıraladığınız herhangi bir özellik için değişmez temel tuşları + GSItercih edin. - Sonuçta tutarlılığı unutmayın— kısa bir süre sonra yeniden sıralanan giriş görünür yayılma gecikmesi. - İlgili:[sort-key strategies](/learn/dynamodb-sort-key-strategies), [GSI ile LSI](/learn/dynamodb-gsi-vs-lsi), [işlemler](/learn/dynamodb-transactions).

Değişken bir özelliğin temel tabloya göre GSI sıralamasında nasıl sıralandığını görmek ister misiniz? Download DynoTable ve dizinlerinizi doğrudan keşfedin.

Yazma maliyeti: sil-ve-put vs GSI güncelleme

Talep üzerine us-east-1'de 1 KB'lik bir bilet öğesi için kaba WCU karşılaştırması (gerçek faturalandırmada AWS yuvarlama kurallarına uyulur):

DesenAPI çağrılarTipik WCU etkisi
İşlemsel silme + temel anahtara yerleştirmeTransactWriteItems (2 işlem)~2× işlem fiyatlandırmasında işlem başına öğe boyutu
status özelliğini güncelleyin; GSI yeniden yayılırBir UpdateItemTemel yazma + GSI yazma (1 KB öğe için ~2 WCU + öngörülen öznitelikler)

GSI yolu, uygulama düzeyinde düzenlemeyi önler ve pencereyi ortadan kaldırır burada silme ve koyma arasındaki çarpışma satırı kaybeder. Ticaret yapıyorsun dizin okumasındaki nihai tutarlılığı daha basit yazmalar karşılığında takas edersiniz.

Öğe boyutunuzu ve güncelleme oranınızı modelleyin pricing calculator durum değiştiğinde yanar dakikada birçok kez.

Sparse GSI for status-sorted lists

Yalnızca açıkbiletlerin duruma göre sıralanmış bir kuyruğa ihtiyacı varsa, sparse index: GSI1PK = TEAM#7 yazın ve GSI1SK = STATUS#open#... yalnızca status = open iken. Bilet kapandığında, güncelleme sırasında GSI temel niteliklerini kaldırın veya atlayın — öğe listeden çıkar temel sıralama anahtarında sil ve koy özelliği olmayan dizin.

Bu, endeksi küçük tutar ve asla listelemediğiniz kapalı biletlerin endekslenmesini önler.

Immutable base keys to prefer

Uçucu alanTaban masası SKDaha iyi temel SKUçucu alan yaşamaya devam ediyor
Sipariş durumuSTATUS#shipped#ORD#99ORD#99GSI sıralama veya nitelik
Görev önceliğiP#1#TASK#12TASK#12GSI sıralama
sennın görünen adıNAME#alice#USER#5USER#5Anahtar olmayan öznitelik

Zaman damgaları ve değişmez kimlikler (CREATED#2026-06-27T10:00:00Z, TICKET#8842) Temel tabloda kronolojik sıralamaya ihtiyaç duyduğunuzda sabit temel sıralama anahtarları oluşturun kendisi.

Kodlamadan önce GSI'yi tasarla

Harita erişim modellerini single-table design tool — "listeyi girin Biletleri takıma göre aç, öncelik sırası" ve önerilen GSI1PK / GSI1SK şablonları. Daha sonra anahtar koşulu oluşturun expression builder ve sayfalandırılmış bir mesaj yayınlayın Entegrasyon için query builder ile sorgulama testler.

Durum değişikliğinden sonra kendi yazmanı oku

UpdateItem sonrasında, temel tablodaoldukça tutarlı bir okuma şunu gösterir: hemen yeni status. GSI ile ilgili bir sorgu kısa süreliğine gecikebilir. Kullanıcı arayüzü şu şekilde akıyor GSI-sıralı bir kuyruğa yönlendirme eski satırları tolere etmeli veya Hassasiyet önemli olduğunda temel tabloyu kimliğe göre ayarlayın.

Güncellendi