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#8842Artı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#8842Artı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).
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.

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):
| Desen | API çağrılar | Tipik WCU etkisi |
|---|---|---|
| İşlemsel silme + temel anahtara yerleştirme | TransactWriteItems (2 işlem) | ~2× işlem fiyatlandırmasında işlem başına öğe boyutu |
status özelliğini güncelleyin; GSI yeniden yayılır | Bir UpdateItem | Temel 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 alan | Taban masası SK | Daha iyi temel SK | Uçucu alan yaşamaya devam ediyor |
|---|---|---|---|
| Sipariş durumu | STATUS#shipped#ORD#99 | ORD#99 | GSI sıralama veya nitelik |
| Görev önceliği | P#1#TASK#12 | TASK#12 | GSI sıralama |
| sennın görünen adı | NAME#alice#USER#5 | USER#5 | Anahtar 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.


