Model Konkurensi Amazon QLDB

Amazon QLDB dimaksudkan untuk memenuhi kebutuhan beban kerja pemrosesan transaksi online (OLTP) berkinerja tinggi. QLDB mendukung kemampuan query SQL-seperti, dan memberikan transaksi ACID penuh. Selain itu, item data QLDB adalah dokumen, memberikan fleksibilitas skema dan pemodelan data intuitif. Dengan jurnal pada intinya, Anda dapat menggunakan QLDB untuk mengakses riwayat lengkap dan dapat diverifikasi dari semua perubahan pada data Anda, dan melakukan streaming transaksi yang koheren ke layanan data lain sesuai kebutuhan.

Pengendalian konkurensi Optimis

Dalam QLDB, kontrol konkurensi diimplementasikan menggunakan kontrol konkurensi optimis (OCC). OCC beroperasi pada prinsip bahwa beberapa transaksi sering dapat diselesaikan tanpa mengganggu satu sama lain.

Menggunakan OCC, transaksi di QLDB tidak memperoleh kunci pada sumber daya database dan beroperasi dengan isolasi serializable penuh. QLDB menjalankan transaksi bersamaan secara serial, sehingga menghasilkan efek yang sama seperti jika transaksi tersebut dimulai secara serial.

Sebelum melakukan, setiap transaksi melakukan pemeriksaan validasi untuk memastikan bahwa tidak ada transaksi berkomitmen lainnya yang memodifikasi data yang diakses. Jika pemeriksaan ini mengungkapkan modifikasi yang bertentangan, atau keadaan perubahan data, transaksi yang melakukan ditolak. Namun, transaksi dapat dimulai ulang.

Ketika transaksi menulis ke QLDB, pemeriksaan validasi model OCC diimplementasikan oleh QLDB itu sendiri. Jika transaksi tidak dapat ditulis ke jurnal karena kegagalan dalam fase verifikasi OCC, QLDB mengembalikanOccConflictException ke lapisan aplikasi. Perangkat lunak aplikasi bertanggung jawab untuk memastikan bahwa transaksi dimulai ulang. Aplikasi harus membatalkan transaksi yang ditolak dan kemudian mencoba kembali seluruh transaksi dari awal.

Untuk mempelajari cara driver QLDB menangani dan mencoba ulang konflik OCC dan pengecualian sementara lainnya, lihatMemahami kebijakan coba ulang dengan pengemudi di Amazon QLDB.

Menggunakan indeks untuk menghindari pemindaian tabel penuh

Dalam QLDB, setiap pernyataan PartiQL (termasuk setiapSELECT permintaan) diproses dalam transaksi dan tunduk pada batas batas waktu transaksi.

Sebagai praktik terbaik, Anda harus menjalankan pernyataan dengan klausaWHERE predikat yang menyaring pada bidang yang diindeks atau ID dokumen. QLDB membutuhkan operator kesetaraan pada bidang diindeks untuk secara efisien mencari dokumen; misalnya,WHERE indexedField = 123 atauWHERE indexedField IN (456, 789).

Tanpa pencarian yang diindeks ini, QLDB perlu melakukan pemindaian tabel penuh saat membaca dokumen. Hal ini dapat menyebabkan latensi kueri dan batas waktu transaksi, dan juga meningkatkan kemungkinan konflik OCC dengan transaksi yang bersaing.

Misalnya, pertimbangkan tabel bernamaVehicle yang memiliki indeks diVIN lapangan saja. Itu berisi dokumen-dokumen berikut.

VIN	Membuat	Model	Warna
"1N4AL11D75C109151"	"Audi"	"A5"	"Silver"
"KM8SRDHF6EU074761"	"Tesla"	"Model S"	"Blue"
"3HGGK5G53FM761765"	"Ducati"	"Monster 1200"	"Yellow"
"1HVBBAANXWH544237"	"Ford"	"F 150"	"Black"
"1C4RJFAG0FC625797"	"Mercedes"	"CLK 350"	"White"

Dua pengguna bersamaan bernama Alice dan Bob bekerja dengan tabel yang sama dalam buku besar. Mereka ingin memperbarui dua dokumen yang berbeda, sebagai berikut.

Alice:

UPDATE Vehicle AS v
SET v.Color = 'Blue'
WHERE v.VIN = '1N4AL11D75C109151'

Bob:

UPDATE Vehicle AS v
SET v.Color = 'Red'
WHERE v.Make = 'Tesla' AND v.Model = 'Model S'

Misalkan Alice dan Bob memulai transaksi mereka pada saat yang sama. UPDATEPernyataan Alice melakukan pencarian diindeks diVIN lapangan, sehingga hanya perlu membaca bahwa satu dokumen. Alice selesai dan berhasil melakukan transaksinya terlebih dahulu.

pernyataan Bob menyaring pada bidang non-diindeks, sehingga melakukan scan tabel dan pertemuanOccConflictException. Ini karena transaksi Alice yang berkomitmen memodifikasi data yang diakses oleh pernyataan Bob, yang mencakup setiap dokumen dalam tabel—tidak hanya dokumen yang diperbarui Bob.

Penyisipan konflik OCC

Konflik OCC dapat mencakup dokumen yang baru disisipkan—tidak hanya dokumen yang sebelumnya ada. Pertimbangkan diagram berikut, di mana dua pengguna serentak (Alice dan Bob) bekerja dengan tabel yang sama di buku besar. Mereka berdua ingin memasukkan dokumen baru hanya di bawah kondisi bahwa nilai predikat belum ada.

Dalam contoh ini, baik Alice dan Bob menjalankan berikutSELECT danINSERT pernyataan dalam satu transaksi. Aplikasi mereka menjalankanINSERT pernyataan hanya jikaSELECT pernyataan tidak mengembalikan hasil.

