View a markdown version of this page

Kontrol konkurensi di Aurora DSQL - Amazon Aurora DSQL
Respons kontrol konkurensiJenis konflik dataPedoman untuk mengoptimalkan kinerja transaksi

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 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 danALTER TABLE, serta GRANT pernyataan dan. REVOKE Untuk informasi selengkapnya, lihat DDL dan transaksi terdistribusi di Aurora DSQL.

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 berjalanUPDATE,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 responsOC000. 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 tersebutNO 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.