Tingkat Isolasi Transaksi di Neptune

Amazon Neptune mengimplementasikan tingkat isolasi transaksi yang berbeda untuk kueri baca-saja dan kueri mutasi. Kueri SPARQL dan Gremlin diklasifikasikan sebagai baca-saja atau mutasi berdasarkan kriteria sebagai berikut:

• Di SPARQL, ada perbedaan yang jelas antara kueri baca (SELECT, ASK, CONSTRUCT, dan DESCRIBE sebagaimana didefinisikan dalam spesifikasi Bahasa Kueri SPARQL 1.1), dan kueri mutasi (INSERT dan DELETE sebagaimana didefinisikan dalam spesifikasi Pembaruan SPARQL 1.1).

  Perhatikan bahwa Neptune memperlakukan beberapa kueri mutasi dikirimkan bersama-sama (misalnya, dalam pesan POST, dipisahkan dengan titik koma) sebagai transaksi tunggal. Mereka dijamin berhasil atau gagal sebagai unit atom, dan dalam kasus kegagalan, perubahan parsial digulung kembali.

• Namun, di Gremlin, Neptunus mengklasifikasikan kueri sebagai kueri hanya-baca atau kueri mutasi berdasarkan apakah kueri berisi langkah-langkah jalur kueri seperti,,, atau yang memanipulasi data. addE() addV() property() drop() Jika kueri berisi langkah jalur apa pun, maka diklasifikasikan dan dieksekusi sebagai kuery mutasi.

Hal ini juga memungkinkan untuk menggunakan sesi berdiri di Gremlin. Untuk informasi selengkapnya, lihat Sesi berbasis skrip Gremlin. Dalam sesi ini, semua kueri, termasuk kueri hanya-baca, dijalankan di bawah isolasi yang sama dengan kueri mutasi pada titik akhir penulis.

Menggunakan sesi baca-tulis baut di OpenCypher, semua kueri termasuk kueri hanya-baca dijalankan di bawah isolasi yang sama dengan kueri mutasi, pada titik akhir penulis.

Isolasi kueri hanya-baca di Neptunus

Neptune mengevaluasi kueri baca-saja di bawah semantik isolasi snapshot. Ini berarti bahwa kueri baca saja secara logis beroperasi pada snapshot yang konsisten dari database yang diambil ketika evaluasi kueri dimulai. Neptune kemudian dapat menjamin bahwa tidak ada fenomena berikut yang akan terjadi:

• Dirty reads – Kueri baca-saja di Neptune tidak akan pernah melihat data yang tidak terikat dari transaksi bersamaan.

• Non-repeatable reads – Sebuah transaksi baca-saja yang membaca data yang sama lebih dari sekali akan selalu mendapatkan nilai yang sama.

• Phantom reads –  Sebuah transaksi baca-saja tidak akan pernah membaca data yang ditambahkan setelah transaksi dimulai.

Karena isolasi snapshot dicapai menggunakan multiversion concurrency control (MVCC), kueri baca-saja tidak perlu mengunci data dan karena itu tidak memblokir kueri mutasi.

Replika baca hanya menerima kueri baca-saja, sehingga semua kueri yang berlawanan dengan replika baca dieksekusi replika baca di bawah semantik isolasi SNAPSHOT.

Satu-satunya pertimbangan tambahan ketika meng-kueri replika baca adalah bahwa ada lag replikasi kecil antara penulis dan replika baca. Ini berarti bahwa pembaruan yang dibuat pada penulis mungkin mengambil waktu singkat untuk disebarkan ke replika baca yang sedang Anda baca. Waktu replikasi sebenarnya tergantung pada pemuatan tulis terhadap instance utama. Arsitektur Neptunus mendukung replikasi latensi rendah dan lag replikasi diinstrumentasi dalam metrik Amazon. CloudWatch

Namun, karena tingkat isolasi SNAPSHOT, kueri baca selalu melihat keadaan yang konsisten dari database, bahkan jika itu bukan yang terbaru.

Dalam kasus ketika Anda memerlukan jaminan yang kuat bahwa kueri mengamati hasil dari pembaruan sebelumnya, kirim kueri ke titik akhir penulis itu sendiri alih-alih ke replika baca.

Isolasi kueri mutasi di Neptunus

