1- Throughput rentang kunci terlampaui (partisi panas) - Amazon DynamoDB
Hasil rentang kunci melebihi langkah-langkah mitigasiDiagnosis dan pemantauan umumProsedur resolusiSumber daya tambahan

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

1- Throughput rentang kunci terlampaui (partisi panas)

Amazon DynamoDB memberlakukan batas throughput tertentu pada tingkat partisi untuk tabel dan indeks sekunder global (GSI). Setiap partisi memiliki jumlah maksimum unit kapasitas baca (RCUs) dan unit kapasitas tulis (WCUs) per detik. Ketika partisi menerima lalu lintas terkonsentrasi yang melebihi batas ini, mereka mengalami pelambatan sementara operasi lain mungkin tetap kurang dimanfaatkan, menciptakan “partisi panas.” Pelambatan tingkat partisi DynamoDB beroperasi secara independen untuk membaca dan menulis - partisi dapat membatasi pembacaan sementara penulisan berlanjut secara normal, atau sebaliknya. Pelambatan ini dapat terjadi bahkan ketika meja atau GSI Anda memiliki kapasitas keseluruhan yang cukup. Untuk mempelajari lebih lanjut tentang:

Ketika partisi individu melebihi batas throughputnya, DynamoDB mengembalikan tipe alasan pelambatan dalam pengecualian KeyRangeThroughputExceeded throttling. Informasi tersebut mengidentifikasi bahwa partisi mengalami lalu lintas tinggi dan jenis operasi mana (baca atau tulis) yang menyebabkan masalah.

Hasil rentang kunci melebihi langkah-langkah mitigasi

Bagian ini memberikan panduan resolusi untuk skenario pelambatan tingkat partisi. 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, periksa apakah masalah teratasi secara otomatis:

  • DynamoDB sering beradaptasi dengan partisi panas melalui mekanisme otomatisnya. split-for-heat Jika Anda melihat peristiwa pelambatan yang berhenti setelah periode singkat, tabel Anda mungkin sudah beradaptasi dengan memisahkan partisi panas. Ketika partisi terbelah, setiap partisi baru menangani bagian yang lebih kecil dari keyspace, yang dapat membantu mendistribusikan beban secara lebih merata. Dalam banyak kasus, tidak ada tindakan lebih lanjut yang diperlukan karena DynamoDB telah menyelesaikan masalah secara otomatis.

    Untuk informasi lebih lanjut tentang split-for-heatmekanismenya, lihatSumber daya tambahan.

Jika pelambatan berlanjut, lihat skenario pelambatan spesifik di bawah ini untuk opsi remediasi yang ditargetkan:

TableReadKeyRangeThroughputExceeded

Ketika ini terjadi

Tingkat konsumsi satu atau lebih partisi dalam tabel DynamoDB Anda melebihi batas throughput baca partisi. Pelambatan ini terjadi terlepas dari total kapasitas yang disediakan tabel Anda dan memengaruhi tabel yang disediakan dan sesuai permintaan. Anda dapat memantau CloudWatch metrik Diagnosis dan pemantauan umum untuk menganalisis peristiwa pelambatan Anda.

Opsi remediasi

Pertimbangkan langkah-langkah ini untuk mengatasi peristiwa pelambatan Anda:

Untuk mode yang disediakan dan sesuai permintaan:

  • Kapasitas pra-hangat: Jika pelambatan berlanjut, periksa apakah meja Anda dibatasi oleh kapasitasnya. Memahami throughput hangat DynamoDB Gunakan throughput hangat atau tingkatkan kapasitas yang disediakan baca terlebih dahulu untuk peningkatan lalu lintas yang diharapkan. Meningkatkan throughput hangat meningkatkan kemampuan meja Anda untuk menangani lonjakan lalu lintas tiba-tiba sebelum pelambatan terjadi. Seiring waktu, jika throughput aktual Anda secara konsisten mendekati level throughput hangat, DynamoDB dapat membagi partisi sibuk berdasarkan pola penggunaan yang diamati.

  • Identifikasi tombol pintas Anda: Jika tabel tidak menyelesaikannya secara otomatis dan throughput hangat Anda tinggi atau menaikkannya tidak membantu, Anda harus mengidentifikasi tombol pintas tertentu. Gunakan Mengidentifikasi tombol pintas menggunakan CloudWatch Contributor Insights untuk menentukan apakah ada nilai kunci partisi tertentu yang panas. Ini adalah langkah pertama untuk menargetkan upaya mitigasi Anda secara efektif. Perhatikan bahwa identifikasi mungkin tidak selalu mudah, terutama dengan partisi panas bergulir (di mana partisi yang berbeda menjadi panas dari waktu ke waktu) atau ketika pelambatan dipicu oleh operasi seperti pemindaian. Untuk skenario kompleks ini, Anda mungkin perlu menganalisis pola akses aplikasi Anda dan menghubungkannya dengan waktu peristiwa pelambatan.

  • Bergantung pada kasus penggunaan Anda, pertimbangkan untuk menggunakan pembacaan yang konsisten pada akhirnya: Beralih dari pembacaan yang sangat konsisten ke yang konsisten pada akhirnya, yang menghabiskan setengah RCUs dan dapat segera menggandakan kapasitas baca efektif Anda. Untuk praktik terbaik dalam menerapkan pembacaan yang konsisten pada akhirnya untuk mengurangi konsumsi kapasitas baca, lihatDynamoDB membaca konsistensi.

  • Tingkatkan desain kunci partisi: Sebagai solusi jangka panjang, pertimbangkan Meningkatkan desain kunci partisi untuk mendistribusikan akses secara lebih merata di seluruh partisi. Pendekatan ini sering memberikan resolusi paling komprehensif untuk masalah partisi panas dengan mengatasi akar masalahnya. Namun, ini membutuhkan perencanaan yang matang karena melibatkan tantangan migrasi yang signifikan.

TableWriteKeyRangeThroughputExceeded

Ketika ini terjadi

Tingkat konsumsi satu atau lebih partisi dalam tabel DynamoDB Anda melebihi batas throughput tulis partisi. Pelambatan ini terjadi terlepas dari total kapasitas yang disediakan tabel Anda dan memengaruhi tabel yang disediakan dan sesuai permintaan. Anda dapat memantau CloudWatch metrik Diagnosis dan pemantauan umum untuk menganalisis peristiwa pelambatan Anda.

Opsi remediasi

Pertimbangkan langkah-langkah ini untuk mengatasi peristiwa pelambatan Anda:

