Strategi Sort Key DynamoDB: 3 Pola dan Kapan Memakainya

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

Sort key menentukan urutan Item di dalam partisi 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 koleksi.

Datang dari SQL Anda akan meraih sebuah ORDER BY atau indeks sekunder setelah faktanya. Di DynamoDB Anda memanggang urutan ke dalam key sejak awal, atau Anda tidak mendapatkannya.

Bagaimana cara kerja sort key DynamoDB?

Sebuah sort key DynamoDB mengurutkan Item di dalam sebuah partisi, sehingga Query bisa melakukan range read — >=, between, begins_with — alih-alih mengambil satu Item satu waktu. Sort key bertipe String diurutkan berdasarkan byte UTF-8 (Number diurutkan secara numerik), jadi desain sebuah key String (timestamp ISO-8601, angka ber-zero-pad) agar urutan byte sama dengan urutan yang ingin Anda baca.

• Sort key adalah indeks in-partisi Anda. Ia mengurutkan item collection di disk, sehingga Query bisa melakukan range read (>=, between, begins_with) alih-alih satu GetItem.
• Sort key String diurutkan berdasarkan byte UTF-8 (Number diurutkan secara numerik). Desain sebuah key String agar urutan byte sama dengan urutan yang ingin Anda baca — sebuah timestamp ISO-8601, sebuah angka ber-zero-pad, jangan pernah UUID mentah atau 6/23/2026.
• Satu sort key yang berbentuk baik melayani banyak pola akses. Sebuah composite key (EVT#<timestamp>) adalah sebuah prefix dan sebuah rentang sekaligus — tanpa GSI.
• Arah itu gratis. ScanIndexForward = false membaca terbaru-dulu dengan biaya yang sama; jangan menyimpan timestamp terbalik untuk memalsukannya.

Mengapa sort key adalah tuasnya

Tanpa sort key, setiap Item dalam partisi hanya dapat dialamati oleh primary key penuhnya — sebuah GetItem paling banter. Tambahkan sort key dan DynamoDB menyimpan Item terurut olehnya di dalam partisi, yang membuka Query.

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

Menurut AWS DynamoDB Developer Guide, semua Item yang berbagi partition key membentuk sebuah item collection, terurut di disk oleh sort key.

Jadi sort key bukan sekadar pengenal kedua. Ia adalah indeks yang Anda query terhadapnya di dalam sebuah partisi.

Pengurutan itu adalah urutan byte pada sort key ter-enkode: 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 sesuatu, urutan byte harus cocok dengan urutan yang ingin Anda baca.

Strategi 1: buat sort key dapat diurutkan

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

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

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

Jika Anda mengurut pada angka (counter versi, sebuah skor), gunakan tipe Number native DynamoDB alih-alih sebuah string, agar 42 mengurut setelah 9 alih-alih sebelumnya.

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

Strategi 2: composite sort key untuk hierarki

Sebuah sort key dapat mengenkode hierarki dengan menggabungkan segmen dengan pembatas, paling umum #. Satu kondisi begins_with lalu memilih seluruh sub-pohon:

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 bersebelahan, sehingga range read tetap satu query murah alih-alih tersebar melintasi partisi.

Strategi 3: kendalikan arah dengan ScanIndexForward

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

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

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

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

Contoh dikerjakan: audit log ber-cakupan-aktor

Misalkan Anda merekam event ber-timestamp yang dihasilkan oleh aktor — user, service, API key — dalam produk SaaS, dan Anda punya dua pembacaan:

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

Kedua pembacaan tercakup ke satu aktor tunggal, jadi aktor adalah partition key dan waktu event adalah sort key. Gunakan nama key generik agar tabel yang sama dapat menampung entitas lain nanti:

Prefix EVT# plus timestamp ISO-8601 memberi sort key yang dapat diurutkan. Pembacaan 1 adalah Query PK = "ACTOR#u_8814" dengan ScanIndexForward = false untuk terbaru-dulu. Pembacaan 2 mempersempit partisi 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 koleksi, dua pola akses, tanpa GSI — karena sort key adalah sekaligus sebuah prefix (EVT#) dan sebuah rentang (timestamp). Pembacaan menurun dan pembacaan jendela adalah Item yang sama dalam urutan yang sama; hanya parameternya yang berbeda.

Membangun key condition itu secara manual, mudah untuk keliru pada batas between atau peng-escape-an reserved-word pada nama atribut.

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

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

Lakukan di DynoTable

Mendesain sort key bersifat iteratif: tulis beberapa Item representatif, jalankan range query, dan periksa baris kembali dalam urutan yang Anda harapkan. Melakukan itu terhadap tabel live dalam sebuah GUI mengalahkan bolak-balik lewat kode.

Balik arah pengurutan, perketat batas between, dan amati koleksi yang dikembalikan berubah tanpa menulis satu baris kode — cara tercepat untuk mengonfirmasi desain sort-key sebelum Anda meng-commit-nya.

Jebakan dan langkah selanjutnya

• Sort key harus unik dalam sebuah partisi. Jika dua event dapat berbagi timestamp, tambahkan pembeda (nomor urut atau id pendek) ke sort key agar komposit tetap unik.
• Hot partition tidak bisa diakali dengan pengurutan. Jika satu aktor menghasilkan jauh lebih banyak event dari yang lain, sort key tidak akan menyelamatkan Anda — Anda butuh desain partition-key yang menyebarkan beban. Lihat single-table design.
• Urutan sort kedua butuh indeks kedua. Sort key tabel dasar memberi satu pengurutan. Untuk mengurutkan Item yang sama secara berbeda (berdasarkan tipe event, katakanlah), tambahkan sebuah GSI dengan sort key berbeda — menimbang trade-off local vs global secondary index.
• Jangan meraih Scan untuk "urutkan nanti". Mengurutkan di sisi klien setelah sebuah Scan membaca seluruh tabel dan membuang pengurutan; itu adalah jebakan Scan. Dorong urutan ke dalam sort key sebagai gantinya.

Begitu key condition benar, coba DynoTable untuk memodelkan koleksi, menjalankan query menaik dan menurun berdampingan, dan memverifikasi strategi sort-key Anda terhadap data nyata sebelum ia dikirim.