Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Model QLDB konkurensi Amazon

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

Kontrol konkurensi yang optimis

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

MenggunakanOCC, transaksi di QLDB tidak memperoleh kunci pada sumber daya database dan beroperasi dengan isolasi serial penuh. QLDBmenjalankan transaksi bersamaan secara serial, sehingga menghasilkan efek yang sama seolah-olah transaksi tersebut dimulai secara serial.

Sebelum melakukan, setiap transaksi melakukan pemeriksaan validasi untuk memastikan bahwa tidak ada transaksi lain yang berkomitmen telah mengubah data yang diakses. Jika pemeriksaan ini menunjukkan modifikasi yang bertentangan, atau keadaan data berubah, transaksi yang dilakukan ditolak. Namun, transaksi dapat dimulai ulang.

Ketika transaksi menulis keQLDB, pemeriksaan validasi OCC model diimplementasikan dengan QLDB sendirinya. Jika transaksi tidak dapat ditulis ke jurnal karena kegagalan dalam fase verifikasiOCC, QLDB mengembalikan OccConflictException 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 QLDB pengemudi menangani dan mencoba kembali OCC konflik dan pengecualian sementara lainnya, lihat. Memahami kebijakan coba lagi dengan pengemudi di Amazon QLDB

Menggunakan indeks untuk menghindari pemindaian tabel penuh

DalamQLDB, setiap pernyataan PartiQL (termasuk SELECT setiap kueri) diproses dalam transaksi dan tunduk pada batas waktu tunggu transaksi.

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

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

Misalnya, pertimbangkan tabel bernama Vehicle yang memiliki indeks di VIN bidang saja. Ini berisi dokumen-dokumen berikut.

Dua pengguna bersamaan bernama Alice dan Bob bekerja dengan tabel yang sama dalam buku besar. Mereka ingin memperbarui dua dokumen 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 yang diindeks di VIN lapangan, jadi hanya perlu membaca satu dokumen itu. Alice selesai dan berhasil melakukan transaksinya terlebih dahulu.

Pernyataan Bob menyaring bidang yang tidak diindeks, sehingga melakukan pemindaian tabel dan menemukan file. OccConflictException Ini karena transaksi komitmen Alice memodifikasi data yang diakses pernyataan Bob, yang mencakup setiap dokumen dalam tabel — tidak hanya dokumen yang diperbarui Bob.

Konflik penyisipan OCC

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

Dalam contoh ini, baik Alice dan Bob menjalankan INSERT pernyataan berikut SELECT dan dalam satu transaksi. Aplikasi mereka menjalankan INSERT pernyataan hanya jika SELECT 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. Kedua SELECT kueri mereka tidak mengembalikan dokumen yang ada dengan aVIN. ABCDE12345EXAMPLE Jadi, aplikasi mereka dilanjutkan dengan INSERT pernyataan itu.

Alice selesai dan berhasil melakukan transaksinya terlebih dahulu. Kemudian, Bob mencoba melakukan transaksinya, tetapi QLDB menolaknya dan melempar. OccConflictException Ini karena transaksi komitmen Alice mengubah kumpulan hasil SELECT permintaan Bob, dan OCC mendeteksi konflik ini sebelum melakukan transaksi Bob.

SELECTKueri diperlukan agar contoh transaksi ini menjadi idempoten. Bob kemudian dapat mencoba kembali seluruh transaksinya dari awal. Tetapi SELECT kueri berikutnya akan mengembalikan dokumen yang disisipkan Alice, sehingga aplikasi Bob tidak akan menjalankan. INSERT

Membuat 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 menjalankan INSERT tanpa terlebih dahulu memeriksa apakah yang tertentu VIN sudah ada, tabel mungkin berakhir dengan dokumen yang memiliki VIN nilai duplikat.

Pertimbangkan skenario coba lagi lainnya selain OCC konflik. Misalnya, mungkin saja QLDB berhasil melakukan transaksi di sisi server, tetapi klien kehabisan waktu sambil menunggu respons. Sebagai praktik terbaik, buat transaksi tulis Anda idempoten untuk menghindari efek samping yang tidak terduga dalam kasus konkurensi atau percobaan ulang.

Konflik redaksi OCC

QLDBmencegah redaksi revisi secara bersamaan 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 dari satu revisi dengan menjalankan prosedur REDACT_REVISION tersimpan, 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'

QLDBmenolak permintaan Bob dengan OccConflictException 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 kembali permintaan redaksinya.

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

Mengelola sesi bersamaan

Jika Anda memiliki pengalaman menggunakan sistem manajemen database relasional (RDBMS), Anda mungkin akrab dengan batas koneksi bersamaan. QLDBtidak memiliki konsep RDBMS koneksi tradisional yang sama karena transaksi dijalankan dengan pesan HTTP permintaan dan respons.

DalamQLDB, 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 aktif menjalankan transaksi. Ini juga bisa menjadi sesi yang baru-baru ini menyelesaikan transaksi di mana layanan mengantisipasi akan segera memulai transaksi lain. QLDBmendukung satu transaksi yang aktif berjalan per sesi.

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

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