♎️ 👩🏻‍🏭 🤷🏽 MVCC sebagai salah satu cara untuk memastikan isolasi transaksi 🕴🏾 🙅🏻 ⏪

Hai, Habr. Nama saya Vladislav Rodin. Saat ini, saya adalah kepala kursus Arsitek Beban Tinggi di OTUS, dan saya juga mengajar kursus arsitektur perangkat lunak.

Khusus untuk permulaan set baru untuk kursus "Arsitek beban tinggi" Saya menulis sedikit materi, yang dengan senang hati saya bagikan kepada Anda.

pengantar

Terakhir kali, kami berbicara dengan Anda tentang konsekuensi dari melemahnya isolasi transaksi di database. Hari ini kita akan membahas secara lebih rinci salah satu cara untuk memastikan isolasi dan penghindaran anomali yang dipertimbangkan ini. Seperti yang mungkin Anda perhatikan, dalam artikel terakhir dua pendekatan sering dibedakan: satu didasarkan pada fakta bahwa catatan memiliki beberapa versi , dan yang kedua pada kenyataan bahwa kami akan memblokir rekaman dengan satu atau lain cara . Dengan demikian, dua kelas basis data dibedakan: versi dan pemblokir . Hari ini kita akan berbicara tentang apa itu pengontrol versi, dan biarkan pertimbangan pemblokir lain kali.

Versiioners

Seperti yang saya katakan, salah satu pendekatan didasarkan pada versi. Itu juga disebut pendekatan optimis atau MVCC (kontrol konkurensi multiversion) . Bahkan, penyimpanan versi untuk transaksi aktif terjadi.

Di mana versi disimpan?

Implementasi mekanisme tergantung pada database. Saya akan memberikan contoh beberapa di antaranya.

PostgreSQL

Setiap transaksi ditandai oleh beberapa id-shnik. Transaksi id-shnik tumbuh secara monoton. Baris mana pun memiliki 2 atribut yang mewakili meta-informasi untuk menyediakan mekanisme: updated_by_id - id transaksi yang terakhir diperbarui catatan ini dan dihapus_by_id - id transaksi yang menghapus catatan ini. Ketika transaksi baru tiba, basis data menentukan id-nicks dari transaksi yang sedang dilakukan, perubahan yang dilakukan oleh transaksi ini akan diabaikan dalam transaksi yang masuk. Ternyata transaksi yang masuk berfungsi seolah-olah dengan versi datanya. Data versi lama disimpan di tempat yang sama dengan yang sekarang. Jika Pembaruan tiba, maka baris lain ditambahkan dan catatan ini menjadi aktif. Juga jelas bahwa untuk operasi yang benar dari skema ini, seorang "pengumpul sampah" diperlukan:jika beberapa catatan telah delete_by_id = 100, dan id-shnik minimum di antara transaksi saat ini adalah 150, maka catatan ini harus dihapus.

MySQL (mesin InnoDB)

Hanya versi saat ini disimpan dalam database MySQL. Ketika Pembaruan tiba, data di dalam file tabel diperbaiki. Setelah menyesuaikan data, versi sebelumnya ada di rollback log. Ada beberapa rollback log di MySQL (berbeda untuk insert'ov dan update'ov). Jika suatu transaksi membutuhkan versi baris sebelumnya, sistem akan membatalkan unduhan dan mengembalikan versi yang diperlukan. Versi ini juga ditentukan oleh id transaksi.

Peramal

Skema ini mirip dengan MySQL: versi saat ini disimpan dalam file data, versi lama dipulihkan berkat batalkan log. Undo log in Oracle ditulis ulang secara siklis. Oleh karena itu, suatu situasi dimungkinkan ketika suatu transaksi membutuhkan versi catatan yang sangat lama, tetapi dalam uraian itu tidak lagi ada. Jika situasi ini terjadi, transaksi akan gagal.

MS SQL

MS SQL memungkinkan masuknya mode versiioner dan pemblokir. Untuk mengaktifkan mode versi dalam pengaturan basis data, Anda harus mengaktifkan snapshot. Dalam MS SQL ada tabel sistem (tempdb), yang dirancang untuk menyimpan tabel sementara. Ini adalah tempdb yang digunakan untuk menyimpan versi lama, sementara tabel berisi versi saat ini. Proses sistem memonitor bahwa dalam tempdb ada versi yang tidak ada yang merujuk, mereka dapat dihapus. Jika transaksi lama, maka versi akan disimpan untuk itu. Tempdb tumbuh, mencapai ukuran maksimumnya, MS SQL mengalokasikan sedikit ruang disk. Jika itu berakhir, maka transaksi dengan isolasi snapshot tidak dapat dilakukan. Jika mode operasi ini digunakan, perlu untuk memantau transaksi panjang,karena kembalinya transaksi seperti itu dalam waktu mungkin biaya sebanyak itu berfungsi, dan mungkin sedikit lebih.

Konflik

Pendekatan ini disebut optimis, karena kami berharap tidak akan ada konflik jika transaksi penggantian data paralel dijalankan. Apa yang terjadi jika terjadi konflik? Misalkan transaksi T1 mengubah 10.000 catatan, dan transaksi T2 mengubah 1 catatan secara paralel. Jika kebetulan bahwa catatan 1 ini termasuk dalam 10.000 itu, maka salah satu transaksi akan dibatalkan: jika T1 dieksekusi pertama, maka T2 akan dibatalkan, jika tidak sebaliknya.

Mekanisme rollback

Mekanisme pengembalian transaksi dalam versi versi tergantung pada implementasinya. Sebagai contoh, di PostgreSQL, transaksi ditandai sebagai dievakuasi dan vakum membebaskan ruang disk. Mekanisme seperti itu cukup cepat. Di Oracle, untuk rollback, data dipulihkan dari undo log. Dalam hal ini, waktu operasi meningkat, namun, masih jauh lebih cepat daripada di loker. MySQL bekerja dengan cara yang sama seperti Oracle.

Kesimpulan

Pendekatan optimis baik karena penulis tidak menghalangi pembaca, pembaca hanya membaca versinya dari data. Oleh karena itu, versi bermanfaat jika beban utama adalah membaca daripada menulis (blog, pelaporan, dan kasus-kasus lain di mana Anda perlu sering membaca dan banyak).

Pelajari lebih lanjut tentang kursus di sini.

MVCC sebagai salah satu cara untuk memastikan isolasi transaksi