Mengapa GSI DynamoDB men-throttle write tabel dasar

Anda menulis ke tabel Anda. Write gagal dengan exception throughput — tetapi exception menamai Global Secondary Index, bukan tabel. Tabel punya kapasitas cadangan.

Datang dari SQL, itu omong kosong: secondary index tidak bisa memblokir INSERT. Di DynamoDB bisa, dan mekanismenya disebut GSI back-pressure.

Mengapa GSI DynamoDB men-throttle write tabel dasar?

DynamoDB men-throttle write tabel dasar karena setiap write juga mereplikasi ke tiap GSI, dan jika partisi GSI tidak bisa menyerap bagiannya, DynamoDB menerapkan back-pressure agar indeks tidak tertinggal secara permanen. Jadi GSI yang under-provisioned atau key kardinalitas rendah menjadi langit-langit keras pada laju write tabel dasar Anda.

• Write ke tabel dasar juga menulis ke setiap GSI. Jika GSI tidak bisa menyerap bagiannya, DynamoDB men-throttle write tabel dasar agar indeks tidak tertinggal secara permanen. (Dokumen AWS)
• Tabel dasar yang merata tidak menyelamatkan Anda. GSI dipartisi by key-nya sendiri. Key GSI kardinalitas rendah (seperti status) menciptakan hot index partition bahkan saat write tabel dasar tersebar sempurna.
• Exception berbohong soal korban. ResourceArn menunjuk ke GSI; operasi yang sebenarnya di-throttle adalah write Anda ke tabel.
• Perbaikannya adalah kapasitas atau desain key, bukan loop retry — naikkan throughput GSI, atau pilih partition key GSI yang menyebar.

Bagaimana satu write menyentuh indeks

PutItem pada tabel dasar bukan satu write. DynamoDB mereplikasi atribut yang diproyeksikan item ke tiap GSI secara asinkron, pada model eventually consistent. Satu write logis fan-out ke N write fisik — tabel plus setiap indeks.

Replikasi itu tidak gratis dan tidak opsional. GSI harus menyusul, atau indeks semakin drift dari tabel pada setiap operasi.

Untuk menghentikan drift itu, DynamoDB menerapkan back-pressure: ia men-throttle write sumber agar indeks tidak pernah basi tanpa batas.

Jadi kapasitas tulis GSI adalah langit-langit keras pada laju write tabel dasar Anda — meskipun Anda tidak pernah menulis ke GSI secara langsung.

Contoh kerja: tabel order

Katakan Anda menjalankan tabel order. Item dasar:

Write tabel dasar sehat. CUST#... punya kardinalitas tinggi, jadi write order menyebar merata lintas partisi dasar. Tidak ada hot key, kapasitas berlimpah.

Sekarang Anda menambah GSI untuk menjawab "tampilkan setiap order dalam state tertentu":

Empat nilai partition key yang mungkin. Selama flash sale, hampir setiap order baru mendarat di order_state = "PENDING". Setiap write itu menghantam partisi GSI yang sama.

Partisi itu punya limit throughput per-partisi, dan Anda baru saja mengarahkan seluruh badai write ke sana.

Tabel dasar baik-baik saja. Partisi GSI PENDING terbakar. DynamoDB men-throttle PutItem tabel dasar untuk melindungi indeks.

Alur yang menggigit Anda

Jalur back-pressure — write dasar seimbang, write indeks terkonsentrasi:

Partisi GSI panas menolak write tabel dasar yang mengisinya.

Baca exception, bukan naluri Anda

Tipe exception memberi tahu tepat langit-langit mana yang Anda tabrak. ResourceArn menamai GSI; op yang di-throttle tetap write tabel.

Sumber: Understanding GSI write throttling and back pressure.

Reason KeyRange adalah penunjuk untuk kasus hot-partition di atas: kapasitas GSI keseluruhan bisa terlihat baik sementara satu rentang key jenuh.

Bagaimana cara memperbaikinya

Beri GSI ruang. Penyebab paling sederhana adalah under-provisioning. GSI punya kapasitas baca dan tulis sendiri, sepenuhnya terpisah dari tabel — lihat GSI vs LSI.

Jika Anda mem-provision tabel dengan dermawan dan meninggalkan GSI tipis, naikkan kapasitas tulis GSI (atau max on-demand-nya).

Perbaiki partition key. Kapasitas tidak menyelamatkan key kardinalitas rendah — Anda tidak bisa out-provision satu partisi panas. Pilih partition key GSI yang menyebar.

Susun: order_state#shard di mana shard adalah suffix acak kecil, atau lipat tanggal (PENDING#2026-06-23). Write menyebar lintas partisi dan Anda tetap Query sebuah state dengan Query shard.

Project lebih sedikit atribut. Setiap write GSI menyalin atribut yang diproyeksikan. Proyeksi KEYS_ONLY atau INCLUDE ketat berarti write indeks lebih kecil dan tekanan lebih sedikit daripada ALL. Jangan project apa yang tidak akan pernah Anda baca dari indeks.

Jatuhkan GSI jika hanya untuk reporting. Jika "order by state" adalah pertanyaan admin sesekali, bukan hot path, scan berkala dengan filter mungkin mengalahkan indeks yang panas permanen — timbang terhadap Query vs Scan.

Saat Anda Query indeks itu, Expression Builder menulis KeyConditionExpression untuk Anda — mis. #s = :state AND begins_with(SK, :prefix) — dengan name dan value yang di-escape dengan benar:

KeyConditionExpression     "#s = :state AND begins_with(SK, :prefix)"
ExpressionAttributeNames   { "#s": "order_state" }
ExpressionAttributeValues  { ":state": { "S": "PENDING" }, ":prefix": { "S": "ORD#2026-06-23" } }

Jebakan yang perlu diingat

Naluri relasional — "indeks hanya sedikit memperlambat write" — tidak mentransfer. GSI DynamoDB adalah dependensi throughput, bukan struktur pasif. Under-size atau pilih key yang menggumpal, dan ia back-pressure tabel yang dilayaninya.

Pantau ConsumedWriteCapacityUnits dan WriteThrottleEvents pada dimensi GSI, bukan hanya tabel, dan pakai Contributor Insights untuk menemukan hot key.

Langkah selanjutnya

• GSI vs LSI — mengapa GSI punya kapasitas sendiri dan partition key berbeda.
• Single-table design — meng-overload satu GSI untuk melayani banyak pattern tanpa mengalikan indeks panas.
• Query vs Scan — kapan indeks tidak sebanding dengan biaya tulisnya.

Coba DynoTable untuk memeriksa setiap GSI di tabel Anda — skema key dan jumlah item — dan Query indeks Anda sebelum sale membuatnya merah.