Hot Partition DynamoDB

DynamoDB menyebar data Anda ke banyak partition fisik, masing-masing dengan porsi throughput-nya sendiri. Hot partition terjadi saat satu key menarik jauh lebih banyak operasi baca atau tulis daripada yang bisa dilayani porsinya — sehingga permintaan ke key itu ter-throttle sementara sisa tabel menganggur.

Apa itu hot partition DynamoDB?

Hot partition DynamoDB terjadi saat satu partition key menyerap operasi baca atau tulis jauh lebih banyak daripada yang bisa dilayani porsi throughput-nya, sehingga permintaan ke key itu ter-throttle sementara sisa tabel menganggur. Penyebabnya adalah desain key — sebuah item selebritas, key berkardinalitas rendah, tanggal hari ini — bukan ukuran tabel. Obatnya adalah menyebar penulisan.

Penyebabnya adalah desain key, bukan ukuran tabel. Satu partition key yang memusatkan lalu lintas — pengguna selebritas, flag status="OPEN", tanggal hari ini — itulah jebakannya.
Adaptive capacity membantu, tapi bukan solusi tuntas. DynamoDB menyeimbangkan ulang panas secara otomatis, namun satu item atau satu key tetap bisa melampaui apa yang dapat dilayani satu partition.
Obatnya adalah menyebar penulisan. Tambahkan entropi ke key (write sharding) atau pindahkan jalur baca yang panas ke pola akses yang terdistribusi lebih baik.
Datang dari SQL, ini tidak ada padanannya. Tabel relasional tidak mengenal "nilai indeks satu baris terlalu populer" — model throughput-per-key DynamoDB yang datar inilah yang mengenalnya.

Mengapa partition ada sama sekali

DynamoDB adalah pewaris produksi dari paper Amazon Dynamo 2007, yang menukar model SQL satu-node dengan model yang terpartisi dan ter-scale horizontal. Data di-shard berdasarkan hash dari partition key ke seluruh node penyimpanan fisik.

Setiap partition menampung sejumlah data terbatas dan melayani sejumlah throughput terbatas. AWS mendokumentasikan batas keras 3.000 read unit dan 1.000 write unit per partition, per detik (AWS — partition behavior).

Batas itu adalah inti seluruh cerita. Throughput tabel Anda yang disediakan adalah jumlah dari seluruh partition — tapi satu key mana pun hanya akan mendarat di satu partition.

Sebut jebakannya: lalu lintas menumpuk di satu key

Throughput dibagi rata hanya jika akses Anda tersebar merata di seluruh key. Begitu satu key mendapat lalu lintas tidak proporsional, key itu ter-throttle sendirian sementara kapasitas tabel keseluruhan tak terpakai.

Bentuk hot-key klasik:

Sebuah item selebritas — satu pengguna, produk, atau tenant yang dibaca semua orang.
Sebuah partition key berkardinalitas rendah — status, country, type. Sedikit nilai berbeda berarti sedikit partition yang menanggung semua kerja.
Sebuah key ber-bucket waktu — PK = "2026-06-23". Setiap penulisan hari ini menghantam satu partition; partition kemarin dingin selamanya.

Datang dari SQL, tidak satu pun dari ini jadi soal. Indeks B-tree pada nilai populer baik-baik saja. Di DynamoDB nilai populer itu adalah unit penempatan fisik, jadi popularitas menjadi jurang throughput.

Contoh nyata: leaderboard selebritas

Misalkan Anda menjalankan leaderboard game global. Skor disimpan di tabel dengan key seperti ini:

PK = "BOARD#global"
SK = "PLAYER#<playerId>"

Operasi baca mengambil N teratas berdasarkan skor; operasi tulis menaikkan currentScore pemain setelah tiap pertandingan. Setiap baris di papan global berbagi satu partition key — BOARD#global — jadi setiap baca dan tulis mendarat di satu partition.

Tambahkan seorang streamer dengan dua juta penonton langsung yang menggempur tombol refresh pada peringkat mereka sendiri, dan satu partition itu melewati 3.000 read unit. Anda mendapat ProvisionedThroughputExceededException pada papan global sementara setiap papan lain di tabel menganggur.

