Apa yang bisa dihasilkan dari melemahnya tingkat isolasi transaksi dalam database

Halo semuanya. Dalam sentuhan Vladislav Rodin. Saat ini, saya adalah kepala kursus Arsitek Beban Tinggi di OTUS, dan saya juga mengajar kursus arsitektur perangkat lunak.

Selain mengajar, seperti yang Anda lihat, saya telah menulis untuk materi hak cipta blog OTUS Habré dan artikel hari ini saya ingin bertepatan dengan dimulainya kursus «PostgreSQL» , yang sekarang sedang membuka set.




pengantar


The terakhir kali Anda dan saya berbicara tentang bahwa transaksi di database yang digunakan untuk dua tujuan: untuk memastikan toleransi kesalahan dan akses data dalam lingkungan yang kompetitif. Untuk menyelesaikan tugas ini, transaksi harus memiliki properti ACID. Hari ini kita akan berbicara secara rinci tentang huruf I (isolasi) dalam singkatan ini.


Isolasi


Isolasi memecahkan masalah mengakses data dalam lingkungan yang kompetitif, secara efektif memberikan perlindungan terhadap kondisi ras. Idealnya, isolasi berarti serialisasi, yaitu properti yang memastikan bahwa hasil pelaksanaan transaksi secara paralel adalah sama seperti jika mereka dieksekusi secara berurutan. Masalah utama dari properti ini adalah secara teknis sangat sulit untuk diberikan dan, sebagai akibatnya, memiliki dampak signifikan pada kinerja sistem. Itulah sebabnya isolasi sering melemah, menerima risiko beberapa anomali, yang akan dibahas di bawah ini. Kemungkinan terjadinya anomali tertentu sama saja mencirikan tingkat isolasi transaksi.

Anomali yang paling terkenal adalah: baca kotor, baca tidak dapat diulang, baca hantu, tetapi sebenarnya ada 5 lagi: tulis kotor, pembaruan kursor hilang, pembaruan hilang, baca miring, baca miring, tulis miring.

Menulis kotor


Inti dari anomali adalah transaksi dapat menimpa data yang tidak berkomitmen.

gambar

Anomali ini berbahaya bukan hanya karena data dapat bertentangan setelah melakukan kedua transaksi (seperti pada gambar), tetapi juga karena atomisitas dilanggar: karena kami mengizinkan menimpa data yang tidak dikunci, tidak jelas cara mengembalikan satu transaksi tanpa memukul yang lain .

Anomali diperlakukan cukup sederhana: kita menggantung kunci tulis sebelum perekaman dimulai, melarang transaksi lain untuk mengubah catatan sampai kunci dilepaskan.

Kotor baca


Membaca kotor berarti membaca data yang tidak dikomit.

gambar

Masalah muncul ketika, berdasarkan sampel, perlu untuk melakukan beberapa tindakan atau membuat keputusan.

Untuk memperbaiki anomali, Anda dapat menggantung kunci baca, tetapi itu akan memukul kinerja yang sulit. Lebih mudah untuk mengatakan bahwa untuk transaksi rollback, keadaan awal data (sebelum merekam) harus disimpan dalam sistem. Kenapa tidak baca dari sana? Ini cukup murah, sehingga sebagian besar database menghapus pembacaan kotor secara default.

Pembaruan yang hilang


Kehilangan pembaruan berarti kehilangan pembaruan, dan terjemahan secara akurat mencerminkan esensi dari masalah:

gambar

Bahkan, hasil transaksi T2 dibatalkan. Situasi ini diperbaiki oleh kunci tulis eksplisit atau implisit. Yaitu, kita cukup memperbarui catatan, dan kemudian kunci implisit terjadi, atau kita melakukan pilih untuk pembaruan , menyebabkan kunci baca dan tulis terjadi. Harap dicatat bahwa operasi semacam itu cukup berbahaya: dengan pembacaan "tidak bersalah" kami, kami memblokir bacaan lainnya. Beberapa database menawarkan pilih yang lebih aman untuk dibagikan yang memungkinkan Anda membaca data, tetapi tidak memungkinkannya untuk berubah.

Kursor kehilangan pembaruan


Untuk kontrol yang lebih halus, pangkalan dapat menawarkan alat lain, misalnya kursor. Kursor adalah struktur yang berisi sekumpulan garis dan memungkinkan Anda untuk mengulanginya. mendeklarasikan cursor_name untuk select_statement . Isi kursor dijelaskan dengan pilih.