Untuk mode yang disediakan dan sesuai permintaan:

  • Kapasitas pra-hangat: Jika pelambatan berlanjut, periksa apakah meja Anda dibatasi oleh kapasitasnya. Memahami throughput hangat DynamoDB Gunakan throughput hangat atau tingkatkan kapasitas yang disediakan penulisan terlebih dahulu untuk peningkatan lalu lintas yang diharapkan. Meningkatkan throughput hangat meningkatkan kemampuan meja Anda untuk menangani lonjakan lalu lintas tiba-tiba sebelum pelambatan terjadi. Seiring waktu, jika throughput aktual Anda secara konsisten mendekati level throughput hangat, DynamoDB dapat membagi partisi sibuk berdasarkan pola penggunaan yang diamati.

  • Identifikasi tombol pintas Anda: Jika tabel tidak menyelesaikannya secara otomatis dan throughput hangat Anda tinggi atau menaikkannya tidak membantu, Anda harus mengidentifikasi tombol pintas tertentu. Gunakan Mengidentifikasi tombol pintas menggunakan CloudWatch Contributor Insights untuk menentukan apakah ada nilai kunci partisi tertentu yang panas. Ini adalah langkah pertama untuk menargetkan upaya mitigasi Anda secara efektif. Pertimbangkan pola umum ini:

    • Jika Anda melihat kunci partisi yang sama sering muncul dalam data throttling Anda, ini menunjukkan tombol pintas terkonsentrasi.

    • Jika Anda tidak melihat kunci berulang tetapi menulis data secara teratur (seperti stempel waktu berurutan atau operasi berbasis pemindaian yang mengikuti urutan keyspace), Anda mungkin memiliki partisi panas bergulir di mana tombol yang berbeda menjadi panas seiring waktu saat penulisan Anda bergerak melalui ruang kunci.

    Perhatikan bahwa pelambatan tulis juga dapat terjadi dengan operasi seperti BatchWriteItem atau transaksi yang memengaruhi beberapa item secara bersamaan. Ketika item individual dalam BatchWriteItem permintaan dibatasi, DynamoDB tidak menyebarkan kesalahan pelambatan ini ke kode aplikasi. Sebagai gantinya, DynamoDB mengembalikan informasi tentang item yang belum diproses dalam respons, yang harus ditangani aplikasi Anda dengan mencoba kembali item tertentu tersebut. Untuk transaksi, seluruh operasi gagal dengan TransactionCanceledException jika ada item yang mengalami pelambatan. Untuk skenario kompleks ini, Anda mungkin perlu menganalisis pola penulisan aplikasi dan alur kerja penyerapan data, menghubungkannya dengan waktu peristiwa pelambatan, dan menerapkan strategi penanganan coba ulang yang sesuai.

  • Tingkatkan desain kunci partisi: Sebagai solusi jangka panjang, pertimbangkan Meningkatkan desain kunci partisi untuk mendistribusikan akses secara lebih merata di seluruh partisi. Pendekatan ini sering memberikan resolusi paling komprehensif untuk masalah partisi panas dengan mengatasi akar masalahnya. Namun, ini membutuhkan perencanaan yang matang karena melibatkan tantangan migrasi yang signifikan.

IndexReadKeyRangeThroughputExceeded

Ketika ini terjadi

Tingkat konsumsi satu atau lebih partisi di DynamoDB GSI Anda melebihi batas throughput baca partisi. Pelambatan ini terjadi terlepas dari total kapasitas yang disediakan GSI Anda dan memengaruhi tabel yang disediakan dan sesuai permintaan. Anda dapat memantau CloudWatch metrik Diagnosis dan pemantauan umum untuk menganalisis peristiwa pelambatan Anda.

Opsi remediasi

