Sementara sebagian besar sistem database menggunakan kunci untuk kontrol konkurensi, PostgreSQL melakukan hal-hal yang sedikit berbeda: ia mempertahankan konsistensi data dengan menggunakan model multi-versi, atau dikenal sebagai Kontrol Konkurensi Multi-Versi, atau MVCC untuk jangka pendek. Akibatnya, ketika query database, setiap transaksi melihat snapshot data seperti beberapa waktu sebelumnya, terlepas dari keadaan saat ini dari data yang mendasarinya. Ini mencegah transaksi melihat data yang tidak konsisten yang dapat disebabkan oleh pembaruan transaksi bersamaan lainnya pada data yang sama, dan menyediakan isolasi transaksi untuk setiap sesi database. Artikel blog ini akan memberikan gambaran singkat tentang cara kerja protokol MVCC serta mencakup beberapa pro dan kontra dari pendekatan MVCC.

Protokol MVCC Dijelaskan

Perbedaan utama antara model kunci dan MVCC adalah bahwa yang terakhir memastikan bahwa membaca tidak pernah memblokir menulis dan menulis tidak pernah memblokir membaca.

Di MVCC, setiap transaksi memiliki timestamp transaksi yang menunjukkan (a) kapan dimulai dan (b) ketika transaksi memperbarui item data tertentu, seperti field, atau catatan, atau tabel. Versi baru item data ini dibuat sementara juga mempertahankan versi yang lebih lama. Setiap versi dilengkapi dengan:

• penulisan timestamp untuk menunjukkan timestamp transaksi (yaitu waktu transaksi dimulai) yang membuatnya, dan
• pembacaan timestamp untuk menunjukkan timestamp terbaru dari semua transaksi yang telah membacanya.

Ide dasar dari protokol MVCC adalah bahwa manajer transaksi hanya mengizinkan operasi jika mereka dapat diizinkan dengan cara yang konsisten dengan semua transaksi yang dijalankan secara keseluruhan pada saat timestamp mereka. Ini disebut sebagai perintah eksekusi yang diduga. Peneliti database Jan Hidders menjelaskan bagaimana manajer transaksi menyelesaikan ini sebagai berikut:

Jika transaksi ingin membaca item, itu diberikan akses ke versi yang akan dibaca dalam urutan eksekusi yang diduga. Ini akan menjadi salah satu dengan timestamp penulisan terbaru tepat sebelum timestampnya sendiri. Misalnya, jika ada versi dengan penulisan timestamp 5, 12 dan 20, dan timestamp transaksi adalah 14, maka versi dengan penulisan timestamp 12 adalah yang dibaca oleh transaksi ini dalam urutan eksekusi yang diduga.

Jika transaksi ingin menulis item, diperiksa apakah tidak ada operasi baca yang diizinkan sebelumnya dan bahwa dalam perintah eksekusi yang diduga akan membaca versi baru yang disebabkan oleh operasi tulis yang diminta, tetapi ketika diizinkan membaca versi lain. Sebagai contoh, asumsikan lagi kita memiliki versi dengan penulisan timestamp 5, 10 dan 16. Selain itu asumsikan pembacaan timestamp dari versi ini masing-masing adalah 8, 12 dan 20. Jika transaksi dengan timestamp 11 ingin memperbarui item, ada masalah, karena versi dengan write-timestamp 10 dibaca oleh transaksi dengan timestamp 12. Jadi, jika versi dengan timestamp 11 dibuat, transaksi dengan timestamp 12 dalam urutan eksekusi yang diduga tidak akan melihat versi yang dibuat oleh transaksi dengan timestamp 10, tetapi yang sekarang akan dibuat dengan timestamp 11. Jika, di sisi lain, transaksi dengan timestamp 14 ingin menulis item, ini baik-baik saja, karena sejauh yang kami tahu setelah t = 12 dalam perintah eksekusi yang diduga, item tersebut tidak dibaca oleh transaksi apa pun sampai saat diperbarui pada t = 16.

Pro dan Kontra MVCC

Pro:

• Seperti yang Anda tahu dari uraian di atas, semua operasi baca akan selalu diizinkan segera. Ini biasanya tidak terjadi dalam pendekatan berbasis kunci, di mana kunci baca mungkin ditolak karena kunci tulis yang ada.
• Ini cenderung memungkinkan juga lebih banyak operasi tulis untuk segera dilalui daripada pendekatan berbasis kunci biasanya.

Cons

• Jika operasi tulis ditolak, tidak ada alternatif selain memutar kembali atau memulai ulang transaksi: setelah pembaruan ditolak, itu juga akan ditolak jika kita mencobanya lagi nanti. Ini berbeda dari pendekatan berbasis kunci, di mana kita biasanya bisa menunggu sampai kunci tersedia. Karena alasan inilah MVCC dikategorikan sebagai protokol optimis: sangat efisien jika tidak ada konflik, tetapi begitu ada, Anda mungkin harus membatalkan banyak pekerjaan.
• Banyak versi item mungkin memerlukan ruang penyimpanan yang jauh lebih besar. Dalam pendekatan berbasis kunci, hanya satu versi yang perlu disimpan.
• Penghapusan versi yang tidak lagi diperlukan dapat menyebabkan beberapa overhead.

Pikiran Akhir tentang Kontrol Konkurensi Multi-Versi di PostgreSQL

Artikel blog ini memberikan gambaran umum tentang cara kerja protokol MVCC dan menyajikan beberapa pro dan kontra.

Tertarik untuk bekerja dengan PostgreSQL? Anda dapat mencoba Navicat 16 for PostgreSQL GRATIS selama 14 hari!