SELECT * FROM Vehicle v WHERE v.VIN = 'ABCDE12345EXAMPLE'

INSERT INTO Vehicle VALUE
{
    'VIN' : 'ABCDE12345EXAMPLE',
    'Type' : 'Wagon',
    'Year' : 2019,
    'Make' : 'Subaru',
    'Model' : 'Outback',
    'Color' : 'Gray'
}

Misalkan Alice dan Bob memulai transaksi mereka pada saat yang sama. KeduaSELECT pertanyaan mereka kembali tidak ada dokumen yang ada denganVIN dariABCDE12345EXAMPLE. Jadi, aplikasi mereka melanjutkan denganINSERT pernyataan itu.

Alice selesai dan berhasil melakukan transaksinya terlebih dahulu. Kemudian, Bob mencoba untuk melakukan transaksinya, tetapi QLDB menolaknya dan melemparOccConflictException. Ini karena transaksi berkomitmen Alice memodifikasi kumpulan hasilSELECT kueri Bob, dan OCC mendeteksi konflik ini sebelum melakukan transaksi Bob.

SELECTQuery diperlukan untuk contoh transaksi ini menjadi idempoten. Bob kemudian dapat mencoba kembali seluruh transaksinya dari awal. TapiSELECT query berikutnya akan kembali dokumen yang Alice dimasukkan, sehingga aplikasi Bob tidak akan menjalankanINSERT.

Melakukan transaksi idempoten

Transaksi insert di bagian sebelumnya juga merupakan contoh transaksi idempoten. Dengan kata lain, menjalankan transaksi yang sama beberapa kali menghasilkan hasil yang identik. Jika Bob menjalankanINSERT tanpa terlebih dahulu memeriksa apakah tertentuVIN sudah ada, tabel mungkin berakhir dengan dokumen yang memilikiVIN nilai duplikat.

Pertimbangkan skenario percobaan ulang lainnya selain konflik OCC. Misalnya, ada kemungkinan bahwa QLDB berhasil melakukan transaksi di sisi server, tetapi klien kali keluar sambil menunggu respon. Sebagai praktik terbaik, buat transaksi tulis Anda idempoten untuk menghindari efek samping yang tidak terduga dalam kasus konkurensi atau percobaan ulang.

Redaksi Konflik OCC

QLDB mencegah redaksi bersamaan revisi pada blok jurnal yang sama. Pertimbangkan contoh di mana dua pengguna bersamaan (Alice dan Bob) ingin menyunting dua revisi dokumen berbeda yang dilakukan pada blok yang sama dalam buku besar. Pertama, Alice meminta redaksi satu revisi dengan menjalankan prosedur yangREDACT_REVISION disimpan, sebagai berikut.

EXEC REDACT_REVISION `{strandId:"JdxjkR9bSYB5jMHWcI464T", sequenceNo:17}`, '5PLf9SXwndd63lPaSIa0O6', 'ADR2Ll1fGsU4Jr4EqTdnQF'

Kemudian, sementara permintaan Alice masih diproses, Bob meminta redaksi revisi lain, sebagai berikut.

EXEC REDACT_REVISION `{strandId:"JdxjkR9bSYB5jMHWcI464T", sequenceNo:17}`, '8F0TPCmdNQ6JTRpiLj2TmW', '05K8zpGYWynDlEOK5afDRc'

QLDB menolak permintaan Bob denganOccConflictException meskipun mereka mencoba untuk menyunting dua revisi dokumen yang berbeda. Ini karena revisi Bob terletak di blok yang sama dengan revisi yang disunting Alice. Setelah permintaan Alice selesai diproses, Bob kemudian dapat mencoba lagi permintaan redaksinya.

Demikian pula, jika dua transaksi bersamaan mencoba menyunting revisi yang sama, hanya satu permintaan yang dapat diproses. Permintaan lainnya gagal dengan pengecualian konflik OCC sampai redaksi selesai. Setelah itu, setiap permintaan untuk menyunting revisi yang sama akan menghasilkan kesalahan yang menunjukkan revisi sudah dihapus.

Mengelola sesi serentak

Jika Anda memiliki pengalaman menggunakan sistem manajemen database relasional (RDBMS), Anda mungkin terbiasa dengan batas koneksi konkurensi. QLDB tidak memiliki konsep yang sama dari koneksi RDBMS tradisional karena transaksi dijalankan dengan permintaan HTTP dan pesan respon.

Dalam QLDB, konsep analog adalah sesi aktif. Sesi secara konseptual mirip dengan login pengguna—ia mengelola informasi tentang permintaan transaksi data Anda ke buku besar. Sesi aktif adalah sesi yang secara aktif menjalankan transaksi. Ini juga bisa menjadi sesi yang baru-baru ini menyelesaikan transaksi di mana layanan mengantisipasi akan segera memulai transaksi lain. QLDB mendukung satu transaksi yang berjalan secara aktif per sesi.

Batas sesi aktif bersamaan per buku besar didefinisikan dalamKuota dan batasan di Amazon QLDB. Setelah batas ini tercapai, setiap sesi yang mencoba memulai transaksi akan mengakibatkan error (LimitExceededException).

Untuk informasi tentang siklus hidup sesi dan cara driver QLDB menangani sesi saat menjalankan transaksi data, lihatManajemen sesi dengan pengemudi. Untuk praktik terbaik untuk mengonfigurasi kumpulan sesi dalam aplikasi Anda menggunakan driver QLDB, lihatMengonfigurasi QldbDriver objek di rekomendasi driver Amazon QLDB.