Bugün Isolation Levels ve Read Anomalies konularını ele alacağız.
Önce temel bir soruyla başlayalım:
Concurrency Problemi Nedir?
Concurrency problemi, birden fazla işlemin eş zamanlı olarak çalışması sırasında oluşan veri çakışmalarıdır. Bu durum genellikle race condition olarak adlandırılır.
Eğer veritabanı veya uygulama bu çakışmayı doğru şekilde yönetemezse:
- Veri tutarsızlığı oluşur
- Güncellemeler kaybolur
- Sistem yanlış sonuç üretir
Node.js tek thread çalışıyor gibi görünse de, veritabanı işlemleri asenkron olduğu için concurrency problemleri veritabanı seviyesinde devam eder.
Isolation Nedir?
Isolation, bir transaction çalışırken diğer transaction’ların bu veriyi ne kadar görebileceğini belirleyen mekanizmadır.
Yani:
Bir transaction devam ederken diğer işlemler bu değişiklikleri görebilecek mi?
Isolation, ACID prensibinin “I” harfidir ve işlem bütünlüğünü korur.
Read Anomalies Türleri
Isolation seviyesi düşük olduğunda aşağıdaki anomaliler oluşabilir:
1) Dirty Read
Bir transaction, henüz commit edilmemiş başka bir transaction’ın yazdığı veriyi okursa dirty read oluşur.
Örnek (Banka Senaryosu)
- Admin, Ali’nin hesabına 1000 TL bonus ekliyor (henüz commit yok)
- Ali bakiyesine bakıyor → 1000 TL fazla görüyor
- Admin işlemi rollback ediyor
Ali aslında olmayan bir parayı görmüş oldu.
2) Non-Repeatable Read
Aynı transaction içinde aynı veri iki kez okunduğunda farklı sonuç alınmasıdır.
Örnek (Stok Raporu)
- Rapor sistemi stoğu okur → 50
- Başka bir kullanıcı ürün satın alır ve commit eder
- Rapor sistemi tekrar okur → 49
Aynı transaction içinde veri değişti.
3) Phantom Read
Bir sorgu belirli bir koşula göre veri getirirken, başka bir transaction bu koşula uyan yeni bir satır eklerse phantom read oluşur.
Örnek (Maaş Listesi)
- “Maaşı 20.000 olan çalışanları getir” → 3 kişi
- Yeni bir çalışan eklenir ve commit edilir
- Aynı sorgu tekrar çalıştırılır → 4 kişi
Yeni kayıt “hayalet” gibi araya girmiştir.
Isolation Levels
Isolation seviyesi arttıkça veri güvenliği artar, ancak performans düşer.
| Seviye | Dirty Read | Non-Repeatable | Phantom |
|---|---|---|---|
| Read Uncommitted | Var | Var | Var |
| Read Committed | Yok | Var | Var |
| Repeatable Read | Yok | Yok | Var |
| Serializable | Yok | Yok | Yok |
Isolation Level Açıklamaları
1) Read Uncommitted
En düşük seviyedir. Dirty read mümkündür.
2) Read Committed
Sadece commit edilmiş veriler okunabilir. Dirty read engellenir.
(PostgreSQL default: Read Committed)
3) Repeatable Read
Aynı transaction süresince okunan satır değişmez. Non-repeatable read engellenir.
(MySQL default: Repeatable Read)
4) Serializable
Transaction’lar sırayla çalışıyormuş gibi davranır. En güvenli ama en yavaş seviyedir. Deadlock riski yüksektir.
Isolation Yetmezse?
Örnek:
- Sen bakiyeyi 100 okudun
- Başkası 50 ekledi ve commit etti
- Sen 20 ekleyip 120 olarak kaydettin
Burada 50 TL kayboldu.
Bu durumda sadece isolation level yeterli değildir; row-level locking (SELECT ... FOR UPDATE) gibi mekanizmalar gerekir.
Transaction Boundary ile İlişkisi
Transaction boundary, isolation ve lock’ların geçerli olduğu sınırı belirler.
- Commit veya rollback yapıldığında
- Kilitler açılır
- Isolation etkisi biter
Isolation Seviyesini Nerede Belirlemeliyiz?
Isolation seviyesini tüm sistem için kalıcı olarak yükseltmek genellikle doğru değildir.
Neden?
- Performans: Serializable tüm sistemi yavaşlatır.
- Esneklik: Çoğu işlem için Read Committed yeterlidir.
- Profesyonel yaklaşım: Sadece kritik işlemlerde (stok, bakiye gibi) izolasyonu yükseltmek gerekir.
Yani:
%95 işlem → Default isolation %5 kritik işlem → Daha yüksek isolation
Bu yaklaşım hem performansı hem veri tutarlılığını dengeler.
Isolation levels, eş zamanlı çalışan transaction’ların birbirini nasıl göreceğini belirler. Seviye yükseldikçe veri tutarlılığı artar ancak performans düşer. Gerçek dünyada en doğru yaklaşım, tüm sistemi ağırlaştırmak yerine yalnızca kritik iş akışlarında izolasyon seviyesini artırmaktır.