Strategi Sort Key DynamoDB

Sebuah primary key DynamoDB adalah satu atau dua atribut: partition key saja, atau partition key plus sort key. Partition key memutuskan partition fisik mana yang menampung sebuah Item.

Sort key memutuskan urutan Item di dalam partition itu — dan pengurutan itulah yang membuat Query bertenaga.

Pilih sort key yang salah dan Anda masih bisa menulis data, tetapi Anda kehilangan range read, pengurutan, dan beberapa pola akses dari satu collection.

Datang dari SQL, Anda akan meraih ORDER BY atau secondary index belakangan. Di DynamoDB Anda memanggang urutan ke dalam key sejak awal, atau Anda tak mendapatkannya.

Bagaimana cara kerja sort key DynamoDB?

Sort key DynamoDB mengurutkan item di dalam sebuah partition, sehingga Query dapat melakukan range read — >=, between, begins_with — alih-alih mengambil satu item sekaligus. Pengurutan adalah urutan-byte pada key yang dikodekan, jadi rancang key tersebut (timestamp ISO-8601, angka yang di-zero-pad) agar urutan-byte sama dengan urutan yang ingin Anda baca.

• Sort key adalah index dalam-partition Anda. Ia mengurutkan item collection pada disk, jadi Query bisa melakukan range read (>=, between, begins_with) alih-alih GetItem tunggal.
• Pengurutan adalah urutan-byte pada key yang dikodekan. Rancang key agar urutan-byte sama dengan urutan yang ingin Anda baca — timestamp ISO-8601, angka yang di-zero-pad, tak pernah UUID mentah atau 6/23/2026.
• Satu sort key yang dibentuk baik melayani banyak pola akses. Composite key (EVT#<timestamp>) sekaligus prefiks dan rentang — tanpa GSI.
• Arah itu gratis. ScanIndexForward = false membaca terbaru-lebih-dulu dengan biaya sama; jangan menyimpan timestamp terbalik untuk memalsukannya.

Mengapa sort key adalah tuasnya

Tanpa sort key, setiap Item dalam partition hanya dapat dialamati lewat primary key penuhnya — GetItem sebaik-baiknya. Tambahkan sort key dan DynamoDB menyimpan Item terurut berdasarkan sort key di dalam partition, yang membuka Query.

Itu berarti kondisi rentang (>=, between), pencocokan prefiks (begins_with), dan flag ScanIndexForward untuk membaca menaik atau menurun.

Menurut AWS DynamoDB Developer Guide, semua Item yang berbagi partition key membentuk item collection, terurut pada disk berdasarkan sort key.

Jadi sort key bukan sekadar identifier kedua. Ia adalah index yang Anda query di dalam sebuah partition.

Pengurutan itu adalah urutan-byte pada sort key yang dikodekan: string dibandingkan berdasarkan byte UTF-8, angka dibandingkan secara numerik. Satu fakta ini mendorong hampir setiap strategi di bawah.

Jika Anda ingin range query berarti, urutan-byte harus cocok dengan urutan yang ingin Anda baca.

Strategi 1: buat sort key dapat diurut

Kesalahan paling umum adalah sort key yang tak terurut secara bermakna. Sebuah UUID acak memberi Anda keunikan tetapi tanpa range query yang berguna — "berikan 20 terakhir" menjadi mustahil karena urutan-byte-nya sembarang.

Sebagai gantinya, kodekan nilai yang Anda urut dan filter ke dalam sort key, dalam representasi yang urutan-byte-nya sama dengan urutan logisnya. Untuk timestamp itu berarti format yang dapat diurut secara leksikografis: string ISO-8601 atau epoch yang di-zero-pad.

ISO-8601 dirancang agar perbandingan string sama dengan perbandingan kronologis — persis yang dibutuhkan range query. Hindari format seperti 6/23/2026; mereka terurut salah begitu bulannya berganti.

Jika Anda mengurutkan berdasarkan angka (counter versi, skor), gunakan tipe Number native DynamoDB daripada string, agar 42 terurut setelah 9 alih-alih sebelumnya.

Jika sebuah angka harus hidup di dalam composite string sort key, zero-pad ia ke lebar tetap.

Strategi 2: composite sort key untuk hierarki

Sebuah sort key bisa mengkodekan hierarki dengan menggabungkan segmen menggunakan delimiter, paling umum #. Satu kondisi begins_with lalu memilih seluruh sub-tree:

begins_with(SK, "EVENT#2026-06#") mengembalikan hanya event Juni; yang lebih luas begins_with(SK, "EVENT#") mengembalikan semuanya.

Pengurutan segmen adalah keputusan desain. Kasar-ke-halus (tahun → bulan → hari) menjaga Item terkait tetap menyatu, jadi range read tetap satu query murah alih-alih tersebar melintasi partition.

Strategi 3: kontrol arah dengan ScanIndexForward

DynamoDB menyimpan Item dalam urutan sort-key menaik dan membacanya begitu secara default. Untuk membaca terbaru-lebih-dulu — urutan alami untuk feed aktivitas — setel ScanIndexForward = false pada Query.

Ini adalah flag waktu-baca, bukan keputusan schema: collection yang sama melayani kedua arah dengan biaya sama. Jangan membalik timestamp Anda (menyimpan "reverse epoch") hanya untuk mendapat pembacaan menurun.

Satu item collection, disimpan sekali dalam urutan menaik, dibaca dua arah:

Item sama, partition sama, biaya sama — hanya arah baca yang berbeda.

Satu pengecualian: jika Anda secara khusus butuh urutan menurun untuk juga menjadi urutan yang dilalui sparse index atau cursor pagination. Selain itu, ScanIndexForward adalah tuas yang lebih sederhana.

Contoh nyata: audit log tercakup-actor

Misalkan Anda mencatat event bertimestamp yang dihasilkan actor — user, service, API key — dalam produk SaaS, dan Anda punya dua pembacaan:

1. Aliran aktivitas untuk satu actor, event terbaru lebih dulu.
2. Event satu actor dalam jendela waktu (mis. "segalanya di antara dua deploy"), untuk investigasi.

Kedua pembacaan tercakup pada satu actor, jadi actor adalah partition key dan waktu event adalah sort key. Gunakan nama key generik agar tabel yang sama bisa menampung entitas lain belakangan:

Prefiks EVT# plus timestamp ISO-8601 memberi sort key yang dapat diurut. Pembacaan 1 adalah Query PK = "ACTOR#u_8814" dengan ScanIndexForward = false untuk terbaru-lebih-dulu. Pembacaan 2 mempersempit partition yang sama dengan kondisi between pada sort key:

Query
PK = "ACTOR#u_8814"
AND SK BETWEEN "EVT#2026-06-23T00:00:00Z"
AND "EVT#2026-06-23T23:59:59Z"

Satu collection, dua pola akses, tanpa GSI — karena sort key sekaligus prefiks (EVT#) dan rentang (timestamp). Pembacaan menurun dan pembacaan jendela adalah Item yang sama dalam urutan yang sama; hanya parameternya berbeda.

Membangun kondisi key itu dengan tangan, mudah salah pada batas between atau escaping reserved-word pada nama atribut.

DynamoDB Expression Builder menghasilkan KeyConditionExpression, ExpressionAttributeNames, dan ExpressionAttributeValues untuk kondisi sort-key begins_with atau between.

Salin ia langsung ke panggilan SDK Anda alih-alih men-debug escaping saat runtime.

Lakukan di DynoTable

Merancang sort key bersifat iteratif: tulis beberapa Item representatif, jalankan range query, dan periksa baris kembali dalam urutan yang Anda harapkan. Melakukan itu terhadap tabel langsung di GUI mengalahkan round-trip lewat kode.

Balikkan arah sort, perketat batas between, dan saksikan collection yang dikembalikan berubah tanpa menulis satu baris kode pun — cara tercepat memastikan desain sort-key sebelum Anda menetapkannya.

Jebakan dan langkah berikutnya

• Sort key harus unik di dalam partition. Jika dua event bisa berbagi timestamp, tambahkan disambiguator (sequence number atau id pendek) ke sort key agar composite-nya tetap unik.
• Hot partition tak bisa diakali dengan pengurutan. Jika satu actor menghasilkan jauh lebih banyak event daripada sisanya, sort key tak akan menyelamatkan Anda — Anda butuh desain partition-key yang menyebarkan beban. Lihat single-table design.
• Urutan sort kedua butuh index kedua. Sort key tabel dasar memberi satu pengurutan. Untuk mengurutkan Item yang sama secara berbeda (berdasarkan tipe event, misalnya), tambahkan GSI dengan sort key berbeda — menimbang trade-off local vs global secondary index.
• Jangan raih Scan untuk "mengurutkan belakangan". Mengurutkan sisi-klien setelah Scan membaca seluruh tabel dan membuang pengurutannya; itulah footgun Scan. Dorong urutan ke dalam sort key.

Setelah kondisi key benar, coba DynoTable untuk memodelkan collection, menjalankan query menaik dan menurun secara berdampingan, dan memverifikasi strategi sort-key Anda terhadap data nyata sebelum dirilis.