DynamoDB On-Demand vs Provisioned Capacity

DynamoDB menagih throughput dengan dua cara. On-Demand menagih per request — Anda membayar untuk apa yang Anda gunakan, menskala ke nol. Provisioned mencadangkan laju baca/tulis tetap yang Anda bayar entah Anda gunakan atau tidak, dengan harga per unit yang jauh lebih rendah. Memilih yang salah adalah salah satu cara termudah untuk membayar lebih.

Audit log membuat pilihannya konkret. Penulisan audit bersifat melonjak dan tak terprediksi: sepi semalaman, lalu banjir saat seorang pelanggan menjalankan operasi massal atau sebuah insiden menghasilkan ribuan event. Bentuk trafik itulah seluruh keputusannya.

Haruskah saya menggunakan kapasitas DynamoDB On-Demand atau Provisioned?

On-Demand menagih per request dan menskala ke nol, menjadikannya pilihan default yang aman untuk trafik yang melonjak, baru, atau tidak dapat diprediksi. Provisioned mencadangkan laju baca/tulis tetap dengan harga per unit yang jauh lebih rendah, dan lebih menguntungkan hanya jika trafik yang stabil dan berkelanjutan menjaga cadangan tersebut termanfaatkan dengan baik. Pilih On-Demand kecuali volume Anda sudah terbukti dan dapat diprediksi.

• On-Demand = bayar per request, menskala ke nol. Tidak ada kapasitas untuk direncanakan; Anda membayar harga lebih tinggi per baca/tulis tetapi hanya saat trafik terjadi.
• Provisioned = cadangkan laju stabil, selalu bayar untuk itu. Jauh lebih murah per unit jika lajunya termanfaatkan baik; Anda menanggung biaya kapasitas menganggur.
• Trafik melonjak / tidak diketahui → On-Demand. Trafik stabil, dapat diprediksi, bervolume tinggi → Provisioned (opsional dengan auto-scaling).
• Anda dapat beralih mode, tetapi hanya sejumlah terbatas kali per 24 jam — ini bukan toggle per request.

Masalahnya: membayar kapasitas yang tidak Anda gunakan

Dengan Provisioned capacity Anda berkomitmen pada, katakanlah, 1.000 write unit per detik. Jika audit log rata-rata 50 penulisan/detik tetapi Anda menyediakan untuk puncak hari insiden, Anda membayar untuk 1.000 sepanjang waktu dan menggunakan seperdua puluhnya. Sediakan untuk rata-rata saja dan banjir hari insiden men-throttle — penulisan ditolak.

Jadi kapasitas tetap memaksa trade-off buruk pada trafik melonjak: terus membayar lebih, atau kurang-menyediakan dan menjatuhkan penulisan saat itu paling penting. On-Demand ada justru untuk menghilangkan trade-off itu.

Cara kerja dua mode

On-Demand menagih untuk read dan write request unit yang benar-benar Anda konsumsi, tanpa kapasitas untuk dikonfigurasi — ia langsung mengakomodasi lonjakan trafik dan menskala ke nol saat menganggur. Anda membayar premium per request untuk elastisitas itu.

Provisioned mencadangkan sejumlah Read Capacity Unit (RCU) dan Write Capacity Unit (WCU) per detik. Harga per unit jauh lebih rendah, tetapi Anda membayar cadangan secara terus-menerus, digunakan atau tidak. Melebihinya dan DynamoDB men-throttle kecuali auto-scaling diaktifkan untuk menumbuhkan kapasitas dalam batas yang dikonfigurasi — meskipun auto-scaling bereaksi dalam hitungan menit, jadi lonjakan tiba-tiba masih bisa men-throttle sebelum ia mengejar.

Persimpangannya adalah utilisasi. Kira-kira: jika trafik berkelanjutan dan dapat diprediksi Anda menjaga Provisioned capacity termanfaatkan baik, Provisioned menang dalam harga; jika trafik melonjak, bursty, atau tidak diketahui, On-Demand menang dengan tidak menagih untuk cadangan menganggur.

Contoh terkerjakan: tagihan audit log

Audit log menulis ~50 event/detik rata-rata tetapi meledak hingga ribuan selama insiden, dengan trafik baca jauh lebih rendah (ekspor kepatuhan, investigasi sesekali). Setiap event kecil — jauh di bawah 1 KB.

Pada Provisioned, Anda harus mencadangkan untuk ledakan (membayarnya 24/7) atau berisiko men-throttle banjir hari insiden — saat terburuk untuk menjatuhkan penulisan audit. Pada On-Demand, jam-jam sepi nyaris tidak berbiaya dan ledakannya diserap otomatis; Anda membayar persis untuk penulisan yang terjadi.

Untuk workload ini On-Demand adalah default yang tepat. Aturan umumnya: mulai dengan On-Demand untuk tabel baru atau melonjak mana pun, dan baru pindah ke Provisioned begitu trafik terbukti cukup stabil untuk menjaga cadangan termanfaatkan.

Masukkan angka Anda sendiri — baca/tulis per detik, ukuran Item, penyimpanan — untuk melihat kedua mode berdampingan untuk satu region:

Untuk gambaran multi-region penuh dengan free tier diterapkan, gunakan Kalkulator Harga DynamoDB.

Lakukan di DynoTable

Keputusan kapasitas dimulai dari angka nyata: seberapa besar Item-nya, berapa banyak yang ada, seberapa cepat mereka ditulis. Menebak itu adalah cara tabel berakhir salah-disediakan.

Untuk mengubah event sampel menjadi RCU/WCU yang benar-benar dikonsumsinya, jalankan melalui kalkulator ukuran Item. Kemudian dasarkan keputusan pada tabel nyata Anda: DynoTable menampilkan metadatanya — jumlah dan ukuran Item — dan memungkinkan Anda memeriksa Item representatif sehingga Anda dapat mengukurnya secara akurat.

Jebakan dan langkah berikutnya

• Beralih mode dibatasi laju. Anda dapat mengubah antara On-Demand dan Provisioned, tetapi hanya sejumlah terbatas kali per 24 jam — perlakukan sebagai keputusan yang dipertimbangkan, bukan dial yang Anda putar.
• Auto-scaling tidak instan. Ia bereaksi dalam hitungan menit, jadi lonjakan tajam pada Provisioned bisa men-throttle sebelum kapasitas tumbuh. Untuk trafik yang benar-benar bursty, On-Demand menyerap lonjakan secara langsung.
• Sebuah hot partition men-throttle terlepas dari mode. Bahkan On-Demand punya batas per partisi — key yang tidak merata bisa men-throttle sementara tabel tampak di bawah kapasitas. Lihat hot partition.
• GSI punya kapasitasnya sendiri. Setiap index ditagih terpisah dan dapat men-throttle penulisan tabel dasar jika kurang-disediakan — lihat mengapa sebuah GSI men-throttle penulisan tabel dasar.

Mode kapasitas menetapkan apa yang Anda bayar untuk menjalankan tabel di satu region. Berikutnya: mereplikasinya lintas region dengan DynamoDB Global Tables.

Unduh DynoTable untuk membaca ukuran dan jumlah Item nyata tabel Anda sebelum Anda berkomitmen pada mode kapasitas.