Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Memahami Global Secondary Index (GSI) tulis throttling dan tekanan balik di DynamoDB
Pelambatan tekanan balik GSI mewakili salah satu skenario pelambatan paling kompleks di DynamoDB karena menciptakan hubungan tidak langsung antara operasi tulis dan pelambatan — aplikasi Anda menulis ke tabel dasar tetapi mengalami pelambatan karena kendala kapasitas pada satu atau beberapa indeks.
Memahami pelambatan tekanan balik GSI
Ketika Anda menulis ke tabel DynamoDB, setiap indeks sekunder global GSIs () pada tabel tersebut diperbarui secara asinkron menggunakan model yang akhirnya konsisten. Jika GSI tidak memiliki kapasitas yang cukup untuk menangani pembaruan ini, DynamoDB throttles menulis ke tabel dasar untuk menjaga konsistensi data. Ini disebut tekanan balik GSI. Untuk informasi selengkapnya tentang cara GSIs kerja, lihat Indeks Sekunder Global di DynamoDB.
Tidak seperti pelambatan tabel langsung di mana sumber daya yang diakses juga merupakan sumber daya yang menyebabkan pelambatan, tekanan balik GSI menciptakan ketergantungan antara tabel dasar dan indeksnya. Bahkan jika tabel dasar Anda memiliki kapasitas yang cukup, penulisan akan dibatasi jika GSI terkait tidak dapat menangani volume pembaruan. Hubungan ini sangat penting untuk dipahami karena kendala tingkat partisi berlaku secara independen pada tabel dasar dan masing-masing GSI — masing-masing memiliki struktur partisi sendiri dan batas throughput yang sesuai.
Partisi GSI didasarkan pada kunci partisi GSI, yang seringkali berbeda dari kunci partisi tabel dasar. Bahkan jika akses tabel dasar Anda didistribusikan dengan sempurna di seluruh partisi, pembaruan GSI Anda mungkin masih berkonsentrasi pada partisi tertentu, menciptakan hot spot di GSI. Untuk praktik terbaik umum pada desain kunci partisi untuk kedua tabel dan GSIs, lihat DynamoDB desain kunci partisi.
Misalnya, jika tabel dasar Anda digunakan customerId sebagai kunci partisi (didistribusikan secara merata) tetapi GSI Anda digunakan status sebagai kunci partisi (dengan kemungkinan nilai terbatas seperti “aktif”, “tertunda”, “tertutup”), pembaruan ke item dengan nilai status populer dapat membuat partisi panas GSI bahkan ketika akses tabel dasar seimbang. Ini menciptakan skenario yang sangat menantang di mana aplikasi Anda mungkin mengalami pelambatan karena partisi panas GSI meskipun tabel dasar dan GSI memiliki kapasitas keseluruhan yang cukup dan pola akses tabel dasar tampak terdistribusi dengan baik.
Meskipun pengecualian pelambatan menunjuk ke GSI (viaResourceArn), operasi sebenarnya yang dibatasi adalah menulis ke tabel dasar. Ini bisa membingungkan karena aplikasi Anda menulis ke tabel dasar tetapi menerima pengecualian tentang GSI.
Jenis pelambatan GSI
Pelambatan tekanan balik GSI bermanifestasi melalui jenis pengecualian yang berbeda tergantung pada kendala kapasitas spesifik:
-
Kapasitas yang disediakan GSI terlampaui: Terjadi ketika GSI tidak memiliki unit kapasitas tulis yang memadai untuk menangani pembaruan dari operasi tabel dasar. Ini menghasilkan
ProvisionedThroughputExceededExceptiondengan alasan IndexWriteProvisionedThroughputExceeded, danResourceArnmenunjuk langsung ke GSI tertentu yang mengalami kendala kapasitas. -
Throughput maksimum GSI sesuai permintaan terlampaui: Terjadi ketika operasi penulisan GSI melampaui batas maksimum yang dikonfigurasi pada tabel sesuai permintaan. Ini menghasilkan
ThrottlingExceptionalasan IndexWriteMaxOnDemandThroughputExceeded, mengidentifikasi GSI spesifik dengan batasan throughput yang dikonfigurasi. -
Batas partisi GSI terlampaui: Terjadi ketika partisi GSI individu melebihi batas throughputnya (partisi panas), bahkan jika kapasitas GSI keseluruhan tampak cukup. Ini menghasilkan
ThrottlingExceptionalasan IndexWriteKeyRangeThroughputExceeded, menunjukkan masalah partisi panas pada GSI spesifik yang diidentifikasi diResourceArn. Hal ini sangat penting karena distribusi partisi GSI mungkin berbeda secara signifikan dari distribusi partisi tabel dasar, menciptakan hot spot di GSI bahkan ketika akses tabel dasar didistribusikan secara merata. -
Batas akun GSI terlampaui: Pemicu saat operasi penulisan ke GSI tertentu melebihi batas throughput regional per tabel (atau GSI individu mana pun dalam tabel itu) yang ditetapkan pada tingkat akun. DynamoDB mengembalikan
ThrottlingExceptiona dengan IndexWriteAccountLimitExceededalasannya, menunjuk ke GSI yang mendorong penggunaannya melampaui batas akun. Pelambatan ini terjadi secara independen untuk setiap GSI yang melampaui batas. Untuk informasi tentang kuota layanan per tabel, per akun, regional, lihat. Kuota di Amazon DynamoDB