Mengurutkan DynamoDB pada atribut yang berubah

Anda memodelkan sort key di sekitar atribut agar bisa Query item sesuai urutannya — lalu atribut itu berubah. Status tiket, state order, prioritas task. Aturan DynamoDB: Anda tidak bisa meng-update atribut key in place. Primary key immutable selama hidup item. Mengubah nilai yang bagian dari key bukan mengedit item — Anda memindahkannya, dan DynamoDB membuat Anda melakukannya secara eksplisit.

Bisakah Anda mengubah sort key DynamoDB?

Tidak. Sort key adalah bagian dari primary key, dan atribut key DynamoDB immutable — UpdateItem tidak bisa mengedit nilai partition atau sort key, dan tidak ada operasi "pindahkan item". Untuk mengubahnya, hapus item lama dan put yang baru, atau simpan nilai volatil di sort key GSI sebagai gantinya.

• Atribut key immutable. Anda tidak bisa UpdateItem nilai partition atau sort key — DynamoDB tidak punya operasi "pindahkan item".
• Untuk mengubah nilai key Anda hapus item lama dan put yang baru — idealnya dalam transaction agar atomik.
• Lebih baik: jaga nilai volatil di luar key tabel dasar dan taruh di sort key GSI — key GSI bisa berubah, karena meng-update item dasar hanya mere-propagasi entri indeks.
• Pilih sort key yang tidak berubah (timestamp, id immutable) setiap kali access pattern memungkinkan.

Masalahnya: status yang ingin Anda urutkan, yang terus berubah

Katakan Anda menjalankan support desk dan ingin mendaftar tiket tim diurutkan by status, jadi Anda taruh status di sort key:

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

Sekarang tiket pindah ke pending. Anda ingin sekadar UpdateItem sort key ke STATUS#pending#TICKET#8842 — tetapi DynamoDB menolak setiap write yang mengubah atribut key. Key adalah alamat item; Anda tidak bisa mengedit alamat in place. Status yang Anda pilih untuk diurutkan tepat adalah yang tidak mau diam.

Opsi 1: hapus dan buat ulang (secara atomik)

Jika nilai harus hidup di key tabel dasar, mengubahnya berarti menghapus item lama dan menulis yang baru:

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

Lakukan di dalam TransactWriteItems agar delete dan put keduanya berhasil atau keduanya gagal — kalau tidak, crash di antaranya kehilangan tiket atau menduplikasinya. Ini bekerja, tetapi setiap perubahan status sekarang dua write plus transaksi; cocok untuk perubahan sesekali, mahal untuk yang panas.

Opsi 2: jaga nilai mutable di luar key dasar (disukai)

Buat key tabel dasar sesuatu yang immutable (id tiket) dan taruh nilai volatil yang bisa diurutkan di sort key GSI.

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

Sekarang mengubah status adalah UpdateItem polos pada atribut status item dasar — yang DynamoDB izinkan, karena status bukan key tabel dasar. DynamoDB lalu mere-propagasi entri GSI secara otomatis ke posisi terurut barunya. Satu panggilan API, dengan atomisitas ditangani untuk Anda — tanpa transaksi, tanpa tarian delete (di balik layar DynamoDB tetap menghapus entri indeks lama dan menulis yang baru, jadi perubahan terindeks menelan ~3 write unit dibanding ~4 dari delete-and-put transaksional).

GSI eventually consistent dan menelan storage/write ekstra — tetapi untuk nilai yang sering berubah, itu agak lebih murah (~3 vs 4 write unit) dan jauh lebih sederhana daripada delete-and-recreate pada setiap perubahan.

Mendesain key di DynoTable

Bangun dan preview key condition untuk baca dasar dan baca GSI di pembuat ekspresi DynamoDB.

Di DynoTable, Anda lalu pilih indeks mana yang dijalankan query dan saksikan nilai volatil mengurut di GSI sementara item dasar menjaga key immutable-nya — kedua baca berdampingan pada data nyata.

Jebakan + langkah selanjutnya

• Jangan pernah mencoba UpdateItem atribut key — ditolak; nilai key tetap selama hidup item.
• Jika harus memindahkannya, lakukan delete+put dalam transaksi — jangan sebagai dua write tanpa penjaga.
• Prefer key dasar immutable + GSI untuk atribut apa pun yang Anda urutkan dan mutasi.
• Jangan lupa eventual consistency GSI — entri yang diurut ulang muncul setelah delay propagasi singkat.
• Terkait: strategi sort key, GSI vs LSI, transactions.

Ingin melihat bagaimana atribut mutable mengurut di GSI versus tabel dasar? Unduh DynoTable dan jelajahi indeks Anda langsung.

Biaya tulis: delete-and-put vs update GSI

Perbandingan kasar WCU untuk item tiket 1 KB di us-east-1 on-demand (billing aktual mengikuti aturan pembulatan AWS):

Jalur GSI menghindari orkestrasi tingkat aplikasi dan menghilangkan jendela di mana crash antara delete dan put kehilangan baris. Anda menukar eventual consistency pada baca indeks untuk write yang lebih sederhana.

Model ukuran item dan laju update di kalkulator harga saat perubahan status menyala berkali-kali per menit.

GSI sparse untuk daftar terurut status

Jika hanya tiket open yang butuh antrian terurut status, pakai sparse index: tulis GSI1PK = TEAM#7 dan GSI1SK = STATUS#open#... hanya sementara status = open. Saat tiket close, hapus atau hilangkan atribut key GSI pada update — item keluar dari indeks tanpa delete-and-put pada sort key dasar.

Itu menjaga indeks kecil dan menghindari mengindeks tiket closed yang tidak pernah Anda daftar.

Key dasar immutable yang lebih disukai

Timestamp dan id immutable (CREATED#2026-06-27T10:00:00Z, TICKET#8842) membuat sort key dasar yang stabil saat Anda butuh urutan kronologis pada tabel dasar itu sendiri.

Desain GSI sebelum coding

Petakan access pattern di alat single-table design — masukkan "daftar tiket open by tim, urutan prioritas" dan periksa template GSI1PK / GSI1SK yang disarankan. Lalu bangun key condition di expression builder dan emit query terpaginasi dengan query builder untuk tes integrasi.

Read-your-writes setelah perubahan status

Setelah UpdateItem, baca strongly consistent pada tabel dasar menampilkan status baru segera. Query pada GSI mungkin tertinggal sebentar. Alur UI yang mengalihkan ke antrian terurut GSI harus mentoleransi baris basi atau re-fetch dari tabel dasar by id saat presisi penting.