Pembacaan yang dibuat sebagai bagian dari kueri mutasi dijalankan di bawah isolasi transaksi READ COMMITTED, yang mengeliminasi kemungkinan dirty-reads. Melampaui jaminan biasa yang disediakan untuk isolasi transaksi READ COMMITTED, Neptune memberikan jaminan yang kuat bahwa baik pembacaan NON-REPEATABLE dan PHANTOM bisa terjadi.

Jaminan kuat ini dicapai dengan mengunci catatan dan rentang catatan saat membaca data. Hal ini mencegah transaksi bersamaan dari membuat penyisipan atau penghapusan dalam rentang indeks setelah mereka baca, sehingga menjamin pembacaan berulang.

catatan

Namun, transaksi mutasi bersamaan Tx2 bisa dimulai setelah dimulainya transaksi mutasi Tx1, dan dapat melakukan perubahan sebelum Tx1 mengunci data untuk dibaca. Dalam kasus itu, Tx1 akan melihat perubahan Tx2 seperti jika Tx2 telah selesai sebelum Tx1dimulai. Karena ini hanya berlaku untuk perubahan yang dilakukan, dirty read tidak akan pernah terjadi.

Untuk memahami mekanisme penguncian yang digunakan Neptune untuk kueri mutasi, terlebih dahulu itu membantu memahami detail Neptune Model Data Grafik dan Strategi Pengindeksan. Neptune mengelola data menggunakan tiga indeks, yaitu SPOG, POGS, dan GPSO.

Untuk mencapai pembacaan berulang untuk tingkat transaksi READ COMMITTED, Neptune mengambil kunci rentang dalam indeks yang sedang digunakan. Sebagai contoh, jika kueri mutasi membaca semua properti dan edge keluar dari sebuah vertex bernama person1, simpul akan mengunci seluruh rentang yang didefinisikan oleh awalan S=person1 dalam indeks SPOG sebelum membaca data.

Mekanisme yang sama berlaku saat menggunakan indeks lain. Sebagai contoh, ketika transaksi mutasi mencari semua pasangan vertex sumber-target untuk label edge yang diberikan menggunakan indeks POGS, rentang label edge dalam posisi P akan terkunci. Setiap transaksi bersamaan, terlepas dari apakah itu baca-saja atau kueri mutasi, masih bisa melakukan pembacaan dalam rentang yang terkunci. Namun, setiap mutasi yang melibatkan penyisipan atau penghapusan catatan baru dalam rentang prefiks terkunci akan memerlukan kunci eksklusif dan akan dicegah.

Dengan kata lain, ketika rentang indeks telah dibaca oleh transaksi mutasi, ada jaminan kuat bahwa rentang ini tidak akan dimodifikasi oleh transaksi bersamaan apapun sampai akhir transaksi pembacaan. Ini menjamin bahwa tidak ada non-repeatable reads akan terjadi.

Resolusi Konflik Menggunakan Lock-Wait Timeout

Jika transaksi kedua mencoba memodifikasi catatan dalam rentang tempat transaksi pertama telah terkunci, Neptune mendeteksi konflik dengan segera dan memblokir transaksi kedua.

Jika tidak ada deadlock dependensi terdeteksi, Neptune secara otomatis memberlakukan mekanisme timeout lock-wait, di mana transaksi yang diblokir menunggu transaksi yang menahan kunci hingga 60 detik untuk diselesaikan dan dilepaskan kuncinya.

• Jika timeout lock-wait berakhir sebelum kunci dirilis, transaksi yang diblokir akan diroll-back.

• Jika kunci dilepaskan dalam timeout lock-wait, transaksi kedua tidak diblokir dan berhasil menyelesaikan tanpa perlu mencoba lagi.

Namun, jika Neptune mendeteksi deadlock dependensi diantara dua transaksi, rekonsiliasi otomatis konflik tidak dimungkinkan. Dalam hal ini, Neptunus segera membatalkan dan memutar kembali salah satu dari dua transaksi tanpa memulai batas waktu tunggu kunci-tunggu. Neptunus melakukan upaya terbaik untuk memutar kembali transaksi yang memiliki catatan paling sedikit dimasukkan atau dihapus.

Kunci rentang dan konflik palsu

Neptunus mengambil kunci jangkauan menggunakan kunci celah. Kunci celah adalah kunci pada celah antara catatan indeks, atau kunci pada celah sebelum catatan indeks pertama atau setelah catatan indeks terakhir.

Neptunus menggunakan tabel kamus yang disebut untuk mengaitkan nilai ID numerik dengan literal string tertentu. Berikut adalah contoh keadaan kamus Neptunus seperti itu: tabel:

