Kunci Utama Komposit DynamoDB: Penjelasan Kunci Partisi + Pengurutan
Kunci utama komposit terdiri dari dua atribut: kunci partisi dan a kunci pengurutan. Kunci partisi menentukan di mana suatu item berada; kunci pengurutan memesan item di dalam partisi itu.
Berasal dari SQL, anggap saja ini bukan sebagai kolom id yang unik dan lebih sebagai
GROUP BY partition, ORDER BY sort dimasukkan ke dalam meja itu sendiri.
Apa itu kunci primer komposit DynamoDB?
Kunci utama komposit DynamoDB menggabungkan dua atribut: kunci partisi dan a
kunci pengurutan. Kunci partisi menentukan di partisi fisik mana suatu item berada;
kunci pengurutan mengurutkan item di dalam partisi itu. Bersama-sama mereka membentuk item itu
identitas unik dan biarkan satu Query mengembalikan rentang yang diurutkan, bukan satu
barang.
- Dua bagian, dua pekerjaan. Kunci partisi merutekan item ke fisik partisi; kunci pengurutan mengurutkan setiap item yang berbagi kunci partisi itu.
- Keunikan adalah pasangannya. Dua item dapat berbagi nilai kunci partisi selama karena kunci pengurutannya berbeda — begitulah satu partisi menampung banyak baris.
- Kunci pengurutan adalah intinya. Inilah yang memungkinkan
Querymengembalikan suatu rentang (>=,between,begins_with) bukan satu item, tanpaScan. - Kunci harus berupa skalar. Kunci partisi dan pengurutan hanya dapat berupa string, angka, atau biner — tanpa peta, tanpa daftar (dokumen AWS).
Kunci sederhana vs kunci komposit
Kunci primer sederhana hanyalah kunci partisi. Ini secara unik mengidentifikasi sebuah
item, dan Anda membacanya kembali dengan GetItem. Itu saja — tidak ada rentang yang terbaca, tidak
"beri aku N terbaru".
Kunci komposit menambahkan kunci pengurutan, dan penambahan tunggal itulah yang menghasilkannya DynamoDB terasa seperti database, bukan peta hash.
| Kunci sederhana | Kunci komposit | |
|---|---|---|
| Atribut | Kunci partisi saja | Kunci partisi + kunci pengurutan |
| Keunikan | Nilai kunci partisi | pasangan nilai |
| Beberapa item per partisi | TIDAK | Ya |
Query rentang | Tidak (hanya GetItem) | Ya (begins_with, between, >) |
| Cocok secara alami | Cari berdasarkan id | Deret waktu, satu-ke-banyak, sejarah |
Modelkan tabel pembacaan sensor
Katakanlah Anda mengumpulkan sampel suhu dari armada sensor lapangan. Akses polanya adalah "dapatkan pembacaan untuk satu perangkat, yang terbaru terlebih dahulu, dalam satu waktu jendela". Itu adalah kunci komposit buku teks.
Gunakan id perangkat sebagai kunci partisi dan stempel waktu pembacaan sebagai kunci pengurutan:
| deviceId | readingTs | tempC | humidity |
|---|---|---|---|
| DEV#a1b2 | 2026-06-23T08:00:00Z | 21.4 | 48 |
| DEV#a1b2 | 2026-06-23T08:05:00Z | 21.7 | 47 |
| DEV#a1b2 | 2026-06-23T08:10:00Z | 22.1 | 46 |
| DEV#c9d8 | 2026-06-23T08:00:00Z | 19.8 | 55 |
Ketiga pembacaan DEV#a1b2 berada di partisi yang sama, disimpan secara fisik
bersama-sama dan diurutkan berdasarkan readingTs.
AWS menyebut kunci partisi sebagai atribut hash dan kunci pengurutan sebagai range atribut — kunci pengurutan adalah rentang yang dapat Anda pindai di dalamnya (Dokumen AWS).
Item diciutkan menjadi satu di bawah setiap partisi kunci:
Satu Query terhadap kunci partisi membaca setiap pembacaan untuk perangkat itu,
sudah dalam urutan stempel waktu — tidak ada penyortiran pada klien, tidak ada perjalanan pulang pergi kedua.
Berapa harga jendela itu
Sepuluh pembacaan pada masing-masing 2 KB di partisi berjumlah 20 KB terukur. Putaran DynamoDB
dibaca per blok 4 KB, jadi Query yang pada akhirnya konsisten pada jendela tersebut memerlukan biaya
3 unit permintaan baca (20 KB → lima blok 4 KB × masing-masing 0,5 RCU). SEBUAH
pembacaan yang sangat konsisten pada jendela yang sama memerlukan biaya 5 unit (satu RCU per blok).
Ambil sepuluh baris yang sama dengan sepuluh panggilan GetItem terpisah dan minimum satu blok
aturan berlaku per item → 5 unit pada akhirnya konsisten, 10 sangat
konsisten — sebelum menghitung perjalanan bolak-balik ekstra.
| Baca pola | Barang | Data tersentuh | Unit baca EC |
|---|---|---|---|
Satu Query, readingTs antara awal dan akhir | 10 | 20 KB | 3 |
10 × GetItem pada kunci komposit penuh | 10 | 20 KB | 5 |
Hanya partisi Query, filter kelembapan di aplikasi | 10 | 20 KB | 3 |
Tabel Scan, filter deviceId + jendela waktu | semua | seluruh meja | berukuran meja |
Lulus ReturnConsumedCapacity: TOTAL saat membuat prototipe; itu
kalkulator harga mengubah jumlah unit tersebut menjadi
item baris bulanan setelah Anda mengetahui permintaan per detik.
Kueri rentangnya, jangan pindai
Karena readingTs adalah string ISO-8601, maka pengurutannya sama secara leksikografis
cara mengurutkannya secara kronologis. Jadi pembacaan jendela waktu adalah rentang kondisi kunci,
bukan filter:
Query
deviceId = "DEV#a1b2"
readingTs BETWEEN "2026-06-23T08:00:00Z" AND "2026-06-23T08:10:00Z"
Itu adalah KeyConditionExpression — ini mempersempit pembacaan sebelum DynamoDB
mengembalikan data, jadi Anda hanya membayar item di jendela. Sebuah FilterExpression
berjalan setelah pembacaan dan menagih Anda untuk semua yang dipindai; itu
Pindai footgun dalam bentuk mini.
Ekspresi itu sendiri, dengan placeholder dan nilai yang diketik, sulit untuk ditulis
dengan tangan. Bangun secara visual dengan
DynamoDB Expression Builder dan salin
KeyConditionExpression yang tepat ke dalam panggilan SDK Anda.
Rancang kunci pengurutan dengan sengaja
Jadi, kunci pengurutan adalah satu-satunya tuas untuk pembacaan rentang bentuk sesuai pertanyaan Anda.
- Gunakan stempel waktu yang dapat diurutkan. String ISO-8601 atau nomor epoch urutkan dengan benar; kurma mentah yang dilokalkan tidak.
- Awali untuk satu-ke-banyak. Seperti kunci pengurutan
READING#2026-06-23T08:00:00Zmemungkinkan Anda menggabungkan tipe entitas dalam satu partisi dan potong denganbegins_with. Itulah jahitannya desain meja tunggal. - Masukkan dimensi kardinalitas tinggi di kunci partisi. ID sensor miliki
ribuan nilai, sehingga penyebaran tulisannya merata. Partisi berkardinalitas rendah
kunci (misalnya,
region) membuat .
Kunci partisi dengan hanya lima puluh nilai berbeda pada 10.000 penulisan per detik aliran terkonsentrasi ~200 WCU per partisi logis sebelum DynamoDB dipecah — baik pada skala prototipe, buruk pada skala produksi. Lebih suka pengidentifikasi itu berkembang bersama armada Anda (id perangkat, id penyewa, id sesi) melalui pengelompokan kasar kecuali Anda dengan sengaja menempatkan kumpulan data yang dibatasi.
Saat kunci komposit menggigit Anda
Kunci komposit adalah sebuah komitmen. Anda memilih kunci partisi, mengirimkan, lalu temukan pola akses yang memerlukan pengelompokan different — "all pembacaan di atas 30°C di seluruh armada".
Tabel dasar tidak dapat menjawabnya; kunci partisi sudah diperbaiki. Pilihan Anda adalah a indeks sekunder global dengan kunci yang berbeda, atau restrukturisasi.
Hitung bacaan Anda sebelum Anda melakukan skema kunci. Mengubah kunci utama
berarti migrasi tabel, bukan ALTER TABLE.
Di DynoTable, buka browser tabel dan periksa tabel kunci komposit secara berdampingan sisi dengan GSI-nya — urutan pengurutan pada tombol pengurutan terlihat baris demi baris, yang mana memperjelas format stempel waktu satu per satu sebelum mencapai produksi.
Langkah selanjutnya
Kunci komposit adalah fondasi pengumpulan item, satu-ke-banyak hubungan, dan desain indeks yang paling berguna — baca desain meja tunggal dan GSI vs LSI selanjutnya untuk melihat arahnya.
Buat sketsa KeyConditionExpression Anda di
DynamoDB Expression Builder, memancarkan secara penuh
Query diberi nomor halaman di pembuat kueri, lalu
coba DynoTable untuk menelusuri partisi Anda yang sebenarnya dan melihat jenisnya
pesanan berbaris di meja Anda sendiri.