Pemula7 menit baca

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 Query mengembalikan suatu rentang (>=, between, begins_with) bukan satu item, tanpa Scan.
  • 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 sederhanaKunci komposit
AtributKunci partisi sajaKunci partisi + kunci pengurutan
KeunikanNilai kunci partisipasangan nilai
Beberapa item per partisiTIDAKYa
Query rentangTidak (hanya GetItem)Ya (begins_with, between, >)
Cocok secara alamiCari berdasarkan idDeret 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:

deviceIdreadingTstempChumidity
DEV#a1b22026-06-23T08:00:00Z21.448
DEV#a1b22026-06-23T08:05:00Z21.747
DEV#a1b22026-06-23T08:10:00Z22.146
DEV#c9d82026-06-23T08:00:00Z19.855

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:

Partisi: DEV#a1b2membacaTs 08:00membacaTs 08:05membacaTs 08:10Permintaan ID perangkat =DEV#a1b2

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 polaBarangData tersentuhUnit baca EC
Satu Query, readingTs antara awal dan akhir1020 KB3
10 × GetItem pada kunci komposit penuh1020 KB5
Hanya partisi Query, filter kelembapan di aplikasi1020 KB3
Tabel Scan, filter deviceId + jendela waktusemuaseluruh mejaberukuran 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:00Z memungkinkan Anda menggabungkan tipe entitas dalam satu partisi dan potong dengan begins_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.

Diperbarui