View a markdown version of this page

3- Batas akun terlampaui - Amazon DynamoDB
Batas akun melebihi langkah-langkah mitigasiDiagnosis dan pemantauan umumProsedur resolusi

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

3- Batas akun terlampaui

On-demand tabel tidak memiliki tingkat kapasitas yang disediakan untuk dikelola, tetapi DynamoDB memberlakukan batas throughput tingkat akun untuk mencegah eksekusi yang tidak terkendali dan memastikan penggunaan sumber daya yang wajar di semua pelanggan. Batas akun per tabel ini berfungsi sebagai perlindungan yang dapat disesuaikan, ditetapkan untuk setiap akun dan kombinasi Wilayah. Ketika tingkat konsumsi baca atau tulis Anda melebihi batas ini, DynamoDB mengembalikan jenis alasan pembatasan dalam pengecualian AccountLimitExceeded throttling. Batas akun per tabel default diterapkan secara otomatis ketika tabel tidak memiliki pengaturan throughput maksimum kustom yang dikonfigurasi. Secara opsional, Anda dapat mengonfigurasi pengaturan throughput maksimum untuk kontrol biaya dan prediktabilitas yang lebih baik, atau meminta peningkatan kuota melalui Kuota di Amazon DynamoDB konsol jika persyaratan aplikasi Anda melebihi batas default.

Batas akun melebihi langkah-langkah mitigasi

Bagian ini memberikan panduan resolusi untuk skenario pelambatan batas akun. Sebelum menggunakan panduan ini, pastikan Anda telah mengidentifikasi alasan pelambatan spesifik dari penanganan pengecualian aplikasi Anda, dan menentukan Nama Sumber Daya Amazon (ARN) dari sumber daya yang terpengaruh. Untuk informasi tentang mengambil alasan pelambatan dan mengidentifikasi sumber daya yang dibatasi, lihat. Kerangka diagnosis pelambatan DynamoDB

Sebelum menyelami skenario pelambatan tertentu, pertama-tama tentukan apakah tindakan benar-benar diperlukan:

  • Mengevaluasi dampak kinerja: Periksa apakah aplikasi Anda masih memenuhi persyaratan kinerjanya meskipun ada pelambatan. Banyak aplikasi berhasil beroperasi pada atau mendekati batas akun, terutama selama operasi massal atau migrasi data.

  • Tinjau pola pelambatan: Jika throttling terputus-putus dan aplikasi Anda menangani percobaan ulang secara efektif, batas saat ini mungkin cukup untuk beban kerja Anda.

Jika aplikasi Anda bekerja dengan baik bahkan ketika kadang-kadang mencapai batas akun, Anda dapat memilih untuk hanya memantau situasi daripada menerapkan perubahan segera.

Jika Anda menentukan bahwa throttling menyebabkan masalah kinerja atau masalah keandalan yang tidak dapat diterima, pilih alasan pelambatan tertentu di bawah ini untuk menemukan opsi mitigasi yang disarankan:

TableReadAccountLimitExceeded

Ketika ini terjadi

Konsumsi baca tabel Anda telah melebihi kuota throughput pembacaan per tabel tingkat akun untuk Wilayah Anda. Anda dapat memantau CloudWatch metrik Diagnosis dan pemantauan umum untuk menganalisis peristiwa pelambatan Anda.

Pendekatan resolusi

Gunakan langkah-langkah berikut untuk mengatasi pelambatan ini:

  • Permintaan kenaikan kuota:

    Minta peningkatan batas throughput baca per tabel (kode kuota L-CF0CBE56). Untuk langkah-langkah terperinci tentang cara mengirimkan permintaan, lihat Meminta kenaikan kuota per tabel.

TableWriteAccountLimitExceeded

Ketika ini terjadi

Konsumsi tulis tabel Anda telah melebihi kuota throughput penulisan per tabel tingkat akun untuk Wilayah Anda. Anda dapat memantau CloudWatch metrik Diagnosis dan pemantauan umum untuk menganalisis peristiwa pelambatan Anda.

Pendekatan resolusi

Gunakan langkah-langkah berikut untuk mengatasi pelambatan ini:

  • Permintaan kenaikan kuota: Meminta peningkatan batas throughput penulisan per tabel (kode kuota L-AB614373). Untuk langkah-langkah terperinci tentang cara mengirimkan permintaan, lihat Meminta kenaikan kuota per tabel.

IndexReadAccountLimitExceeded

Ketika ini terjadi

Operasi baca yang diarahkan pada Indeks Sekunder Global (GSI) menghabiskan lebih banyak throughput daripada yang diizinkan kuota baca per tabel akun Anda di Wilayah Anda saat ini AWS . Kuota throughput baca per tabel tingkat akun berlaku secara kolektif ke tabel dan semua GSI digabungkan. Anda dapat memantau CloudWatch metrik Diagnosis dan pemantauan umum untuk menganalisis peristiwa pelambatan Anda.

Pendekatan resolusi

Pilih resolusi yang sesuai berdasarkan distribusi kapasitas akun Anda:

  • Minta kenaikan kuota: Meminta peningkatan batas throughput baca per tabel (kode kuota L-CF0CBE56). Untuk langkah-langkah terperinci tentang cara mengirimkan permintaan, lihat Meminta kenaikan kuota per tabel.

  • Optimalkan penggunaan GSI: T injau desain GSI dan pola kueri untuk mengurangi konsumsi kapasitas baca yang tidak perlu.

IndexWriteAccountLimitExceeded

Ketika ini terjadi

