PostgreSQL | Setiap row di PostgreSQL memiliki dua ID transaksi: creation transaction ID yang menunjukkan ID transaksi yang membuat row tersebut, serta expiration transaction ID yang menunjukkan transaksi yang membuat row tersebut kedaluwarsa. Ketika UPDATE dilakukan, PostgreSQL menciptakan row baru dan meng-expire row lama. Ini row yang sama — hanya saja berbeda versi. PostgreSQL menciptakan row versi baru hasil perubahannya tapi juga mempertahankan row versi lama yang sudah kedaluwarsa.
Jelas kan sekarang….. kenapa namanya Multi-Versioning…. Pada sistem database yang menggunakan row-level locking tidak mempertahankan versi lama dari data yang diubah, sehingga kebutuhan untuk mengkunci data muncul untuk menjaga konsistensi data. Setelah sekarang Anda tahu bagaimana PostgreSQL menciptakan versi data, Anda mungkin bertanya-tanya bagaimana PostgreSQL bisa tahu versi yang mana untuk ditampilkan….
PostgreSQL | Pada artikel sebelumnya, kita sudah membahas tentang definisi MVCC. Sekarang mari kita lihat lebih dalam bagaimana MVCC bekerja di PostgreSQL sehingga memungkinkan terjadinya "no-locking."
Setiap row di PostgreSQL memiliki dua ID transaksi: createtion transaction ID yang menunjukkan ID transaksi yang membuat row tersebut, serta expiration transaction ID yang menunjukkan transaksi yang membuat row tersebut kedaluwarsa. Ketika UPDATE dilakukan, PostgreSQL menciptakan row baru dan meng-expire row lama. Ini row yang sama — hanya saja berbeda versi. PostgreSQL menciptakan row versi baru hasil perubahan, tapi juga mempertahankan row versi lama yang sudah kedaluwarsa.
Jelas kan sekarang….. kenapa namanya Multi-Versioning…. Pada sistem database yang menggunakan row-level locking tidak mempertahankan versi lama dari data yang diubah, sehingga kebutuhan untuk mengkunci data muncul untuk menjaga konsistensi data. Setelah sekarang Anda tahu bagaimana PostgreSQL menciptakan versi data, Anda mungkin bertanya-tanya bagaimana PostgreSQL bisa tahu versi yang mana untuk ditampilkan….
Sebenarnya cukup sederhana. Pada awal query, PostgreSQL mencatat dua hal: 1) ID transaksi saat ini berjalan, dan 2) semua ID transaksi yang belum di-commit. Jika ada permintaan query, PostgreSQL menampilkan semua versi row yang cocok dengan kriteria berikut:
- row tersebut memiliki creation transaction ID yang sudah di-commit namun kurang dari counter transaksi saat ini berjalan.
- row tersebut tidak memiliki expiration transaction ID atau expiration transaction ID-nya masih termasuk dalam proses yang belum di-commit.
Kekuatan MVCC adalah dalam tracking ID transaksi untuk menentukan versi dari data yang harus ditampilkan, sehingga locking tidak lagi diperlukan. Cara ini sangat logis dan efisien. Pengguna baru untuk PostgreSQL pasti akan senang dengan perbaikan kinerja saat memanfaat database yang punya MVCC dibanding sistem database yang menggunakan row-level locking, terlebih lagi jika aplikasi berjalan di lingkungan multi-user dengan user yang banyak.
Selain itu, MVCC menawarkan keuntungan lain: hot backup. MVCC memungkinkan PostgreSQL untuk membuat backup database penuh sementara database hidup. Untuk sistem database lain yang mengharuskan semua user menghentikan aktifitas kemudian shutdown database sebelum proses backup dilakukan. Tidak demikian halnya dengan PostgreSQL karena hanya perlu mengambil snapshot dari seluruh database pada titik waktu tertentu dan melakukan backup, bahkan ketika data sedang dimasukkan, diperbarui atau dihapus.
Kesimpulannya, MVCC memastikan bahwa pembaca (SELECT) tidak pernah menunggu untuk penulis (UPDATE) dan penulis tidak pernah menunggu pembaca. Jika Anda tidak percaya bahwa MVCC di PostgreSQL lebih baik dari row-level-locking, saya tantang Anda untuk mencoba sendiri menggunakan PostgreSQL.
