Apa akibat melemahnya tingkat isolasi transaksi dalam database?

Halo semua. Vladislav Rodin menghubungi kami. Saat ini saya adalah Pemimpin Kursus untuk kursus Arsitek Beban Kerja Tinggi di OTUS dan juga mengajar kursus arsitektur perangkat lunak.

Selain mengajar, seperti yang mungkin Anda ketahui, saya menulis materi asli untuk blog OTUS di Habré dan saya ingin artikel hari ini bertepatan dengan peluncuran kursus. "PostgreSQL", yang terbuka untuk pendaftaran sekarang.

Apa akibat melemahnya tingkat isolasi transaksi dalam database?

pengenalan

В terakhir kali kami berbicara tentang fakta bahwa transaksi dalam database berfungsi untuk memecahkan dua masalah: memastikan toleransi kesalahan dan akses ke data dalam lingkungan yang kompetitif. Untuk sepenuhnya melakukan tugas ini, transaksi harus memiliki properti ACID. Hari ini kita akan berbicara secara detail tentang surat itu saya (isolasi) dalam singkatan ini.

Isolasi

Isolasi memecahkan masalah akses data dalam lingkungan yang kompetitif, dan pada dasarnya memberikan perlindungan dari kondisi balapan. Idealnya, isolasi berarti serialisasi, yaitu properti yang memastikan bahwa hasil eksekusi transaksi secara paralel sama seperti jika dieksekusi secara berurutan. Masalah utama dengan properti ini adalah sangat sulit untuk disediakan secara teknis dan akibatnya memiliki dampak yang signifikan terhadap kinerja sistem. Itulah sebabnya isolasi sering kali melemah, menerima risiko anomali tertentu, yang akan dibahas di bawah. Kemungkinan terjadinya anomali tertentu justru mencirikan tingkat isolasi transaksi.

Anomali yang paling terkenal adalah: dirty read, non-repeatable read, phantom read, namun sebenarnya masih ada 5 lagi: dirty write, kursor hilang update, lost update, read skew, write skew.

Tulisan kotor

Inti dari anomali ini adalah bahwa transaksi dapat menimpa data yang tidak terikat.

Apa akibat melemahnya tingkat isolasi transaksi dalam database?

Anomali ini berbahaya bukan hanya karena data dapat konflik setelah melakukan kedua transaksi (seperti pada gambar), tetapi juga karena atomisitas dilanggar: karena kami mengizinkan data yang tidak dikomit untuk ditimpa, tidak jelas bagaimana cara mengembalikan satu transaksi tanpa mempengaruhi yang lain. .

Anomali ini dapat diatasi dengan cukup sederhana: kami memasang kunci pada catatan sebelum memulai pencatatan, melarang transaksi lain mengubah catatan hingga kunci tersebut dilepas.

Bacaan kotor

Bacaan kotor berarti membaca data yang belum dikomit.

Apa akibat melemahnya tingkat isolasi transaksi dalam database?

Masalah muncul ketika tindakan atau keputusan perlu diambil berdasarkan sampel.

Untuk memperbaiki anomali tersebut, Anda dapat memasang kunci baca, namun hal ini akan sangat memengaruhi kinerja. Jauh lebih sederhana untuk mengatakan bahwa untuk transaksi rollback, keadaan awal data (sebelum dimulainya perekaman) harus disimpan dalam sistem. Mengapa tidak membaca dari sana? Cukup murah sehingga sebagian besar database menghapus pembacaan kotor secara default.

Pembaruan hilang

Pembaruan yang hilang berarti pembaruan yang hilang, dan terjemahannya secara akurat mencerminkan inti masalahnya:

Apa akibat melemahnya tingkat isolasi transaksi dalam database?

Faktanya, hasil transaksi T2 terbalik. Situasi ini dapat diperbaiki dengan kunci tulis eksplisit atau implisit. Artinya, kita cukup memperbarui catatan, dan kemudian terjadi pemblokiran implisit, atau kita menjalankannya pilih untuk pembaruan, menyebabkan terjadinya kunci baca dan tulis. Harap dicatat bahwa operasi semacam itu cukup berbahaya: dengan pembacaan “tidak bersalah”, kami memblokir pembacaan lainnya. Beberapa database menawarkan lebih aman pilih untuk dibagikan, memungkinkan data untuk dibaca tetapi tidak diubah.

Kursor kehilangan pembaruan

Untuk kontrol yang lebih baik, pangkalan mungkin menawarkan alat lain, seperti kursor. Kursor adalah struktur yang berisi sekumpulan baris dan memungkinkan Anda mengulanginya. mendeklarasikan nama_kursor untuk pernyataan_pilih. Isi kursor dijelaskan dengan memilih.

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