Penulisan operasi ke tabel dasar menghasilkan pembaruan yang sesuai untuk GSI yang secara kolektif melebihi kuota throughput penulisan per tabel tingkat akun untuk Wilayah Anda. AWS Setiap penulisan ke item tabel dasar yang berisi atribut yang diindeks oleh GSI memicu operasi penulisan yang sesuai dengan GSI tersebut. Operasi penulisan gabungan ini diperhitungkan dalam kuota throughput penulisan per tabel Anda. Anda dapat memantau CloudWatch metrik Diagnosis dan pemantauan umum untuk menganalisis pola dan waktu peristiwa pelambatan ini dan mengidentifikasi operasi mana yang menyebabkan aktivitas penulisan GSI yang berlebihan.

Pendekatan resolusi

Pilih resolusi yang sesuai berdasarkan distribusi kapasitas akun Anda:

  • Peningkatan kuota permintaan: Minta peningkatan batas throughput pen ulisan per tabel (kode kuota L-AB614373) untuk mengakomodasi lalu lintas tulis GSI yang lebih tinggi dari operasi tabel dasar. Kuota throughput penulisan per tabel berlaku untuk seluruh tabel, termasuk semua GSI-nya. Untuk langkah-langkah terperinci tentang cara mengirimkan permintaan, lihat Meminta kenaikan kuota per tabel.

  • Optimalkan proyeksi GSI: T injau proyeksi dan desain GSI untuk mengurangi volume penulisan ke GSI.

Diagnosis dan pemantauan umum

Saat pemecahan masalah batas akun melebihi peristiwa pelambatan, beberapa CloudWatch metrik dapat membantu mengidentifikasi apakah Anda mencapai batas per tabel atau seluruh akun dan memahami pola distribusi kapasitas Anda.

CloudWatch Metrik penting

Pantau metrik utama ini untuk mendiagnosis pelambatan batas akun:

Prosedur resolusi

Meminta kenaikan kuota per tabel

Jika aplikasi Anda perlu beroperasi di luar batas throughput per tabel saat ini, Anda harus mengirimkan permintaan peningkatan kuota menggunakan prosedur di bawah ini. Setiap tabel DynamoDB di AWS akun Anda (bersama dengan semua GSI terkait) tunduk pada kuota throughput ini dalam Wilayah tertentu. Kuota ini mewakili kapasitas baca atau tulis maksimum yang dapat dikonsumsi oleh setiap tabel individu dan GSI-nya secara kolektif, dan kuota ini berlaku secara independen untuk setiap tabel daripada sebagai agregat di semua tabel di akun Anda.

Secara opsional, Anda juga dapat menetapkan batas yang lebih rendah berdasarkan per-tabel atau per-GSi dengan mengonfigurasi pengaturan throughput sesuai permintaan maksimum mereka.

  1. Identifikasi kuota spesifik yang perlu ditingkatkan:

    • Per-table baca batas throughput (kode kuota L-CF0CBE56): Default 40.000 RCU per tabel

    • Per-table tulis batas throughput (kode kuota L-AB614373): Default 40.000 WCU per tabel

  2. Gunakan konsol AWS Kuota Layanan untuk meminta peningkatan:

    • Arahkan ke layanan DynamoDB di Kuota Layanan

    • Temukan kuota yang sesuai menggunakan kode kuota

    • Minta kenaikan berdasarkan proyeksi penggunaan puncak

  3. Memberikan justifikasi untuk kenaikan tersebut, termasuk:

    • Pola penggunaan saat ini dan persyaratan lalu lintas puncak

    • Pembenaran bisnis untuk peningkatan kapasitas

    • Garis waktu untuk kapan peningkatan kapasitas diperlukan

catatan

Peningkatan kuota biasanya memakan waktu 24-48 jam untuk diproses. Rencanakan permintaan Anda sesuai dan pertimbangkan strategi mitigasi sementara sambil menunggu persetujuan.

Mengoptimalkan proyeksi dan desain GSI

Optimalkan proyeksi dan desain Global Secondary Index (GSI) Anda untuk mengurangi konsumsi kapasitas dan meningkatkan kinerja.

Strategi proyeksi selektif

Jika kueri Anda hanya perlu mengakses beberapa atribut, memproyeksikan hanya atribut tersebut mengurangi jumlah data yang ditulis ke GSI saat item tabel dasar berubah. Untuk detail tentang jenis proyeksi, lihat Pro yeksi untuk Indeks Sekunder Global.

  1. Analisis pola kueri: Tinjau pola kueri aplikasi Anda untuk mengidentifikasi atribut mana yang benar-benar diakses melalui GSI.

  2. Gunakan proyeksi selektif: Hanya atribut proyek yang benar-benar diperlukan dalam kueri untuk mengurangi volume penulisan.

  3. PertimbangkanKEYS_ONLY: Jika kueri Anda hanya membutuhkan atribut kunci, gunakan KEYS_ONLY proyeksi untuk meminimalkan volume penulisan.

  4. Saldo pertukaran baca vs tulis: Memproyeksikan atribut yang lebih sedikit mengurangi konsumsi kapasitas tulis tetapi mungkin memerlukan pembacaan tabel dasar tambahan.

Implementasi GSI jarang

GSI jarang hanya berisi item yang memiliki atribut yang diindeks, bukan semua item dari tabel dasar Anda. Ini mengurangi kepadatan partisi dan meningkatkan kinerja saat Anda sering menanyakan subset data tertentu.

  1. Desain GSI yang hanya menyertakan item dengan nilai atribut tertentu.

  2. Terapkan pengindeksan bersyarat dengan hanya mengatur atribut kunci partisi GSI pada item yang harus diindeks.

  3. Gunakan kunci komposit di GSI jarang (misalnya, status #timestamp) untuk mendistribusikan lalu lintas lebih lanjut dalam subset item yang diindeks.

Untuk informasi selengkapnya tentang menerapkan strategi ini, lihat Praktik Terbaik untuk Menggunakan Indeks Sekunder di Dynam oDB.