Adaptive capacity DynamoDB

DynamoDB menyebar tabel Anda di seluruh partition, tapi lalu lintas Anda jarang tersebar merata. Burst capacity dan adaptive capacity adalah dua mekanisme otomatis yang menghentikan beban kerja yang miring dari ter-throttle — sampai ia mengenai batas keras.

Apa itu adaptive capacity DynamoDB?

Adaptive capacity DynamoDB adalah mekanisme otomatis yang mengalihkan throughput tak terpakai ke sebuah partition panas sehingga key yang miring tidak ter-throttle sementara sisa tabel duduk menganggur. Dipadukan dengan burst capacity, ia menyerap lonjakan dan kemiringan berkelanjutan secara gratis — tapi ia tak bisa mendorong sebuah key tunggal melewati plafon partition.

• Burst capacity meminjamkan Anda hingga 5 menit (300 detik) throughput tak terpakai untuk melewati lonjakan singkat. Ia sebuah buffer, bukan fitur yang Anda setel.
• Adaptive capacity secara otomatis menaikkan throughput untuk partition "panas" — menarik dari sisa kapasitas tak terpakai tabel Anda — sehingga key yang miring tidak ter-throttle.
• Ia bahkan akan mengisolasi sebuah Item panas ke partition-nya sendiri, memberi satu key hingga plafon partition 3.000 RCU / 1.000 WCU.
• Ia bukan lisensi untuk mengabaikan desain key. Melewati plafon per-partition tak ada lagi tempat untuk meminjam — sebuah key yang benar-benar panas tetap ter-throttle.

Ketahui plafon partition terlebih dahulu

Setiap partition dibatasi secara independen: 3.000 read unit dan 1.000 write unit per detik. Batas itu fisik, bukan diprovisioning — ia berlaku pada tabel provisioned maupun on-demand. (AWS, Burst and adaptive capacity.)

Datang dari SQL, Anda menalar tentang beban server total. Di DynamoDB unit yang ter-throttle adalah partition tunggal, dan satu key yang miring bisa meleleh sementara tabel duduk 90% menganggur. Itulah celah yang ada untuk ditutup oleh kedua mekanisme.

Burst capacity menyerap lonjakan singkat

Kapan pun Anda tidak sepenuhnya menggunakan throughput sebuah partition, DynamoDB menabung sisanya. Hingga 300 detik kapasitas tak terpakai itu disimpan sebagai cadangan, dan sebuah lonjakan tiba-tiba bisa mengurasnya lebih cepat daripada yang biasanya diizinkan oleh laju per-detik Anda.

Ia tak terlihat dan otomatis. Anda tidak bisa mengukurnya, dan DynamoDB mungkin diam-diam menghabiskan sebagian untuk pekerjaan latarnya sendiri. Perlakukan ia sebagai bantalan untuk lalu lintas yang bursty — jangan pernah sebagai headroom yang bisa Anda rencanakan.

Adaptive capacity mendorong hot partition

Burst capacity menangani lonjakan singkat. Adaptive capacity menangani kemiringan berkelanjutan. Saat satu partition berjalan panas sementara tetangganya menganggur, DynamoDB mengalihkan throughput ke yang panas — hingga total tabel dan plafon partition.

Misalkan Anda menjalankan sebuah tabel telemetri-armada yang di-key VEHICLE#<id> (partition) dan TS#<epoch> (sort). Satu van pengantar di zona flash-sale memancarkan 10× ping dari yang lain. Partition-nya panas; partition 200 van lainnya duduk nyaris menganggur.

Adaptive capacity menyadari dan mengangkat throughput satu partition itu, menarik dari kapasitas tak terpakai partition dingin. Tanpa config, tanpa biaya, tanpa warm-up — sejak Mei 2019 dorongan itu efektif seketika. (AWS Database Blog, "How DynamoDB adaptive capacity accommodates uneven access patterns".)

Partition van panas butuh 150 WCU tapi bagian rata-nya 100 WCU akan ter-throttle; adaptive capacity meminjam WCU menganggur dari partition dingin untuk menutupinya.

Isolasi: saat satu Item adalah masalahnya

Kemiringan tidak selalu per-key — kadang sebuah Item tunggal membara putih. Jika lalu lintas tanpa henti menggerakkan satu Item VEHICLE#HOT, split-for-heat DynamoDB menyeimbangkan ulang partition sehingga Item yang sering diakses mendarat sendirian.

Setelah terisolasi, key Item tunggal itu bisa menarik plafon partition penuh: 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 layak disematkan: adaptive capacity tidak akan membagi sebuah item collection ke beberapa partition saat tabel memiliki Local Secondary Index. Sebuah LSI mengikat collection ke satu partition — lihat GSI vs LSI untuk alasannya.

Saat adaptive capacity tak bisa menyelamatkan Anda

Inilah jebakannya. Kedua mekanisme memindahkan throughput berkeliling; keduanya tidak menciptakan lebih dari yang diizinkan sebuah partition secara fisik.

Jika satu key memang sah membutuhkan lebih dari 1.000 tulisan per detik, tak ada mekanisme otomatis yang menyelamatkan Anda — Anda harus menyebar beban ke lebih banyak key.

Write sharding adalah solusi yang biasa: tambahkan suffix (VEHICLE#HOT#0 … #9) sehingga tulisan menyebar ke seluruh partition, lalu kumpulkan pembacaan kembali.

Pengumpulan-kembali itu sendiri adalah pola akses untuk dimodelkan secara sengaja, sama seperti Anda merencanakan jalur query di single-table design — adaptive capacity membeli waktu, bukan tiket gratis pada desain key.

Lihat di tabel Anda sendiri

Adaptive capacity tak terlihat secara desain, jadi Anda menalarnya melalui satu gejala: key mana yang panas. Saat Anda membangun jalur tulisan ter-shard, Expression Builder menghasilkan sintaks PutItem dan Query untuk key ber-suffix.

Untuk menyaksikan bagaimana sebuah key sebenarnya terdistribusi di seluruh data Anda, unduh DynoTable dan periksa penyebaran partition pada tabel nyata Anda sebelum Anda berasumsi adaptive capacity sudah mengatasinya. Untuk sisi baca dari kemiringan, lihat Query vs Scan.