Pembacaan Kotor, Tidak Berulang, dan Hantu

Tingkat isolasi ada untuk mencegah bug konkurensi tertentu yang disebut anomali pembacaan. Pewawancara mengharapkan Anda mendefinisikan ketiganya secara tepat dan memetakan masing-masing ke tingkat yang menghentikannya.

• Pembacaan kotor - membaca data yang belum di-COMMIT
• Pembacaan tidak berulang - sebuah baris berubah di antara dua pembacaan
• Pembacaan hantu - baris baru muncul di antara dua pembacaan

Triknya adalah membedakan pembacaan tidak berulang dari pembacaan hantu, karena keduanya melibatkan kueri ulang dan menghasilkan hasil yang berbeda.

Pembacaan kotor terjadi ketika transaksi T1 membaca sebuah baris yang telah diubah oleh transaksi T2 tetapi belum di-COMMIT. Jika T2 kemudian melakukan ROLLBACK, T1 telah bertindak berdasarkan data yang sebenarnya tidak pernah ada.

Hanya READ UNCOMMITTED yang mengizinkan pembacaan kotor. Semua tingkat yang lebih tinggi melarangnya.

Bahaya di dunia nyata: menyetujui pinjaman berdasarkan setoran yang di-ROLLBACK beberapa detik kemudian.

Bacalah kedua kolom sebagai linimasa. T1 berjalan pada READ UNCOMMITTED.

T1 melihat saldo 700, tetapi T2 tidak pernah melakukan COMMIT. Nilai 700 itu hanyalah bayangan dari pekerjaan T2 yang sedang berlangsung. Setelah T2 melakukan ROLLBACK, nilai sebenarnya masih 500. T1 mengambil keputusan berdasarkan data yang tidak valid.

Pembacaan tidak berulang terjadi ketika T1 membaca sebuah baris, T2 melakukan COMMIT atas pembaruan atau penghapusan pada baris yang sama, lalu T1 membacanya lagi dan melihat nilai yang berbeda.

Perhatikan perbedaan utama dari pembacaan kotor: di sini T2 telah melakukan COMMIT. Data tersebut nyata, tetapi berubah di bawah T1 dalam satu transaksi.

READ COMMITTED masih mengizinkan hal ini. REPEATABLE READ dan tingkat yang lebih tinggi mencegahnya dengan membaca dari cuplikan yang stabil.

T1 berjalan pada READ COMMITTED dan membaca baris yang sama dua kali. Di antara kedua pembacaan itu, T2 melakukan COMMIT atas suatu perubahan.

Kunci primer yang sama mengembalikan dua nilai berbeda dalam satu transaksi. Inkonsistensi itu dapat merusak logika bertahap yang mengasumsikan baris tersebut stabil.

Pembacaan hantu terjadi ketika T1 menjalankan kueri dengan kondisi pencarian, T2 melakukan COMMIT atas INSERT (atau DELETE) baris-baris yang cocok dengan kondisi tersebut, lalu T1 menjalankan ulang kueri dan melihat kumpulan baris yang berbeda.

Perbedaannya dari pembacaan tidak berulang: pembacaan tidak berulang berkaitan dengan nilai baris yang sudah ada yang berubah; pembacaan hantu berkaitan dengan jumlah baris yang cocok dengan predikat yang berubah.

Hanya SERIALIZABLE yang dijamin oleh standar untuk mencegah pembacaan hantu.

T1 menghitung akun bernilai tinggi dua kali. Di antara kedua penghitungan, T2 menyisipkan baris baru yang memenuhi syarat dan melakukan COMMIT.

Tidak ada baris yang sudah ada yang berubah, tetapi COUNT berbeda. Baris baru itu adalah "hantu" yang muncul dalam kumpulan hasil T1.

Pemetaan ini adalah inti topik ini. Berikut tingkat terendah yang mencegah setiap anomali:

• Pembacaan kotor dicegah mulai dari READ COMMITTED ke atas.
• Pembacaan tidak berulang dicegah mulai dari REPEATABLE READ ke atas.
• Pembacaan hantu dicegah oleh SERIALIZABLE (menurut standar).

Perhatikan bahwa namanya selaras: REPEATABLE READ membuat pembacaan dapat diulang; tingkat-tingkat tersebut dinamai berdasarkan anomali yang baru diperbaikinya.

Ini adalah kekeliruan yang paling umum dalam wawancara. Ingat satu kalimat ini:

Pembacaan tidak berulang = nilai baris yang sudah ada berubah. Pembacaan hantu = kumpulan baris yang cocok berubah (baris ditambahkan atau dihapus).

Uji diri Anda: T2 menjalankan UPDATE ... WHERE id = 5 lalu melakukan COMMIT, dan T1 membaca ulang baris 5. Itu adalah pembacaan tidak berulang. T2 menjalankan INSERT untuk baris baru yang cocok dengan WHERE milik T1, lalu T1 menjalankan ulang kueri. Itu adalah pembacaan hantu.

Wawancara tingkat senior mungkin melampaui tiga anomali standar dan membahas kemiringan penulisan: dua transaksi masing-masing membaca kumpulan yang saling tumpang tindih, melakukan penulisan yang tidak saling tumpang tindih berdasarkan hasil bacaan mereka, lalu keduanya melakukan COMMIT sehingga menyisakan keadaan yang tidak akan diizinkan oleh salah satu pun jika berjalan sendiri.

Contoh klasik: dua dokter sedang piket; masing-masing memeriksa bahwa dokter lain sedang piket lalu mengeluarkan diri dari jadwal. Keduanya berhasil, sehingga tidak ada cakupan layanan.

Isolasi cuplikan (Postgres REPEATABLE READ) mengizinkan kemiringan penulisan; hanya SERIALIZABLE yang menghentikannya. Menyebutkan hal ini menunjukkan kedalaman pemahaman.

Pewawancara terkadang menyelipkan pembaruan yang hilang, yang tidak termasuk dalam daftar anomali standar tetapi sangat sering muncul dalam praktik. Dua transaksi membaca nilai yang sama, keduanya menghitung nilai baru dari nilai tersebut, lalu keduanya menulis kembali. Penulisan kedua diam-diam menimpa penulisan pertama.

Contoh: dua transfer masing-masing membaca saldo 500, masing-masing mengurangkan sejumlah dana, lalu masing-masing menulis hasilnya. Salah satu pengurangan hilang.

Perbaikannya bukan hanya tingkat isolasi yang lebih tinggi, melainkan juga penguncian eksplisit dengan SELECT ... FOR UPDATE, atau pembaruan atomik yang menghitung di basis data, bukan di aplikasi.

Identifikasi anomali dari perilakunya.

Tiga anomali pembacaan, masing-masing diatasi oleh tingkat isolasi yang lebih tinggi:

• Pembacaan kotor (data yang belum di-COMMIT) - diatasi pada READ COMMITTED.
• Pembacaan tidak berulang (nilai baris yang sudah ada berubah) - diatasi pada REPEATABLE READ.
• Pembacaan hantu (kumpulan baris yang cocok berubah) - diatasi pada SERIALIZABLE.

Pertahankan perbedaan tegas antara pembacaan tidak berulang dan pembacaan hantu, lalu sebutkan kemiringan penulisan jika pewawancara menginginkan lebih banyak. Berikutnya kita melihat bagaimana mesin basis data benar-benar menerapkan isolasi: penguncian, kebuntuan, dan MVCC.