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

Tabel sesuai permintaan tidak memiliki tingkat kapasitas yang disediakan untuk dikelola, tetapi DynamoDB memberlakukan batas throughput tingkat akun untuk mencegah eksekusi runaway dan memastikan penggunaan sumber daya yang adil 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 tipe alasan pelambatan AccountLimitExceeded dalam pengecualian pelambatan. Batas akun per tabel default secara otomatis berlaku ketika tabel tidak memiliki pengaturan throughput maksimum kustom yang dikonfigurasi. Anda dapat mengonfigurasi pengaturan throughput maksimum secara opsional 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 pembatasan batas akun. Sebelum menggunakan panduan ini, pastikan Anda telah mengidentifikasi alasan pembatasan 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:

  • Evaluasi dampak kinerja: Periksa apakah aplikasi Anda masih memenuhi persyaratan kinerjanya meskipun ada pembatasan. Banyak aplikasi beroperasi dengan sukses 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 berfungsi dengan baik bahkan ketika kadang-kadang mencapai batas akun, Anda dapat memilih untuk hanya memantau situasi daripada menerapkan perubahan langsung.

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

TableReadAccountLimitExceeded

Ketika ini terjadi

Konsumsi baca tabel Anda telah melampaui kuota throughput baca tingkat akun per tabel 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 pembatasan ini:

  • Kuota permintaan meningkat:

    Minta peningkatan batas throughput baca per tabel (Kode kuota L-CF0). CBE56 Untuk langkah-langkah mendetail tentang cara mengirimkan permintaan, lihat Meminta kuota per tabel meningkat.

TableWriteAccountLimitExceeded

Ketika ini terjadi

Konsumsi tulis tabel Anda telah melampaui kuota throughput tulis 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 pembatasan ini:

  • Kuota permintaan meningkat: Minta peningkatan batas throughput tulis per tabel (Kode kuota L-). AB614373 Untuk langkah-langkah mendetail tentang cara mengirimkan permintaan, lihat Meminta kuota per tabel meningkat.

IndexReadAccountLimitExceeded

Ketika ini terjadi

Operasi baca yang diarahkan pada Indeks Sekunder Global (GSI) mengkonsumsi lebih banyak throughput daripada yang diizinkan kuota baca per tabel akun Anda di Wilayah Anda saat ini. AWS Kuota throughput baca tingkat akun per tabel berlaku secara kolektif ke tabel dan semua gabungannya. GSIs 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:

  • Kuota permintaan meningkat: Minta peningkatan batas throughput baca per tabel (Kode kuota L-CF0). CBE56 Untuk langkah-langkah mendetail tentang cara mengirimkan permintaan, lihat Meminta kuota per tabel meningkat.

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

IndexWriteAccountLimitExceeded

Ketika ini terjadi

Operasi tulis ke tabel dasar Anda menghasilkan pembaruan terkait ke GSI yang secara kolektif melebihi kuota throughput tulis 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 itu. Operasi penulisan gabungan ini dihitung terhadap 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:

  • Kuota permintaan meningkat: Minta peningkatan batas throughput tulis per tabel (Kode kuota L-AB614373) untuk mengakomodasi lalu lintas penulisan GSI yang lebih tinggi dari operasi tabel dasar. Kuota throughput tulis per tabel berlaku untuk seluruh tabel, termasuk semua miliknya. GSIs Untuk langkah-langkah mendetail tentang cara mengirimkan permintaan, lihat Meminta kuota per tabel meningkat.

  • Optimalkan proyeksi GSI: Tinjau proyeksi dan desain GSI untuk mengurangi volume tulis menjadi. GSIs

Diagnosis dan pemantauan umum

Ketika 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 pembatasan batas akun:

Prosedur resolusi

Meminta kuota per tabel meningkat

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 akun AWS Anda (bersama dengan semua yang GSIs terkait) tunduk pada kuota throughput ini dalam Wilayah tertentu. Kuota ini mewakili kapasitas baca atau tulis maksimum yang GSIs dapat dikonsumsi oleh setiap tabel individu dan secara kolektif, dan mereka berlaku secara independen untuk setiap tabel daripada sebagai agregat di semua tabel di akun Anda.

Secara opsional, Anda juga dapat menetapkan batas bawah berdasarkan per-tabel atau per-GSI dengan mengonfigurasi pengaturan throughput sesuai permintaan maksimum mereka.

  1. Identifikasi kuota spesifik yang perlu ditingkatkan:

    • Batas throughput baca per tabel (Kode kuota L-CF0CBE56): Default 40.000 per tabel RCUs

    • Batas throughput tulis per tabel (Kode kuota L-AB614373): Default 40.000 per tabel WCUs

  2. Gunakan konsol AWS Service Quotas untuk meminta peningkatan:

    • Arahkan ke layanan DynamoDB di Service Quotas

    • Temukan kuota yang sesuai menggunakan kode kuota

    • Minta peningkatan berdasarkan proyeksi penggunaan puncak Anda

  3. Berikan pembenaran untuk kenaikan tersebut, termasuk:

    • Pola penggunaan saat ini dan persyaratan lalu lintas puncak

    • Pembenaran bisnis untuk peningkatan kapasitas

    • Garis waktu 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 akan mengurangi jumlah data yang ditulis ke GSI saat item tabel dasar berubah. Untuk detail tentang jenis proyeksi, lihat Proyeksi untuk Indeks Sekunder Global.

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

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

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

  4. Balance read vs. write trade-off: Memproyeksikan lebih sedikit atribut mengurangi konsumsi kapasitas tulis tetapi mungkin memerlukan pembacaan tabel dasar tambahan.

Implementasi GSI jarang

Sparse hanya GSIs berisi item yang memiliki atribut diindeks, bukan semua item dari tabel dasar Anda. Ini mengurangi kepadatan partisi dan meningkatkan kinerja ketika Anda sering meminta subset data tertentu.

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

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

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

Untuk informasi selengkapnya tentang penerapan strategi ini, lihat Praktik Terbaik untuk Menggunakan Indeks Sekunder di DynamoDB.