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 di tingkat partisi untuk tabel dan indeks sekunder global (GSI). Setiap partisi memiliki jumlah maksimum unit kapasitas baca (RCU) dan unit kapasitas tulis (WCU) 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 mungkin membatasi pembacaan saat penulisan berlanjut secara normal, atau sebaliknya. Pelambatan ini dapat terjadi bahkan ketika tabel atau GSI Anda memiliki kapasitas keseluruhan yang cukup. Untuk mempelajari lebih lanjut tentang:
+ Batas partisi DynamoDB dan desain kunci partisi yang efektif menangani pencegahan partisi panas, lihat Praktik [ terbaik untuk merancang dan menggunakan kunci partisi secara efektif di DynamoDB. ](bp-partition-key-design.md)
+ Konsep partisi umum dan distribusi data, lihat [ Partisi di DynamoDB](HowItWorks.Partitions.md).
+ Panduan tambahan dan skenario dunia nyata untuk mengelola kunci partisi dan throughput, lihat[Sumber daya tambahan](#key-range-additional-resources).
Ketika partisi individu melebihi batas throughput mereka, DynamoDB mengembalikan jenis alasan pembatasan dalam pengecualian `KeyRangeThroughputExceeded` throttling. Informasi mengidentifikasi bahwa partisi mengalami lalu lintas tinggi dan jenis operasi mana (baca atau tulis) yang menyebabkan masalah.
## Throughput rentang utama melebihi langkah-langkah mitigasi
Bagian ini memberikan panduan resolusi untuk skenario pelambatan tingkat partisi. 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](throttling-diagnosing-workflow.md#throttling-diagnosing)
Sebelum menyelami skenario pelambatan tertentu, pertama-tama, periksa apakah masalah teratasi secara otomatis:
+ DynamoDB sering beradaptasi dengan partisi panas melalui mekanisme split-for-heat otomatis. Jika Anda melihat peristiwa pelambatan yang berhenti setelah periode singkat, tabel Anda mungkin sudah beradaptasi dengan memisahkan partisi panas. Ketika partisi terpecah, setiap partisi baru menangani bagian yang lebih kecil dari ruang tombol, yang dapat membantu mendistribusikan beban lebih merata. Dalam banyak kasus, tidak ada tindakan lebih lanjut yang diperlukan karena DynamoDB telah menyelesaikan masalah secara otomatis.
Untuk informasi lebih lanjut tentang mekanisme * * split-for-heat, lihat. [Sumber daya tambahan](#key-range-additional-resources)
Jika pelambatan berlanjut, lihat skenario pelambatan spesifik di bawah ini untuk opsi remediasi yang ditargetkan:
+ [TableReadKeyRangeThroughputExceeded](#throttling-table-read-keyrange)
+ [TableWriteKeyRangeThroughputExceeded](#throttling-table-write-keyrange)
+ [IndexReadKeyRangeThroughputExceeded](#throttling-index-read-keyrange)
+ [IndexWriteKeyRangeThroughputExceeded](#throttling-index-write-keyrange)
### TableReadKeyRangeThroughputExceeded
**Ketika ini terjadi**
Tingkat konsumsi satu atau lebih partisi di tabel DynamoDB melebihi batas throughput baca partisi. Pelambatan ini terjadi terlepas dari total kapasitas tabel yang disediakan dan memengaruhi tabel yang disediakan dan sesuai permintaan. Anda dapat memantau CloudWatch metrik [Diagnosis dan pemantauan umum](#key-range-exceeded-diagnosis-monitoring) untuk menganalisis peristiwa pelambatan Anda.
**Opsi remediasi**
Pertimbangkan langkah-langkah berikut untuk mengatasi peristiwa pelambatan Anda:
**Untuk mode yang disediakan dan sesuai permintaan: **
+ **Pre-warm kapasitas: ** Jika pelambatan berlanjut, periksa apakah tabel Anda dibatasi oleh [Memahami throughput hangat DynamoDB](warm-throughput.md) kapasitasnya. Gunakan throughput hangat atau tingkatkan kapasitas yang disediakan baca terlebih dahulu untuk peningkatan lalu lintas yang diharapkan. Meningkatkan throughput hangat meningkatkan kemampuan tabel Anda untuk menangani lonjakan lalu lintas mendadak sebelum pelambatan terjadi. Seiring waktu, jika throughput aktual Anda secara konsisten mendekati tingkat throughput hangat, DynamoDB dapat membagi partisi sibuk berdasarkan pola penggunaan yang diamati.
+ **Identifikasi tombol pint ** as Anda: Jika tabel tidak menyelesaikannya secara otomatis dan throughput hangat Anda tinggi atau meningkatkannya tidak membantu, Anda harus mengidentifikasi tombol pintas tertentu. Gunakan [Mengidentifikasi tombol pintas menggunakan Con CloudWatch tributor Insights](#key-range-identify-hot-keys) 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 seiring 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 akhirnya konsisten: Ber ** alih dari pembacaan yang sangat konsisten ke akhirnya konsisten, yang menghabiskan setengah RCU dan dapat segera menggandakan kapasitas baca efektif Anda. Untuk praktik terbaik dalam menerapkan pembacaan yang akhirnya konsisten untuk mengurangi konsumsi kapasitas baca, lihat[Konsistensi baca DynamoDB](HowItWorks.ReadConsistency.md).
+ **Tingkatkan desain kunci partisi: ** Sebagai solusi jangka panjang, pertimbangkan [Meningkatkan desain kunci partisi](#key-range-improve-partition-key-design) untuk mendistribusikan akses lebih merata di seluruh partisi. Pendekatan ini sering memberikan resolusi paling komprehensif untuk masalah partisi panas dengan mengatasi akar penyebabnya. Namun, ini membutuhkan perencanaan yang cermat karena melibatkan tantangan migrasi yang signifikan.
### TableWriteKeyRangeThroughputExceeded
**Ketika ini terjadi**
Tingkat konsumsi satu atau lebih partisi di tabel DynamoDB melebihi batas throughput tulis partisi. Pelambatan ini terjadi terlepas dari total kapasitas tabel yang disediakan dan memengaruhi tabel yang disediakan dan sesuai permintaan. Anda dapat memantau CloudWatch metrik [Diagnosis dan pemantauan umum](#key-range-exceeded-diagnosis-monitoring) untuk menganalisis peristiwa pelambatan Anda.
**Opsi remediasi**
Pertimbangkan langkah-langkah berikut untuk mengatasi peristiwa pelambatan Anda:
**Untuk mode yang disediakan dan sesuai permintaan: **
+ **Pre-warm kapasitas: ** Jika pelambatan berlanjut, periksa apakah tabel Anda dibatasi oleh [Memahami throughput hangat DynamoDB](warm-throughput.md) kapasitasnya. Gunakan throughput hangat atau tingkatkan kapasitas tulis yang disediakan sebelumnya untuk peningkatan lalu lintas yang diharapkan. Meningkatkan throughput hangat meningkatkan kemampuan tabel Anda untuk menangani lonjakan lalu lintas mendadak sebelum pelambatan terjadi. Seiring waktu, jika throughput aktual Anda secara konsisten mendekati tingkat throughput hangat, DynamoDB mungkin membagi partisi sibuk berdasarkan pola penggunaan yang diamati.
+ **Identifikasi tombol pint ** as Anda: Jika tabel tidak menyelesaikannya secara otomatis dan throughput hangat Anda tinggi atau meningkatkannya tidak membantu, Anda harus mengidentifikasi tombol pintas tertentu. Gunakan [Mengidentifikasi tombol pintas menggunakan Con CloudWatch tributor Insights](#key-range-identify-hot-keys) untuk menentukan apakah ada nilai kunci partisi tertentu yang panas. Ini adalah langkah pertama untuk menargetkan upaya mitigasi Anda secara efektif. Pertimbangkan pola-pola umum ini:
+ Jika Anda melihat kunci partisi yang sama sering muncul di data throttling Anda, ini menunjukkan tombol pintas terkonsentrasi.
+ Jika Anda tidak melihat kunci berulang tetapi menulis data dengan cara yang teratur (seperti stempel waktu berurutan atau operasi berbasis pemindaian yang mengikuti urutan ruang tombol), Anda mungkin memiliki partisi panas bergulir di mana kunci yang berbeda menjadi panas seiring waktu saat penulisan Anda bergerak melalui ruang tombol.
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 pembatasan 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 percobaan ulang yang sesuai.
+ **Tingkatkan desain kunci partisi: ** Sebagai solusi jangka panjang, pertimbangkan [Meningkatkan desain kunci partisi](#key-range-improve-partition-key-design) untuk mendistribusikan akses lebih merata di seluruh partisi. Pendekatan ini sering memberikan resolusi paling komprehensif untuk masalah partisi panas dengan mengatasi akar penyebabnya. Namun, ini membutuhkan perencanaan yang cermat karena melibatkan tantangan migrasi yang signifikan.
### IndexReadKeyRangeThroughputExceeded
**Ketika ini terjadi**
Tingkat konsumsi satu atau lebih partisi di DynamoDB GSI melebihi batas throughput baca partisi. Pelambatan ini terjadi terlepas dari total kapasitas GSI yang disediakan dan memengaruhi tabel yang disediakan dan sesuai permintaan. Anda dapat memantau CloudWatch metrik [Diagnosis dan pemantauan umum](#key-range-exceeded-diagnosis-monitoring) untuk menganalisis peristiwa pelambatan Anda.
**Opsi remediasi**
Pertimbangkan langkah-langkah berikut untuk mengatasi peristiwa pelambatan Anda:
+ **Pre-warm kapasitas: ** Jika pelambatan berlanjut, periksa apakah GSI Anda dibatasi oleh kapasitasnya[Memahami throughput hangat DynamoDB](warm-throughput.md). 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 tingkat throughput hangat, DynamoDB mungkin membagi partisi sibuk berdasarkan pola penggunaan yang diamati.
+ **Identifikasi tombol pintas Anda: ** Jika GSI tidak menyelesaikannya secara otomatis dan throughput hangat Anda tinggi atau meningkatkannya tidak membantu, Anda harus mengidentifikasi tombol pintas tertentu. Gunakan [Mengidentifikasi tombol pintas menggunakan Con CloudWatch tributor Insights](#key-range-identify-hot-keys) untuk menentukan apakah ada nilai kunci partisi tertentu yang panas. Ini adalah langkah pertama untuk menargetkan upaya mitigasi Anda secara efektif. Perhatikan bahwa untuk GSI, 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 khusus tanggal, atau atribut boolean) yang memusatkan pembacaan 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 terapkan [Menggunakan write sharding untuk mendistribusikan beban kerja secara merata di tabel DynamoDB Anda](bp-partition-key-sharding.md) teknik ke item tabel dasar yang memengaruhi distribusi GSI untuk mendistribusikan penulisan di beberapa partisi. Sementara kueri data sharded memerlukan logika aplikasi tambahan untuk mengumpulkan hasil, pendekatan ini mencegah pelambatan dengan mendistribusikan pola akses secara lebih merata.
### IndexWriteKeyRangeThroughputExceeded
**Ketika ini terjadi**
Tingkat konsumsi satu atau lebih partisi di DynamoDB GSI melebihi batas throughput tulis partisi. Pelambatan ini terjadi terlepas dari total kapasitas GSI yang disediakan dan memengaruhi tabel yang disediakan dan sesuai permintaan. Anda dapat memantau CloudWatch metrik [Diagnosis dan pemantauan umum](#key-range-exceeded-diagnosis-monitoring) untuk menganalisis peristiwa pelambatan Anda.
**Opsi remediasi**
Pertimbangkan langkah-langkah berikut untuk mengatasi peristiwa pelambatan Anda:
+ **Desain ulang kunci partisi GSI: T ** injau desain kunci partisi GSI Anda untuk memverifikasi bahwa ia memiliki kardinalitas (keunikan) yang cukup untuk mendistribusikan penulisan secara merata. Penyebab umum pelambatan tulis GSI adalah menggunakan atribut kardinalitas rendah sebagai kunci partisi GSI (seperti flag status dengan hanya beberapa kemungkinan nilai). Bahkan ketika tabel dasar Anda memiliki kunci partisi yang terdistribusi dengan baik, GSI Anda masih dapat mengalami partisi panas jika kunci partisinya terkonsentrasi 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 terapkan [Menggunakan write sharding untuk mendistribusikan beban kerja secara merata di tabel DynamoDB Anda](bp-partition-key-sharding.md) teknik ke item tabel dasar yang memengaruhi distribusi GSI untuk mendistribusikan penulisan di beberapa partisi. Sementara kueri data sharded memerlukan logika aplikasi tambahan untuk mengumpulkan hasil, pendekatan ini mencegah pelambatan dengan mendistribusikan pola akses secara lebih merata.
+ **Pre-warm kapasitas: ** Periksa apakah GSI Anda dibatasi oleh [Memahami throughput hangat DynamoDB](warm-throughput.md) kapasitasnya. Gunakan throughput hangat atau tingkatkan kapasitas yang disediakan tulis 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 tingkat throughput hangat, DynamoDB dapat membagi partisi sibuk berdasarkan pola penggunaan yang diamati.
+ **Optimalkan proyeksi GSI: ** Terapkan [Mengoptimalkan proyeksi GSI](#key-range-optimize-gsi-projections) teknik untuk mengurangi volume tulis ke GSI. Memproyeksikan atribut yang lebih sedikit dapat secara signifikan mengurangi kapasitas penulisan 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:
+ **Partition-level peristiwa pelambatan: ** [`ReadKeyRangeThroughputThrottleEvents`](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadKeyRangeThroughputThrottleEvents) dan lac [`WriteKeyRangeThroughputThrottleEvents`](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteKeyRangeThroughputThrottleEvents) ak ketika partisi individu melebihi batas throughput mereka. [`ReadThrottleEvents`](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents)dan [`WriteThrottleEvents`](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents) lacak ketika permintaan baca atau tulis melebihi kapasitas yang disediakan.
+ **Konsumsi kapasitas: ** [`ConsumedReadCapacityUnits`](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits) dan [`ConsumedWriteCapacityUnits`](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits) menunjukkan pola penggunaan keseluruhan.
## Prosedur resolusi
### Mengidentifikasi tombol pintas menggunakan Con CloudWatch tributor Insights
Gunakan prosedur ini untuk mengidentifikasi kunci partisi mana yang menyebabkan pelambatan.
1. Aktif [ CloudWatch kan Insights ](contributorinsights_HowItWorks.md) Contributor di meja atau GSI Anda untuk melacak tombol yang paling terbatas. Pertimbangkan untuk CloudWatch mengaktifkan Contributor Insights secara terus menerus untuk peringatan pelambatan 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 hemat biaya untuk mempertahankan visibilitas berkelanjutan terhadap masalah pelambatan.
1. Identifikasi kunci mana yang menyebabkan masalah partisi panas.
1. (Jika mode tombol * Akses 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 mewakili perubahan mendasar pada model data Anda yang berdampak pada seluruh ekosistem aplikasi Anda. Sebelum melanjutkan dengan pendekatan ini, pertimbangkan dengan cermat batasan 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](bp-partition-key-design.md) dan[Merancang kunci partisi untuk mendistribusikan beban kerja Anda di DynamoDB](bp-partition-key-uniform-load.md).
### Mengoptimalkan proyeksi GSI
Tinjau pola kueri aplikasi Anda untuk menentukan dengan tepat atribut mana yang perlu tersedia saat menanyakan GSI, dan batasi proyeksi Anda hanya pada atribut tersebut. Saat Anda memperbarui atribut yang tidak diproyeksikan ke GSI, tidak ada operasi penulisan yang terjadi pada GSI tersebut, sehingga 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 Dynam ](bp-indexes-general.md) oDB.
## Sumber daya tambahan
Posting blog berikut memberikan contoh langsung dan detail praktis untuk konsep yang tercakup dalam panduan ini:
+ Untuk panduan langsung tentang penskalaan DynamoDB dan mengelola partisi panas, lihat [ Bagian 1: Penskalaan DynamoDB - Bagaimana partisi, tombol pintas, dan pemisahan untuk kinerja dampak panas. ](https://aws.amazon.com/blogs/database/part-1-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/)
+ Untuk informasi terperinci tentang cara kerja mekanisme split-for-heat DynamoDB, manfaatnya, dan detail implementasinya, lihat [ Bagian 3: Ringkasan dan praktik terbaik. ](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/)
+ Untuk strategi sharding tulis terperinci, lihat[Menggunakan write sharding untuk mendistribusikan beban kerja secara merata di tabel DynamoDB Anda](bp-partition-key-sharding.md).