Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Kontrol konkurensi di Aurora DSQL
Konkurensi memungkinkan beberapa sesi untuk mengakses dan memodifikasi data secara bersamaan tanpa mengorbankan integritas dan konsistensi data. Aurora DSQL menyediakan kompatibilitas [ PostgreSQL ](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility.html) sambil menerapkan mekanisme kontrol konkurensi yang modern dan bebas kunci. Ini mempertahankan kepatuhan ACID penuh melalui isolasi snapshot, memastikan konsistensi dan keandalan data.
Keuntungan utama Aurora DSQL adalah arsitekturnya yang bebas kunci, yang menghilangkan hambatan kinerja database yang umum. Aurora DSQL mencegah transaksi lambat memblokir operasi lain dan menghilangkan risiko kebuntuan. Pendekatan ini membuat Aurora DSQL sangat berharga untuk aplikasi throughput tinggi di mana kinerja dan skalabilitas sangat penting.
## Respons kontrol konkurensi
Aurora DSQL menggunakan kontrol konkurensi optimis (OCC), yang bekerja berbeda dari sistem berbasis kunci tradisional. Alih-alih menggunakan kunci, OCC mengevaluasi konflik pada waktu komit. Proses evaluasi konflik waktu komit ini juga disebut ajudikasi. Ketika Aurora DSQL mendeteksi konflik, ia mengembalikan kegagalan serialisasi PostgreSQL dengan kode SQLSTATE. `40001` Pesan respons menyertakan kode OCC yang mengidentifikasi jenis konflik:
**OC000 - Konflik data**
Dua transaksi mencoba memodifikasi baris yang sama. Transaksi dengan waktu komit paling awal berhasil, dan transaksi yang bertentangan menerima respons OC000:
```
ERROR: change conflicts with another transaction (OC000) (SQLSTATE 40001)
```
**OC001 - Konflik skema**
Katalog skema cache sesi sudah kedaluwarsa. Ketika Aurora DSQL mendeteksi bahwa versi katalog telah berubah sejak sesi memuat cache-nya, dan transaksi tidak dapat dengan aman melakukan rebase ke versi saat ini, transaksi menerima respons OC001:
```
ERROR: schema has been updated by another transaction (OC001) (SQLSTATE 40001)
```
Operasi apa pun yang memodifikasi katalog skema dapat menyebabkan respons OC001, termasuk pernyataan DDL seperti `CREATE TABLE` dan`ALTER TABLE`, serta `GRANT` pernyataan dan. `REVOKE` Untuk informasi selengkapnya, lihat [DDL dan transaksi terdistribusi di Aurora DSQL](working-with-ddl.md).
Rancang aplikasi Anda untuk menerapkan logika coba ulang untuk menangani respons ini. Pola desain yang ideal adalah idempoten, memungkinkan percobaan ulang transaksi sebagai jalan pertama bila memungkinkan. Logika yang disarankan mirip dengan logika aborsi dan coba lagi dalam situasi batas waktu atau kebuntuan kunci PostgreSQL standar. Namun, OCC mengharuskan aplikasi Anda untuk menjalankan logika ini lebih sering.
## Jenis konflik data
Karena mekanisme kontrol konkurensi Aurora DSQL, `SELECT ... FOR KEY SHARE` klausa `SELECT ... FOR UPDATE` dan menghasilkan hasil melalui deteksi konflik yang optimis pada waktu komit daripada mengunci. Di Aurora DSQL, ketika satu transaksi menulis baris dan yang lain membacanya dengan salah satu klausa sebelumnya, konflik mungkin muncul pada waktu komit tergantung pada kolom mana yang digunakan transaksi. Klausa berikut menentukan bagaimana Aurora DSQL mendeteksi konflik ini.
**Definisi kolom kunci**
**Kolom kunci ** adalah kolom yang merupakan anggota indeks unik, non-parsial, non-ekspresi. Semua kolom lainnya adalah kolom non-kunci.
**`SELECT ... FOR UPDATE`**
Menyatakan bahwa Aurora DSQL menilai baris yang dipilih seolah-olah transaksi menulis ke baris tersebut. Jika transaksi lain berjalan`UPDATE`,`DELETE`,`SELECT ... FOR UPDATE`, atau `SELECT ... FOR KEY SHARE` pada baris yang sama dan melakukan commit terlebih dahulu, transaksi yang dijalankan `SELECT ... FOR UPDATE` gagal dengan `OC000` respons. Klausa ini bertentangan dengan penulisan bersamaan ke baris, dan dengan pembacaan `FOR UPDATE` atau `FOR KEY SHARE` bersamaan.
**`SELECT ... FOR KEY SHARE`**
Menyatakan bahwa transaksi tergantung pada kolom kunci dari baris yang dipilih. Jika transaksi lain menghapus baris, mengubah kolom kuncinya, atau menjalankan `SELECT ... FOR UPDATE` dan melakukan commit terlebih dahulu, transaksi yang dijalankan `SELECT ... FOR KEY SHARE` gagal dengan respons`OC000`. Kolom yang bersamaan `UPDATE` dengan kolom non-kunci tidak bertentangan.
Aurora DSQL tidak mendukung `FOR SHARE` klausa `NO KEY UPDATE` or. Namun, DML secara implisit menggunakan mekanisme tersebut`NO KEY UPDATE`. Matriks berikut merangkum ketika dua transaksi bersamaan yang mengakses baris yang sama bertentangan. An `X` menunjukkan bahwa dua operasi bertentangan: transaksi mana pun yang terakhir dilakukan gagal dengan `OC000` respons. Sel kosong menunjukkan bahwa kedua transaksi dapat dilakukan.
| Operasi | `INSERT`,`DELETE`, `UPDATE` (kolom kunci), atau `SELECT ... FOR UPDATE` | `UPDATE`(hanya kolom non-kunci) | `SELECT ... FOR KEY SHARE` |
| --- | --- | --- | --- |
| INSERT,DELETE, UPDATE (kolom kunci), atau SELECT ... FOR UPDATE | X | X | X |
| UPDATE(hanya kolom non-kunci) | X | X | |
| SELECT ... FOR KEY SHARE | X | | |
## Pedoman untuk mengoptimalkan kinerja transaksi
Untuk mengoptimalkan kinerja, minimalkan pertikaian tinggi pada tombol tunggal atau rentang kunci kecil. Untuk mencapai tujuan ini, rancang skema Anda untuk menyebarkan pembaruan di rentang kunci cluster Anda dengan menggunakan pedoman berikut:
+ Pilih kunci utama acak untuk tabel Anda.
+ Hindari pola yang meningkatkan pertengkaran pada tombol tunggal. Pendekatan ini memastikan kinerja optimal bahkan ketika volume transaksi tumbuh.