String	ID
jenis	1
default_graph	2
orang_3	3
orang_1	5
tahu	6
orang_2	7
usia	8
tepi_1	9
lives_in	10
New York	11
Orang	12
Tempat	13
tepi_2	14

String di atas termasuk dalam model grafik properti, tetapi konsep berlaku sama untuk semua model grafik RDF juga.

Keadaan yang sesuai dari indeks SPOG (Subject-Predicate-Object_Graph) ditunjukkan di bawah di sebelah kiri. Di sebelah kanan, string yang sesuai ditampilkan, untuk membantu memahami apa arti data indeks.

S (ID)	P (ID)	O (ID)	G (ID)		S (string)	P (string)	O (string)	G (string)
3	1	12	2		orang_3	jenis	Orang	default_graph
5	1	12	2		orang_1	jenis	Orang	default_graph
5	6	3	9		orang_1	tahu	orang_3	tepi_1
5	8	40	2		orang_1	usia	40	default_graph
5	10	11	14		orang_1	lives_in	New York	tepi_2
7	1	12	2		orang_2	jenis	Orang	default_graph
11	1	13	2		New York	jenis	Tempat	default_graph

Sekarang, jika kueri mutasi membaca semua properti dan tepi keluar dari simpul bernamaperson_1, node akan mengunci seluruh rentang yang ditentukan oleh awalan S=person_1 dalam indeks SPOG sebelum membaca data. Kunci rentang akan menempatkan kunci celah pada semua catatan yang cocok dan catatan pertama yang tidak cocok. Catatan yang cocok akan dikunci, dan catatan yang tidak cocok tidak akan dikunci. Neptunus akan menempatkan kunci celah sebagai berikut:

• 5 1 12 2 (celah 1)

• 5 6 3 9 (celah 2)

• 5 8 40 2 (celah 3)

• 5 10 11 14 (celah 4)

• 7 1 12 2 (celah 5)

Ini mengunci catatan berikut:

• 5 1 12 2

• 5 6 3 9

• 5 8 40 2

• 5 10 11 14

Dalam keadaan ini, operasi berikut diblokir secara sah:

• Penyisipan properti atau tepi baru untukS=person_1. Properti baru yang berbeda dari type atau tepi baru harus masuk ke celah 2, celah 3, celah 4, atau celah 5, yang semuanya terkunci.

• Penghapusan salah satu catatan yang ada.

Pada saat yang sama, beberapa operasi bersamaan akan diblokir secara salah (menghasilkan konflik palsu):

• Setiap properti atau penyisipan tepi untuk S=person_3 diblokir karena harus masuk ke celah 1.

• Setiap penyisipan simpul baru yang diberi ID antara 3 dan 5 akan diblokir karena harus masuk ke celah 1.

• Setiap penyisipan simpul baru yang diberi ID antara 5 dan 7 akan diblokir karena harus masuk ke celah 5.

Kunci celah tidak cukup tepat untuk mengunci celah untuk satu predikat tertentu (misalnya, untuk mengunci gap5 untuk predikat). S=5

Kunci rentang hanya ditempatkan di indeks tempat pembacaan terjadi. Dalam kasus di atas, catatan dikunci hanya dalam indeks SPOG, bukan di POGS atau GPSO. Pembacaan untuk kueri dapat dilakukan di semua indeks tergantung pada pola akses, yang dapat dicantumkan menggunakan explain API (untuk Sparql dan untuk Gremlin).

catatan

Kunci celah juga dapat diambil untuk pembaruan bersamaan yang aman pada indeks yang mendasarinya, yang juga dapat menyebabkan konflik palsu. Kunci celah ini ditempatkan independen dari tingkat isolasi atau operasi baca yang dilakukan oleh transaksi.

Konflik palsu dapat terjadi tidak hanya ketika transaksi bersamaan bertabrakan karena kunci celah, tetapi juga dalam beberapa kasus ketika transaksi sedang dicoba lagi setelah segala jenis kegagalan. Jika roll-back yang dipicu oleh kegagalan masih berlangsung dan kunci yang sebelumnya diambil untuk transaksi belum sepenuhnya dirilis, percobaan ulang akan menghadapi konflik palsu dan gagal.

Di bawah beban tinggi, Anda mungkin biasanya menemukan bahwa 3-4% kueri tulis gagal karena konflik palsu. Untuk klien eksternal, konflik palsu semacam itu sulit diprediksi, dan harus ditangani menggunakan percobaan ulang.