MVCC Nedir, Önemi ve Transaction ID Wraparound sorunu?

MVCC (Multi-Version Concurrent Control)

Aynı veriye eş zamanlı yapılan okuma/yazma işlemlerinde herhangi bir çakışma olmasını engelleyen tekniktir.

  • Eş zamanlı sorgu davranışı tahmini
  • MVCC performans etkilerinin yönetilmesi
  • Depolama alanının yeniden kullanımı anlama

Supporters of MVCC

CouchbaseVirtuosofirebird
PostgreSQLBigTableHyperGraphDB
OrientDBProject VoldemortDrizzle
CouchDBclustrixIBM DB2
MarkLogicCloudantStormDB
Percona ServerInterSystems CachéInterBase

Sorgu başlarken, PostgreSQL Current Transaction ID’yi kaydeder ve sorgudan dönen satırların versiyonlarına bakar ve eşleştirmeyi şu şekilde yapar;

Eğer Creation ID committed transaction ise ve Current Transaction ID’den daha düşükse satırları gösterir.

Creation IDExpiration ID….

Her satırda 2 ID vardır. Birincisi yarartıldığında verilen Creation ID, diğeri ise satır silindiğinde veya değişiklik olduğunda verilen Expiration ID. Expiration ID, Current Transaction ID’den küçükse satır görünürlüğünü kaybetmiş demektir. Eğer Creation ID, Current Transaction ID’den küçükse satır görünürdür. Buna Transaction Visibility denir.

 ID Wraparound Failure

Satır’ın Creation ID’si Transaction ID’den büyükse “in the future” olarak adlandırılır ve yapılan işleme görünür değildir. Transaction ID ise 32-bitlik bir sayı olup en fazla alabileceği değer 4 milyar civarıdır (2^32). Maximum sayıya ulaştıktan sonra arttırıldığında değer en başa yani sıfıra döner. Böyle olduğunda tüm satırların versiyonunun Transaction ID’den büyük olarak gözükmesi(in the future) tüm satırların görünürlülüğünü kaybettirir. Bu durum catastrophic veri kaybı olarak adlandırılır. Transaction ID maximum sayıya ulaşmadan önce VACUUM çalıştırırsak sorun ortadan kalkmış olacaktır. Çünkü Transaction ID sıfırlanmış olup satırların versiyonları buna göre düzenlenmiş olacaktır.

deadrows

Burda tüm satırlar için 2 kere update yapıldı ve her satır 2 versiyon numarası değiştirdi. VACUUM yapıldığında ise toplamda 400002 satırın expiration ID’si Transaction ID’sinden küçük kaldı böylece görünürlülüğünü yitirdi. VACUUM eski versiyonları bularak sildi ve Transaction ID Wraparound tehlikesini ortadan kaldırdı.

MVCC’ye sahip transactional veritabanları non-transactional veritabanlarından daha yavaş count(*) işlemi yaparlar. Nedeni ise non-transactional veritabanları index scan yaparak sonucu da cache de tutar. Böylelikle daha hızlıdır. Transactional veritabanları table scan yaparlar çünkü tüm satırların görünür olup olmadıklarına bakmak zorundalardır ve cache’e atmak yanlış sonuçlara neden olabilir. Bu nedenlerle daha yavaştır.

Erkin Çakar

PostgreSQL DBA & Software developer