Adaptive Capacity DynamoDB: Apa yang Bisa dan Tidak Bisa
DynamoDB menyebar tabel Anda ke seluruh partisi, tetapi trafik Anda jarang menyebar merata. Burst capacity dan adaptive capacity adalah dua mekanisme otomatis yang menghentikan beban kerja yang miring dari throttling — sampai ia mengenai batas keras.
Apa itu DynamoDB adaptive capacity?
DynamoDB adaptive capacity adalah mekanisme otomatis yang menggeser throughput yang tak terpakai ke arah agar key yang miring tak ter-throttle sementara sisa tabel menganggur. Dipasangkan dengan burst capacity, ia menyerap lonjakan dan kemiringan berkelanjutan secara gratis — tetapi ia tak bisa mendorong satu key melewati plafon partisi.
- Burst capacity meminjamkan hingga 5 menit (300 detik) throughput yang tak terpakai untuk mengendarai lonjakan singkat. Ia buffer, bukan fitur yang Anda setel.
- Adaptive capacity otomatis menaikkan throughput untuk — menarik dari sisa kapasitas tabel Anda yang tak terpakai — agar key yang miring tak ter-throttle.
- Ia bahkan akan mengisolasi Item panas ke partisinya sendiri, memberi satu key hingga plafon partisi 3.000 RCU / 1.000 WCU.
- Ini bukan lisensi untuk mengabaikan desain key. Melewati plafon per-partisi tak ada lagi tempat untuk meminjam — key yang benar-benar panas tetap ter-throttle.
Ketahui plafon partisi dulu
Setiap partisi dibatasi secara independen: 3.000 read unit dan 1.000 write unit per detik. Batas itu fisik, bukan diprovisikan — ia berlaku pada tabel provisioned maupun on-demand. (AWS, Burst and adaptive capacity.)
Datang dari SQL, Anda menalar beban server total. Di DynamoDB unit yang ter-throttle adalah partisi tunggal, dan satu key yang miring bisa meleleh sementara tabelnya menganggur 90%. Itulah kesenjangan yang menjadi alasan keberadaan kedua mekanisme.
Burst capacity menyerap lonjakan singkat
Kapan pun Anda tak sepenuhnya memakai throughput sebuah partisi, DynamoDB menabung sisanya. Hingga 300 detik kapasitas tak terpakai itu disimpan sebagai cadangan, dan burst mendadak bisa mengurasnya lebih cepat dari yang biasanya diizinkan laju per-detik Anda.
Ia tak terlihat dan otomatis. Anda tak bisa mengukurnya, dan DynamoDB mungkin diam-diam membelanjakan sebagiannya untuk kerja latar belakangnya sendiri. Perlakukan ia sebagai bantalan untuk trafik bergelombang — jangan pernah sebagai ruang lega yang bisa Anda rencanakan.
Adaptive capacity mendongkrak hot partition
Burst capacity menangani lonjakan singkat. Adaptive capacity menangani kemiringan berkelanjutan. Saat satu partisi berjalan panas sementara tetangganya menganggur, DynamoDB menggeser throughput ke arah yang panas — hingga total tabel dan plafon partisi.
Katakan Anda menjalankan tabel telemetri armada berkunci VEHICLE#<id> (partisi) dan
TS#<epoch> (sort). Satu van pengiriman di zona flash-sale memancarkan 10× ping van mana
pun lainnya. Partisinya panas; partisi 200 van lainnya nyaris menganggur.
Adaptive capacity menyadarinya dan mengangkat throughput satu partisi itu, menarik dari kapasitas tak terpakai partisi dingin. Tanpa konfigurasi, tanpa biaya, tanpa pemanasan — sejak Mei 2019 dongkrakan itu efektif seketika. (AWS Database Blog, "How DynamoDB adaptive capacity accommodates uneven access patterns".)
Partisi van panas butuh 150 WCU tetapi porsi meratanya 100-WCU akan ter-throttle; adaptive capacity meminjam WCU menganggur dari partisi dingin untuk menutupinya.
Isolasi: saat satu Item adalah masalahnya
Kemiringan tak selalu per-key — kadang satu Item yang membara. Jika trafik tanpa henti
menggerakkan satu Item VEHICLE#HOT, split-for-heat DynamoDB menyeimbangkan ulang
partisi sehingga Item yang sering diakses mendarat sendirian.
Setelah terisolasi, key satu Item itu bisa menarik penuh plafon partisi: 3.000 RCU dan 1.000 WCU. Itu atap absolut untuk satu key — tak ada mekanisme di atasnya. (AWS, Key range throughput exceeded.)
Satu peringatan yang patut dipaku: adaptive capacity tak akan memecah lintas partisi saat tabel punya . LSI mengikat koleksi ke satu partisi — lihat GSI vs LSI untuk alasannya.
Saat adaptive capacity tak bisa menyelamatkan Anda
Ini jebakannya. Kedua mekanisme memindahkan throughput di sekitar; tak satu pun menciptakan lebih dari yang secara fisik diizinkan sebuah partisi.
| Skenario | Burst | Adaptive | Hasil |
|---|---|---|---|
| Lonjakan singkat, tabel punya kelegaan | Menutupinya | — | Tak ada throttle |
| Kemiringan berkelanjutan, tetangga dingin | — | Mendongkrak panas | Tak ada throttle |
| Satu Item, < 3K RCU / 1K WCU | — | Mengisolasinya | Tak ada throttle |
| Satu Item, > plafon partisi | Terkuras cepat | Di atap | Ter-throttle — perlu desain ulang |
| Banyak key panas sekaligus, tabel maks | Terkuras cepat | Tak ada menganggur | Ter-throttle — perlu desain ulang |
Jika satu key secara sah butuh lebih dari 1.000 penulisan per detik, tak ada mekanisme otomatis yang menyelamatkan Anda — Anda harus menyebar beban ke lebih banyak key.
Write sharding adalah perbaikan yang biasa: tambahkan sufiks (VEHICLE#HOT#0 … #9)
agar penulisan menyebar ke seluruh partisi, lalu satukan kembali pembacaannya.
Fan-in itu sendiri adalah pola akses untuk dimodelkan secara sengaja, sama seperti Anda merencanakan jalur query di desain tabel tunggal — adaptive capacity membeli waktu, bukan tiket gratis untuk desain key.
Lihat pada tabel Anda sendiri
Adaptive capacity tak terlihat secara desain, jadi Anda menalarnya melalui satu gejala:
key mana yang panas. Saat Anda membangun jalur tulis ter-shard,
Expression Builder menghasilkan sintaks PutItem
dan Query untuk key bersufiks.
Untuk mengamati bagaimana sebuah key sebenarnya terdistribusi di data Anda, unduh DynoTable dan jalankan GROUP BY atas partition key Anda di SQL Workbench untuk melihat bagaimana Item menumpuk per key sebelum Anda mengasumsikan adaptive capacity sudah menanganinya. Untuk sisi baca dari kemiringan, lihat Query vs Scan.