Cevap.

Konunun Tarihçesi

Çoklu versiyon erişim kontrolü (MVCC, Multi-Version Concurrency Control) konsepti, büyük sayıda işlemin paralel çalışabilmesini sağlamak için katı kilitlere alternatif olarak ortaya çıktı. Bu, veriler üzerinde eş zamanlı erişimde çatışmaların ve kilitlenmelerin azaltılması açısından özellikle OLTP sistemlerinde önemli olmuştur.

Problem

Geleneksel kilitleme yaklaşımları (örneğin, satır düzeyinde kilitleme), yüksek rekabet durumunda uygulama yavaşlamalarına neden olabilir. MVCC'nin amacı, işlemlerin yazma işlemleri eş zamanlı olarak gerçekleştirilse bile tutarlı veri anlık görüntülerini okumasına izin vermek, böylece izolasyon ve eş zamanlı erişim sağlamaktır.

Çözüm

MVCC, popüler veritabanı sistemlerinde (PostgreSQL, Oracle, MySQL/InnoDB) satırların sürüm tarihlerini saklayarak uygulanmaktadır. Okuma işlemi sırasında, her işlem sadece başlangıcından önce onaylanmış satırları görür ve eklemeler/güncellemeler satırların yeni sürümlerini oluşturur, bu da onları hemen silmez.

Sorgu örneği (PostgreSQL):

BEGIN TRANSACTION;
SELECT * FROM orders WHERE status = 'processing';
UPDATE orders SET status = 'completed' WHERE id = 42;
COMMIT;

İşlem tamamlanana kadar, diğer kullanıcılar satırın önceki sürümünü görecek ve yalnızca onaylıklı işlemden sonra değişiklikler yeni işlemlere sunulacaktır.

Anahtar Özellikler:

MVCC, okuma sırasında kilitlenmeyi engeller (okuyucular yazarları engellemez, yazarlar okuyucuları engellemez).
Analiz için verilerin "anlık görüntüleri" (snapshots) kolayca uygulanabilir.
Eski satır sürümleri düzenli olarak çöp toplama (VACUUM/garbage collection) gerektirir.

Kandırıcı Sorular.

MVCC tüm kilit türlerinden ve çatışmalardan tamamen kurtulabilir mi?

Hayır, MVCC'de, aynı satırların eş zamanlı güncellenmesi durumunda — örneğin, eş zamanlı UPDATE'ler sırasında, bir yazma-yazma çatışması olabilir ve veritabanı bu durumda hata fırlatır veya işlemlerden birini geri alır.

MVCC'de eski satır sürümleri ne zaman silinir ve bu bellek sızıntısına neden olabilir mi?

Çoğu veritabanında, eski satır sürümleri özel süreçler (PostgreSQL'de VACUUM) tarafından silinir. Bu süreçler çalıştırılmazsa, veritabanı "şişer" ve performans düşer.

"Select for update" MVCC koşullarında doğru çalışır mı ve neden kilitleme gereklidir?

Evet, SELECT FOR UPDATE sorguları, eş zamanlı değişiklikler sırasında çatışmaları önlemek için satırları kilitler, aksi takdirde "kaybolan güncellemeler" ortaya çıkabilir.

Örnek:

BEGIN;
SELECT * FROM products WHERE id = 123 FOR UPDATE;
UPDATE products SET quantity = quantity - 1 WHERE id = 123;
COMMIT;

Yaygın Hatalar ve Anti-Desenler

"Ölü" satırların temizlenmesi gereğini hesaba katmamak, bu da büyüyen bir veritabanına ve düşen performansa neden olur.
Yazma/yazma çatışmalarını göz ardı etmek — yalnızca MVCC'ye güvenmek ve işlem hatalarını kontrol etmemek.
İlkelerinin tutarlılık üzerindeki etkisini anlamadan farklı işlem izolasyon seviyelerini karıştırmak.

Gerçek Hayat Örneği

Olumsuz Durum

Büyük bir çevrimiçi mağazada, VACUUM ayarı yapılmadan sık sık güncellemeler içeren bir sipariş şeması uygulandı. Bir ay sonunda veritabanı 10 kat büyüdü, sorgular yavaşladı.

Artılar:

Başlangıçta yüksek paralellik, hızlı uygulama.

Eksiler:

Disk alanı kullanımı, büyük hacim nedeniyle sistemin çökmesi.

Olumlu Durum

Düzenli bir autovacuum uygulanmıştır; yazma çatışması kontrolü yapılmış ve yalnızca kritik sorgular için TEKRARLANABİLİR OKUMA düzeyinde izolasyon kullanılmıştır.