Mengapa kita membutuhkan kursor? Faktanya adalah bahwa beberapa database menawarkan penguncian pada semua catatan yang dipilih dengan pilih (baca stabilitas), atau hanya pada catatan di mana kursor saat ini berada (stabilitas kursor). Dengan stabilitas kursor, kunci pendek diterapkan, yang memungkinkan kita untuk mengurangi jumlah kunci jika kita beralih pada sampel data yang besar. Oleh karena itu, anomali pembaruan yang hilang disorot secara terpisah untuk kursor.

Baca tidak dapat diulang


Pembacaan yang tidak dapat diulangi adalah bahwa selama pelaksanaan transaksi kami, 2 pembacaan berurutan dari catatan yang sama akan menghasilkan hasil yang berbeda, karena transaksi lain mengintervensi antara dua pembacaan ini, mengubah data kami dan berkomitmen.

gambar

Mengapa ini menjadi masalah? Bayangkan bahwa tujuan transaksi T2 dalam gambar adalah untuk memilih semua produk yang harganya kurang dari 150 cu Orang lain memperbarui harga menjadi $ 200 Dengan demikian, filter yang dipasang tidak berfungsi.

Anomali ini berhenti terjadi ketika kunci dua fase ditambahkan atau ketika menggunakan mekanisme MVCC, yang ingin saya bicarakan secara terpisah.

Phantom membaca


Phantom sedang membaca data yang telah ditambahkan oleh transaksi lain.

gambar

Sebagai contoh, Anda dapat mengamati pemilihan produk termurah yang salah ketika anomali ini terjadi.

Menyingkirkan pembacaan hantu sudah cukup sulit. Pemblokiran normal tidak cukup, karena kita tidak akan dapat memblokir apa yang belum tersedia. Sistem 2PL menggunakan penguncian prediktif, sedangkan sistem MVCC menggunakan penjadwal transaksi untuk membatalkan transaksi yang dapat dipatahkan oleh sebuah insert. Mekanisme pertama dan kedua cukup berat.

Baca miring


Kemiringan baca muncul ketika kami bekerja dengan beberapa tabel, yang isinya harus berubah secara konsisten.

Misalkan ada tabel yang mewakili posting dan meta-informasi mereka:

gambar

Satu transaksi membaca dari tabel, yang lain mengubahnya:

gambar

Sebagai hasil dari transaksi T1, pos tersebut memiliki judul = Baik dan updated_by = T2, yang merupakan beberapa inkonsistensi.

Sebenarnya, ini adalah bacaan yang tidak dapat diulang, tetapi sebagai bagian dari beberapa tabel.

Untuk koreksi, T1 dapat menggantung kunci pada semua baris yang akan dibaca, yang akan mencegah T2 dari mengubah informasi. Dalam hal MVCC, transaksi T2 akan dibatalkan. Perlindungan terhadap anomali ini bisa menjadi penting jika kita menggunakan kursor.

Tulis miring


Anomali ini juga lebih mudah dijelaskan dengan menggunakan contoh: misalkan dalam sistem kami setidaknya satu dokter harus bertugas, tetapi kedua dokter memutuskan untuk membatalkan tugas mereka:

gambar

gambar

Anomali telah mengarah pada fakta bahwa tidak ada dokter yang akan bertugas. Kenapa ini terjadi? Karena transaksi memeriksa kondisi yang mungkin dilanggar oleh transaksi lain, dan karena isolasi, kami tidak melihat perubahan ini.

Ini adalah bacaan yang tidak dapat diulang yang sama. Atau, pilih yang dapat menggantung kunci pada catatan ini.

Menulis miring dan membaca miring adalah kombinasi dari anomali sebelumnya. Anda dapat mempertimbangkan menulis miring, yang pada dasarnya adalah membaca hantu. Pertimbangkan tabel di mana terdapat nama-nama karyawan, gaji mereka dan proyek tempat mereka bekerja:

gambar

gambar

Sebagai hasilnya, kami mendapatkan gambar berikut: setiap manajer berpikir bahwa perubahannya tidak akan mengarah pada anggaran, sehingga mereka membuat perubahan personil, yang secara total menyebabkan overrun.

Penyebab masalah persis sama dengan membaca hantu.

temuan


Melemahnya tingkat isolasi transaksi dalam basis data merupakan kompromi antara keamanan dan kinerja, pilihan tingkat ini harus didekati berdasarkan risiko potensial terhadap bisnis jika terjadi anomali.



Pelajari lebih lanjut tentang kursus.



All Articles