Bom waktunya adalah keruntuhan BOARD#global: Anda memodelkan satu papan logis sebagai satu key fisik.

Sebar penulisan: sharding pada key

Solusinya adalah memproduksi kardinalitas. Tambahkan shard suffix ke partition key agar satu papan logis menyebar ke N partition fisik:

PK = "BOARD#global#<shard>"  -- shard = playerId mod 10
SK = "PLAYER#<playerId>"

Penulisan kini tersebar ke sepuluh partition, bukan satu — sepuluh kali ruang tulis. Biayanya: membaca seluruh papan harus menjangkau kesepuluh shard lalu menggabungkannya, karena tidak ada satu Query yang melintasi batas shard. Anda menukar kesederhanaan baca demi distribusi tulis.

AWS menyebut ini write sharding dan merekomendasikannya justru untuk key berkecepatan-tinggi dan berkardinalitas-rendah (AWS — using write sharding).

Ini adalah naluri key-overloading yang sama di balik single-table design — Anda membentuk key untuk pola akses, bukan untuk bagaimana data "secara alami" terletak.

Biarkan adaptive capacity mengerjakan bagian mudah

DynamoDB membawa adaptive capacity, dibahas di sesi re:Invent 2018 "Amazon DynamoDB Under the Hood" (DAT401). Ia terus-menerus mendistribusikan ulang throughput tabel ke partition yang sedang panas, dan akan mengisolasi key yang panas secara persisten ke partition-nya sendiri (isolasi setingkat key, AWS — bursting & adaptive capacity).

Ini instan dan gratis — tapi dibatasi fisika. Adaptive capacity bisa memindahkan panas antar key; ia tidak bisa mendorong satu key melewati batas per-partition. Key selebritas sejati tetap ter-throttle. Sharding-lah yang membawa Anda melewati tembok itu.

Berikut jalur keputusan begitu Anda melihat throttle pada key yang sibuk:

Sebagian besar hot partition terselesaikan ke "shard key" atau "biarkan adaptive capacity menyerapnya" — diagram itu hanya menunjukkan Anda ada di cabang yang mana.

Diagnosis sebelum Anda mendesain ulang

Anda tidak bisa memperbaiki yang tidak bisa Anda lihat. Throttling muncul sebagai ProvisionedThroughputExceededException (provisioned) atau sebagai ThrottledRequests dan ThrottleCount per-partition di CloudWatch (AWS — CloudWatch metrics).

Pasangkan itu dengan CloudWatch Contributor Insights for DynamoDB, yang meranking key Anda yang paling sering diakses secara langsung — cara tercepat mengonfirmasi key selebritas berdasarkan namanya (AWS — Contributor Insights).

Saat Anda menguji jalur baca yang ter-shard, Anda akan menyusun sendiri KeyConditionExpression untuk tiap shard. Hasilkan itu tanpa salah ketik dengan DynamoDB Expression Builder — ia mengeluarkan bentuk PK = :pk AND begins_with(SK, :sk) yang tepat per shard.

Jebakan yang harus dihindari

Key auto-increment atau monoton. ID berurutan dan timestamp sebagai partition key merutekan penulisan berurutan ke partition yang sama. Tambahkan prefix hash.
Sharding jalur read-heavy secara tak perlu. Jika baca mendominasi dan item-nya kecil, sebuah cache atau GSI dengan key yang terdistribusi lebih baik sering mengalahkan biaya baca scatter-gather dari sharding.
Mengacaukan hot partition dengan Scan lambat. Sebuah Scan lambat karena membaca segalanya; sebuah hot partition ter-throttle karena satu key kelebihan beban. Masalah berbeda — lihat Query vs Scan.

Langkah berikutnya

Sketsakan key yang ter-shard, lalu buktikan jalur bacanya terhadap data nyata. Bangun kondisi per-shard di DynamoDB Expression Builder, dan unduh DynoTable untuk menjalankannya terhadap tabel Anda sendiri dan amati partition mana yang sebenarnya menanggung panas.