Mengurutkan DynamoDB Berdasarkan Atribut yang Berubah (Mutable)

Anda memodelkan sort key di sekitar sebuah atribut agar bisa mem-Query Item dalam urutannya — lalu atribut itu berubah. Status sebuah tiket, keadaan sebuah order, prioritas sebuah task. Inilah jebakan yang dilemparkan DynamoDB: Anda tidak bisa meng-update atribut key di tempat. Sebuah primary key bersifat immutable sepanjang umur Item. Ubah sebuah nilai yang merupakan bagian dari key dan Anda bukan mengedit sebuah Item — Anda memindahkannya, yang oleh DynamoDB diharuskan dilakukan secara eksplisit.

Bisakah Anda mengubah sort key DynamoDB?

Tidak. Sort key merupakan bagian dari primary key, dan atribut key DynamoDB bersifat immutable — UpdateItem tidak dapat mengubah nilai partition key atau sort key, dan tidak ada operasi "pindah item". Untuk mengubahnya, hapus item lama dan buat yang baru, atau simpan nilai yang volatil pada sort key GSI sebagai gantinya.

• Atribut key bersifat immutable. Anda tidak bisa UpdateItem sebuah nilai partition atau sort key — DynamoDB tidak punya operasi "pindah item".
• Untuk mengubah nilai key, Anda menghapus Item lama dan mem-put yang baru — idealnya dalam sebuah transaksi agar atomik.
• Lebih baik: jauhkan nilai volatil dari key base-table dan letakkan pada sort key GSI sebagai gantinya — key GSI bisa berubah, karena meng-update Item dasar cukup mem-propagasi-ulang entri index.
• Pilih sort key yang tidak berubah (timestamp, id immutable) kapan pun pola akses mengizinkan.

Masalahnya: status yang ingin Anda jadikan urutan, yang terus berubah

Misalkan Anda menjalankan meja dukungan dan ingin mendaftar tiket sebuah tim yang terurut berdasarkan status, jadi Anda menaruh status di sort key:

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

Sekarang tiket berpindah ke pending. Anda ingin sekadar UpdateItem sort key menjadi STATUS#pending#TICKET#8842 — tetapi DynamoDB menolak setiap penulisan yang mengubah atribut key. Key adalah alamat Item; Anda tidak bisa mengedit alamat di tempat. Status yang Anda pilih untuk pengurutan justru adalah hal yang tidak mau diam.

Opsi 1: hapus dan buat ulang (secara atomik)

Jika nilai itu harus berada di key base-table, 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 sebuah TransactWriteItems agar delete dan put sama-sama berhasil atau sama-sama gagal — jika tidak, sebuah crash di antara keduanya menghilangkan tiket atau menggandakannya. Ini berfungsi, tetapi setiap perubahan status kini menjadi dua penulisan ditambah sebuah transaksi; baik untuk perubahan sesekali, mahal untuk yang panas.

Opsi 2: jauhkan nilai mutable dari base key (disarankan)

Desain yang lebih bersih: jadikan key base-table sesuatu yang immutable (id tiket) dan letakkan nilai yang volatil dan dapat-diurutkan pada sort key GSI.

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

Kini mengubah status adalah sebuah UpdateItem biasa pada atribut status Item dasar — yang diizinkan DynamoDB, karena status bukan key base-table. DynamoDB lalu mem-propagasi-ulang entri GSI secara otomatis ke posisi terurutnya yang baru. Satu penulisan, tanpa transaksi, tanpa tarian delete.

Trade-off-nya: GSI bersifat eventually consistent dan menelan storage/penulisan ekstra — tetapi untuk nilai yang sering berubah, itu jauh lebih murah daripada hapus-dan-buat-ulang pada setiap perubahan.

Merancang key di DynoTable

Bangun dan pratinjau condition key untuk baik pembacaan dasar maupun pembacaan GSI di DynamoDB expression builder.

Di DynoTable, Anda lalu memilih lewat index mana sebuah Query berjalan dan menyaksikan nilai volatil terurut pada GSI sementara Item dasar mempertahankan key-nya yang immutable — kedua pembacaan berdampingan pada data nyata.

Jebakan dan langkah berikutnya

• Jangan pernah mencoba UpdateItem sebuah atribut key — ia ditolak; nilai key tetap sepanjang umur Item.
• Jika Anda harus memindahkannya, lakukan delete+put dalam sebuah transaksi — jangan pernah sebagai dua penulisan tanpa pengaman.
• Utamakan base key immutable + sebuah GSI untuk setiap atribut yang Anda urutkan sekaligus ubah.
• Jangan lupakan eventual consistency GSI — entri yang terurut-ulang muncul setelah jeda propagasi singkat.
• Terkait: strategi sort-key, GSI vs LSI, transaksi.

Ingin melihat bagaimana atribut mutable terurut pada GSI versus base table? Unduh DynoTable dan jelajahi index Anda secara langsung.