Pertimbangkan langkah-langkah ini untuk mengatasi peristiwa pelambatan Anda:

  • Kapasitas pra-hangat: Jika pelambatan berlanjut, periksa apakah GSI Anda dibatasi oleh kapasitasnya. Memahami throughput hangat DynamoDB Gunakan throughput hangat atau tingkatkan kapasitas yang disediakan baca terlebih dahulu untuk peningkatan lalu lintas yang diharapkan. Meningkatkan throughput hangat meningkatkan kemampuan GSI Anda untuk menangani lonjakan lalu lintas mendadak sebelum pelambatan terjadi. Seiring waktu, jika throughput aktual Anda secara konsisten mendekati level throughput hangat, DynamoDB dapat membagi partisi sibuk berdasarkan pola penggunaan yang diamati.

  • Identifikasi tombol pintas Anda: Jika GSI tidak menyelesaikannya secara otomatis dan throughput hangat Anda tinggi atau menaikkannya tidak membantu, Anda harus mengidentifikasi tombol pintas tertentu. Gunakan Mengidentifikasi tombol pintas menggunakan CloudWatch Contributor Insights untuk menentukan apakah ada nilai kunci partisi tertentu yang panas. Ini adalah langkah pertama untuk menargetkan upaya mitigasi Anda secara efektif. Perhatikan bahwa untuk GSIs, distribusi kunci partisi mungkin berbeda secara signifikan dari tabel dasar Anda, menciptakan pola tombol pintas yang berbeda.

  • Mendesain ulang kunci partisi GSI: Pertimbangkan apakah desain kunci GSI Anda mungkin membuat hot spot buatan (seperti flag status, kunci hanya tanggal, atau atribut boolean) yang berkonsentrasi membaca pada sejumlah kecil partisi. Pertimbangkan untuk menggunakan kunci komposit yang menggabungkan atribut kardinalitas rendah dengan atribut kardinalitas tinggi (misalnya, “AKTIF #customer123" alih-alih hanya “AKTIF”) atau menerapkan Menggunakan sharding tulis untuk mendistribusikan beban kerja secara merata di tabel DynamoDB Anda teknik ke item tabel dasar yang memengaruhi distribusi GSI untuk mendistribusikan tulisan di beberapa partisi. Sementara query data sharded memerlukan logika aplikasi tambahan untuk mengumpulkan hasil, pendekatan ini mencegah throttling dengan mendistribusikan pola akses lebih merata.

IndexWriteKeyRangeThroughputExceeded

Ketika ini terjadi

Tingkat konsumsi satu atau lebih partisi di DynamoDB GSI Anda melebihi batas throughput tulis partisi. Pelambatan ini terjadi terlepas dari total kapasitas yang disediakan GSI Anda dan memengaruhi tabel yang disediakan dan sesuai permintaan. Anda dapat memantau CloudWatch metrik Diagnosis dan pemantauan umum untuk menganalisis peristiwa pelambatan Anda.

Opsi remediasi

Pertimbangkan langkah-langkah ini untuk mengatasi peristiwa pelambatan Anda:

  • Desain ulang kunci partisi GSI: Tinjau desain kunci partisi GSI Anda untuk memverifikasi bahwa ia memiliki kardinalitas (keunikan) yang cukup untuk mendistribusikan tulisan secara merata. Penyebab umum pelambatan penulisan GSI adalah menggunakan atribut kardinalitas rendah sebagai kunci partisi GSI (seperti flag status dengan hanya beberapa nilai yang mungkin). Bahkan ketika tabel dasar Anda memiliki kunci partisi yang terdistribusi dengan baik, GSI Anda masih dapat mengalami partisi panas jika kunci partisi berkonsentrasi menulis ke sejumlah kecil nilai. Misalnya, jika 80% item Anda memiliki status = “aktif”, ini membuat partisi panas yang parah di GSI berbasis status. Pertimbangkan untuk menggunakan kunci komposit yang menggabungkan atribut kardinalitas rendah dengan atribut kardinalitas tinggi (misalnya, “AKTIF #customer123" alih-alih hanya “AKTIF”) atau menerapkan Menggunakan sharding tulis untuk mendistribusikan beban kerja secara merata di tabel DynamoDB Anda teknik ke item tabel dasar yang memengaruhi distribusi GSI untuk mendistribusikan tulisan di beberapa partisi. Sementara query data sharded memerlukan logika aplikasi tambahan untuk mengumpulkan hasil, pendekatan ini mencegah throttling dengan mendistribusikan pola akses lebih merata.

  • Kapasitas pra-hangat: Periksa apakah GSI Anda dibatasi oleh Memahami throughput hangat DynamoDB kapasitasnya. Gunakan throughput hangat atau tingkatkan kapasitas yang disediakan baca terlebih dahulu untuk peningkatan lalu lintas yang diharapkan. Meningkatkan throughput hangat meningkatkan kemampuan GSI Anda untuk menangani lonjakan lalu lintas mendadak sebelum pelambatan terjadi. Seiring waktu, jika throughput aktual Anda secara konsisten mendekati level throughput hangat, DynamoDB dapat membagi partisi sibuk berdasarkan pola penggunaan yang diamati.

  • Optimalkan proyeksi GSI: Terapkan Mengoptimalkan proyeksi GSI teknik untuk mengurangi volume tulis menjadi GSIs. Memproyeksikan lebih sedikit atribut dapat secara signifikan mengurangi kapasitas tulis yang dikonsumsi oleh setiap pembaruan GSI.

Diagnosis dan pemantauan umum

Saat memecahkan masalah pelambatan tingkat partisi, beberapa CloudWatch metrik dapat membantu mengidentifikasi partisi panas dan mengonfirmasi akar penyebabnya.

CloudWatch Metrik penting

Pantau metrik utama ini untuk mendiagnosis pelambatan tingkat partisi:

Prosedur resolusi

Mengidentifikasi tombol pintas menggunakan CloudWatch Contributor Insights

Gunakan prosedur ini untuk mengidentifikasi kunci partisi mana yang menyebabkan pelambatan.

  1. Aktifkan Wawasan CloudWatch Kontributor di meja Anda atau GSI untuk melacak kunci yang paling dibatasi. Pertimbangkan untuk mengaktifkan CloudWatch Contributor Insights secara terus menerus untuk peringatan pembatasan waktu nyata dengan menggunakan mode tombol Throttled. Mode ini berfokus secara eksklusif pada permintaan yang dibatasi dengan hanya memproses peristiwa saat pelambatan terjadi. Pemantauan yang ditargetkan ini adalah cara yang hemat biaya untuk mempertahankan visibilitas berkelanjutan ke dalam masalah pelambatan.

  2. Identifikasi kunci mana yang menyebabkan masalah partisi panas.

  3. (Jika mode tombol Diakses dan dibatasi penuh diaktifkan) Analisis pola akses dari waktu ke waktu untuk menentukan apakah tombol pintas konsisten atau terjadi selama periode tertentu.

Meningkatkan desain kunci partisi

Gunakan pendekatan ini ketika Anda dapat memodifikasi skema tabel Anda untuk mendistribusikan lalu lintas dengan lebih baik di seluruh partisi. Jika memungkinkan, ini adalah solusi jangka panjang yang paling efektif untuk masalah partisi panas. Idealnya, desain kunci partisi harus dipertimbangkan dengan cermat selama fase desain tabel awal.

Desain ulang kunci partisi merupakan perubahan mendasar pada model data Anda yang memengaruhi seluruh ekosistem aplikasi Anda. Sebelum melanjutkan dengan pendekatan ini, pertimbangkan dengan cermat keterbatasan signifikan ini:

  • Kompleksitas migrasi data: Mendesain ulang kunci partisi memerlukan migrasi semua data yang ada, yang dapat memakan banyak sumber daya dan memakan waktu untuk tabel besar.

  • Perubahan kode aplikasi: Semua kode aplikasi yang membaca atau menulis ke tabel harus diperbarui untuk menggunakan struktur kunci baru.

  • Dampak produksi: Migrasi ke desain kunci baru seringkali membutuhkan waktu henti atau strategi penulisan ganda yang kompleks selama transisi.

Untuk panduan dan prinsip komprehensif tentang desain kunci partisi, lihat Praktik terbaik untuk merancang dan menggunakan kunci partisi secara efektif di DynamoDB danMerancang kunci partisi untuk mendistribusikan beban kerja Anda di DynamoDB.

Mengoptimalkan proyeksi GSI

Tinjau pola kueri aplikasi Anda untuk menentukan dengan tepat atribut mana yang perlu tersedia saat melakukan kueri GSI, dan batasi proyeksi Anda hanya pada atribut tersebut. Saat Anda memperbarui atribut yang tidak diproyeksikan ke GSI, tidak ada operasi tulis yang terjadi pada GSI itu, mengurangi konsumsi throughput tulis selama pembaruan. Strategi proyeksi yang ditargetkan ini mengoptimalkan kinerja dan biaya sambil tetap mendukung persyaratan kueri aplikasi Anda. Perhatikan bahwa memproyeksikan atribut yang lebih sedikit mengurangi konsumsi kapasitas tulis tetapi mungkin memerlukan pembacaan tabel dasar tambahan.

Untuk informasi selengkapnya tentang strategi proyeksi yang efisien, lihat Praktik Terbaik untuk Menggunakan Indeks Sekunder di DynamoDB.

Sumber daya tambahan

Posting blog berikut memberikan contoh langsung dan detail praktis untuk konsep yang tercakup dalam panduan ini: