Cara Kerja Partition Key DynamoDB

Partition key Anda bukanlah sebuah kolom — ia adalah sebuah alamat. DynamoDB meng-hash key itu dan hash menentukan mesin fisik mana yang menyimpan Item. Pilih key dengan baik dan beban tersebar; pilih dengan buruk dan satu server menanggung panasnya.

Bagaimana cara kerja partition key DynamoDB?

DynamoDB menjalankan partition key Anda melalui fungsi hash internal, dan hash tersebut menentukan partition fisik mana yang menyimpan Item. Key tidak diurutkan atau di-index seperti kolom SQL — ia adalah sebuah alamat. Pilih key ber-cardinality-tinggi dan beban tersebar ke banyak partition; pilih yang ber-cardinality-rendah dan satu partition menanggung semua beban.

• Key di-hash, bukan diurutkan. DynamoDB menjalankan partition key Anda melalui hash internal untuk memilih sebuah partition. Dua nilai yang berdekatan mendarat jauh dari satu sama lain di disk.
• Sebuah partition adalah unit penyimpanan nyata. Masing-masing mentok di sekitar 10 GB, 3.000 read unit/detik dan 1.000 write unit/detik. Lalu lintas Anda dibagi oleh berapa banyak partition tempat key Anda tersebar.
• Hot key adalah footgun-nya. Salurkan sebagian besar request ke satu nilai partition-key dan Anda ter-throttle pada partition itu sementara sisa tabel menganggur.
• Key ber-cardinality-tinggi menang. Semakin banyak nilai key yang berbeda dan ter-hit merata yang Anda miliki, semakin banyak partition yang menyerap beban.

Mulai dengan apa yang sebenarnya dilakukan key

Datang dari SQL, primary key adalah kolom yang terurut dan ter-index yang Anda JOIN dan ORDER BY. Di DynamoDB partition key (kadang disebut hash key) melakukan sesuatu yang berbeda: ia menentukan penempatan.

DynamoDB memberi makan partition key ke sebuah fungsi hash internal. Outputnya memetakan ke sebuah keyspace, dan keyspace dipotong menjadi rentang — setiap rentang dimiliki oleh sebuah partition fisik. Partition itu adalah penyimpanan nyata di node nyata.

Jadi partition key menjawab satu pertanyaan: mesin mana yang menampung Item ini? Sort key, jika Anda punya, hanya mengurutkan Item dalam mesin itu. Ia tidak berperan dalam penempatan.

Ikuti satu tulisan melalui hash

Misalkan Anda menjalankan sebuah SaaS yang menelan pembacaan perangkat. Tabel Anda SensorReadings menggunakan partition key deviceId dan sort key readingTs. Anda menulis sebuah pembacaan untuk deviceId = "vac-7741".

Berikut jalur yang ditempuh tulisan itu — dari key Anda ke disk tempatnya mendarat:

Tulisan untuk vac-7741 di-hash ke sebuah titik di keyspace, titik itu jatuh dalam rentang P2, dan Item mendarat di P2 — diurutkan di sana oleh readingTs.

Hal yang perlu diinternalisasi: "vac-7741" dan "vac-7742" hanya berbeda satu karakter, tapi hash-nya tak berkaitan. Mereka hampir pasti tinggal di partition berbeda. Tak ada "berdekatan" di keyspace partition.

Ini adalah gagasan consistent-hashing yang diwarisi DynamoDB dari desain aslinya — paper Amazon Dynamo 2007 ("Dynamo: Amazon's Highly Available Key-value Store") menyebar key di antara node dengan meng-hash persis agar tak ada node tunggal yang menjadi bottleneck.

Hormati batas keras partition

Sebuah partition fisik itu terhingga. Menurut AWS DynamoDB Developer Guide, masing-masing menampung hingga sekitar:

Saat sebuah partition terisi melewati 10 GB, atau kebutuhan throughput yang diprovisioning butuh lebih banyak ruang, DynamoDB memecahnya — rentang keyspace dibagi dan Item didistribusikan ulang ke lebih banyak partition. Ini otomatis; Anda tidak memicunya.

Tangkapannya: sebuah pemecahan menyebar Item berdasarkan hash-nya. Jika setiap request panas menargetkan satu nilai partition-key, pemecahan tidak membantu — semua lalu lintas itu tetap di-hash ke titik yang sama. Anda tidak bisa memecah beban satu key tunggal ke beberapa partition.

Sebut jebakannya: hot partition

Sebuah hot partition adalah footgun klasik. Ia terjadi ketika satu nilai partition-key (atau himpunan kecil darinya) menyerap bagian lalu lintas yang tidak proporsional.

Kegagalan konkret: Anda mengganti SensorReadings ke partition key region dengan nilai seperti "us-east", "eu-west". Tiga region berarti tiga nilai key berarti — paling banyak — tiga partition yang melakukan pekerjaan nyata. Hantam "us-east" dengan pembacaan dan ia ter-throttle pada 3.000 RCU sementara total kapasitas provisioning tabel menganggur.

Adaptive capacity DynamoDB melunakkan ini — ia bisa mengalihkan throughput yang tak terpakai ke partition yang sibuk, dan mengisolasi satu key yang sangat panas ke partition-nya sendiri. AWS merinci ini dalam sesi mendalam re:Invent "Advanced Design Patterns for DynamoDB". Tapi adaptive capacity membeli waktu, bukan kekebalan: ia tidak bisa membagi beban satu key individual. Rancang untuk penyebaran; jangan bersandar pada jaring pengaman.

Pilih key ber-cardinality-tinggi

Solusinya adalah cardinality — jumlah nilai key yang berbeda, dan seberapa merata lalu lintas mengenainya.

• Cardinality rendah (region, status, true/false): sedikit partition, lalu lintas terkonsentrasi, Anda ter-throttle dini.
• Cardinality tinggi (deviceId, userId, sebuah order ID): banyak nilai yang di-hash ke banyak partition, beban tersebar, headroom tumbuh.

Datang dari SQL Anda akan dengan senang hati meng-index kolom status dan memfilter padanya. Sebagai partition key DynamoDB itu jebakan — ia tidak bisa tersebar. Jaga atribut ber-cardinality-rendah sebagai filter atau sebagai sort key dari index sekunder, jangan pernah sebagai hal yang menentukan penempatan.

Saat sebuah key yang secara alami baik tetap miring — segelintir tenant paus mengungguli sisanya — tambahkan suffix untuk menyebar satu nilai logis ke N partition, mis. tenantId#3 untuk jalur tulisan ter-shard. Anda meng-agregat ulang saat pembacaan.

Untuk menargetkan Item dalam sebuah partition setelah key Anda tersebar, Anda akan menulis sebuah KeyConditionExpression pada sort key. Anda bisa menyusunnya terhadap schema Anda sendiri di DynamoDB expression builder sebelum menyambungkannya ke kode:

deviceId = "vac-7741" AND readingTs BETWEEN "2026-06-01" AND "2026-06-30"

Itu membaca jendela Juni satu perangkat dari satu partition — sebuah Query, bukan Scan. Partition key menyematkan mesin; condition sort-key mempersempit baris.

Jebakan dan langkah berikutnya

• Jangan pilih key berdasarkan apa yang enak dibaca di SQL. Pilih berdasarkan apa yang tersebar. Cardinality dulu, kemudahan query kedua.
• Jangan asumsikan total kapasitas tabel milik Anda per key. Throughput bersifat per-partition; satu nilai panas bisa ter-throttle sementara tabel tampak menganggur.
• Jangan lawan sebuah pemecahan. Ia otomatis dan digerakkan-hash — tugas Anda adalah memberinya cukup key berbeda untuk tersebar.

Begitu key Anda tersebar dengan bersih, keputusan berikutnya adalah cara menata Item di dalam sebuah partition — lihat single-table design — dan kapan sebuah index sekunder adalah alat yang tepat untuk pola akses kedua.

Unduh DynoTable untuk menjelajahi partition nyata dan distribusi key Anda, serta menemukan hot key sebelum ia membangunkan Anda.