Composite Primary Key DynamoDB

Sebuah composite primary key adalah dua atribut: sebuah partition key dan sebuah sort key. Partition key memutuskan di mana sebuah item tinggal; sort key mengurutkan item di dalam partition itu.

Datang dari SQL, anggap ia bukan sebagai kolom id unik melainkan lebih seperti GROUP BY partition, ORDER BY sort yang dipanggang ke dalam tabel itu sendiri.

Apa itu composite primary key DynamoDB?

Composite primary key DynamoDB menggabungkan dua atribut: sebuah partition key dan sebuah sort key. Partition key menentukan di partition fisik mana sebuah item tinggal; sort key mengurutkan item di dalam partition itu. Bersama-sama keduanya membentuk identitas unik item dan membiarkan satu Query mengembalikan rentang terurut alih-alih satu item saja.

• Dua bagian, dua tugas. Partition key merutekan item ke sebuah partition fisik; sort key mengurutkan setiap item yang berbagi partition key itu.
• Keunikan adalah pasangannya. Dua item bisa berbagi nilai partition key selama sort key-nya berbeda — begitulah satu partition menampung banyak baris.
• Sort key adalah intinya. Itulah yang membiarkan sebuah Query mengembalikan rentang (>=, between, begins_with) alih-alih satu item, tanpa Scan.
• Key harus skalar. Partition dan sort key hanya bisa berupa string, number, atau binary — tanpa map, tanpa list (AWS docs).

Simple key vs composite key

Sebuah simple primary key hanyalah sebuah partition key. Ia mengidentifikasi item secara unik, dan Anda membacanya kembali dengan GetItem. Itu saja — tanpa pembacaan rentang, tanpa "beri saya N terbaru".

Sebuah composite key menambahkan sort key, dan satu penambahan itu yang membuat DynamoDB terasa seperti database, bukan hash map.

Modelkan tabel pembacaan sensor

Misalkan Anda mengumpulkan sampel suhu dari armada sensor lapangan. Pola aksesnya adalah "ambil pembacaan untuk satu perangkat, terbaru dulu, dalam sebuah jendela waktu". Itu adalah composite key buku teks.

Gunakan id perangkat sebagai partition key dan timestamp pembacaan sebagai sort key:

Ketiga pembacaan DEV#a1b2 mendarat di partition yang sama, secara fisik tersimpan bersama dan terurut berdasarkan readingTs.

AWS menyebut partition key sebagai hash attribute dan sort key sebagai range attribute — sort key adalah sebuah rentang yang bisa Anda scan di dalamnya (AWS docs).

Berikut bagaimana item-nya runtuh menjadi satu item collection di bawah tiap partition key:

Satu Query terhadap partition key membaca setiap pembacaan untuk perangkat itu, sudah dalam urutan timestamp — tanpa pengurutan di klien, tanpa round trip kedua.

Query rentangnya, jangan scan

Karena readingTs adalah string ISO-8601, ia terurut secara leksikografis dengan cara yang sama seperti ia terurut secara kronologis. Jadi sebuah pembacaan jendela-waktu adalah rentang key-condition, bukan filter:

Query
deviceId  = "DEV#a1b2"
readingTs BETWEEN "2026-06-23T08:00:00Z" AND "2026-06-23T08:10:00Z"

Itu adalah KeyConditionExpression — ia mempersempit pembacaan sebelum DynamoDB mengembalikan data, jadi Anda hanya membayar untuk item dalam jendela. Sebuah FilterExpression berjalan setelah pembacaan dan menagih Anda untuk segala yang dilewatinya; itulah jebakan Scan dalam miniatur.

Ekspresinya sendiri, dengan placeholder dan nilai bertipe, ribet ditulis dengan tangan. Bangun ia secara visual dengan DynamoDB Expression Builder dan salin KeyConditionExpression yang persis ke panggilan SDK Anda.

Desain sort key dengan sengaja

Sort key bukan metadata gratis — ia adalah satu-satunya tuas untuk pembacaan rentang, jadi bentuk ia untuk query Anda.

• Gunakan timestamp yang dapat diurutkan. String ISO-8601 atau number epoch yang ter-zero-pad terurut dengan benar; tanggal terlokalisasi mentah tidak.
• Beri prefix untuk overloading one-to-many. Sebuah sort key seperti READING#2026-06-23T08:00:00Z membiarkan Anda mencampur tipe entitas di bawah satu partition dan mengirisnya dengan begins_with. Itu adalah jahitan menuju single-table design.
• Taruh dimensi berkardinalitas-tinggi di partition key. Id sensor punya ribuan nilai, jadi ia menyebarkan penulisan merata. Sebuah partition key berkardinalitas rendah (misalnya region) menciptakan sebuah hot partition.

Kapan composite key menggigit Anda

Ia adalah komitmen, bukan kemudahan. Jebakannya: Anda memilih sebuah partition key, merilis, lalu menemukan sebuah pola akses yang butuh pengelompokan yang berbeda — "semua pembacaan di atas 30°C di seluruh armada".

Base table tak bisa menjawab itu; partition key-nya tetap. Pilihan Anda adalah sebuah global secondary index dengan key berbeda, atau restrukturisasi.

Enumerasi pembacaan Anda sebelum Anda mengomit skema key-nya. Mengubah sebuah primary key berarti migrasi tabel, bukan ALTER TABLE.

Langkah berikutnya

Composite key adalah fondasi di balik item collection, relasi one-to-many, dan sebagian besar desain indeks yang berguna — baca single-table design dan GSI vs LSI berikutnya untuk melihat ke mana mereka menuju.

Sketsakan KeyConditionExpression Anda di DynamoDB Expression Builder, lalu coba DynoTable untuk menjelajahi partition asli Anda dan amati urutan sort sejajar terhadap tabel Anda sendiri.