Bacaan yang tidak dapat diulang

Pembacaan yang tidak dapat diulang adalah bahwa selama eksekusi transaksi kami, 2 pembacaan berturut-turut dari catatan yang sama akan menghasilkan hasil yang berbeda, karena transaksi lain mengintervensi antara dua pembacaan ini, mengubah data kami dan dilakukan.

Apa akibat melemahnya tingkat isolasi transaksi dalam database?

Mengapa ini menjadi masalah? Bayangkan tujuan transaksi T2 pada gambar adalah memilih semua barang yang harganya kurang dari 150 USD. Orang lain memperbarui harga menjadi $200. Jadi, filter yang dipasang tidak berfungsi.

Anomali ini tidak lagi terjadi ketika interlock dua fase ditambahkan atau ketika mekanisme MVCC digunakan, yang ingin saya bahas secara terpisah.

Hantu membaca

Phantom adalah pembacaan data yang ditambahkan oleh transaksi lain.

Apa akibat melemahnya tingkat isolasi transaksi dalam database?

Sebagai contoh, kita dapat mengamati kesalahan pemilihan produk termurah ketika anomali ini terjadi.

Menghilangkan phantom reads sudah cukup sulit. Pemblokiran biasa saja tidak cukup, karena kita tidak bisa memblokir sesuatu yang belum ada. Sistem 2PL menggunakan penguncian prediktif, sedangkan sistem MVCC memiliki penjadwal transaksi yang mengembalikan transaksi yang mungkin terganggu oleh penyisipan. Mekanisme pertama dan kedua keduanya cukup berat.

Baca miring

Read skew terjadi ketika kita bekerja dengan beberapa tabel yang isinya harus berubah secara konsisten.

Katakanlah kita memiliki tabel yang mewakili postingan dan informasi metanya:

Apa akibat melemahnya tingkat isolasi transaksi dalam database?

Satu transaksi membaca dari tabel, transaksi lainnya memodifikasinya:

Apa akibat melemahnya tingkat isolasi transaksi dalam database?

Akibat transaksi T1, postingan memiliki judul = Baik, dan diperbarui_oleh = T2, yang merupakan semacam inkonsistensi.

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

Untuk mengatasinya, T1 dapat mengunci semua baris yang akan dibacanya, yang akan mencegah transaksi T2 mengubah informasi. Dalam kasus MVCC, transaksi T2 akan dibatalkan. Perlindungan terhadap anomali ini menjadi penting jika kita menggunakan kursor.

Tulis miring

Anomali ini juga lebih mudah dijelaskan dengan sebuah contoh: misalkan dalam sistem kita setidaknya ada satu dokter yang harus bertugas, namun kedua dokter tersebut memutuskan untuk membatalkan tugasnya:

Apa akibat melemahnya tingkat isolasi transaksi dalam database?

Apa akibat melemahnya tingkat isolasi transaksi dalam database?

Anomali ini menyebabkan tidak ada satu pun dokter yang bertugas. Kenapa ini terjadi? Karena transaksi tersebut sedang memeriksa suatu kondisi yang dapat dilanggar oleh transaksi lain, dan karena isolasi kami tidak melihat perubahan tersebut.

Ini adalah bacaan yang sama dan tidak dapat diulang. Alternatifnya, orang yang dipilih dapat mengunci catatan ini.

Write skew dan read skew merupakan kombinasi dari anomali sebelumnya. Anda dapat mempertimbangkan penulisan miring, yang pada dasarnya adalah pembacaan bayangan. Perhatikan tabel yang berisi nama-nama karyawan, gajinya, dan proyek yang mereka kerjakan:

Apa akibat melemahnya tingkat isolasi transaksi dalam database?

Apa akibat melemahnya tingkat isolasi transaksi dalam database?

Hasilnya, kita mendapatkan gambaran berikut: setiap manajer berpikir bahwa perubahan yang mereka lakukan tidak akan menyebabkan kelebihan anggaran, sehingga mereka melakukan pergantian personel yang bersama-sama menyebabkan pembengkakan biaya.

Penyebab masalahnya sama persis dengan phantom reading.

Temuan

Melonggarkan tingkat isolasi transaksi dalam database merupakan trade-off antara keamanan dan kinerja; pilihan tingkat ini harus didekati berdasarkan potensi risiko terhadap bisnis jika terjadi anomali tertentu.

Pelajari lebih lanjut tentang kursus ini.

Sumber: www.habr.com

Tambah komentar