Örnek Üzerinden RDBMS’lerde Transaction Isolation Seviyeleri
--
Son flood’da çeşitli Transaction Isolation seviyelerine değinmiştik. RDBMS’ler ilgili izolasyon seviyesinin vadettiği garantileri sağlamak için DB üzerindeki kayıt veya kayıtlarda kilitler tutar. Bu kilitlerin RDBMS’in eş zamanlı işlem yapmasını engellediği ve dolayısıyla scale etmesine engel olduğundan bahsetmiştik. Şimdi bu izolasyon seviyelerinin kullanım alanları ile ilgili aynı domain’den örnekler verelim.
- Read Uncommitted, kirli data okumanın (dirty read) problem oluşturmadığı durumlarda kullanılır. Bir oyundaki aktif kullanıcı sayısını gösterdiğimiz ekranda Read Uncommitted ile toplam oyuncu sayısını okuyabiliriz çünkü 2 eksik 1 fazla sayı vermemiz çok önemli olmayacaktır.
- Read Committed, oyuncunun oyuna aynı anda sadece bir cihazdan login olmasını istediğimiz ve login durumunda DB’deki bir kolonu işaretlediğimiz bir senaryoda kullanılamaz. Oyuncu iki farklı cihazdan eş zamanlı olarak login isteklerini gönderdiğinde bu izolasyon seviyesinde ‘Nonrepetable Read’ olabileceği için oyuncunun çift giriş yapamayacağını garanti edemeyiz.
- Repetable Read, ‘Nonrepetable Read’i engeller, önceki senaryoda oyuncunun oyuna sadece bir giriş yapabileceği senaryoda kullanılabilir.
- Serializable, puan tablosundan bir oyuncunun bütün puanlarını toplamak istediğimiz durumda kullanılabilir. Bu izolasyon seviyesinde ‘Phantom Read’, ‘Nonrepetable Read’ ve ‘Dirty Read’ engellendiği için oyuncunun puanı anlık değişimlerden etkilenmeden doğru bir şekilde hesaplanıp oyuncuya gösterilebilir. Burada RDBMS puan tablosunda ‘Range Lock’ tutarak gerekli tutarlılığı sağlar.
Görüldüğü üzere Serializable haricindeki isolasyon seviyelerinin kullanım alanı çok dardır, her transaction’da Serializable kullanmak da DB’nin eş zamanlı işlem yapma özelliğini kısıtlayıp ölçeklenirliğini azaltır. Bu noktada imdada MVCC (Multi Version Concurrency Control), SQL standardında olmayan Snapshot isolation ve Optimistic Locking yetişiyor. Bunları da bir sonraki flood’da ele alacağız.
