Veritabanı Yalıtım Seviyeleri: Hangi Tutarlılık, Hangi Maliyet?
Aynı raporu iki kez çalıştırdınız ve farklı sonuç aldınız. Ya da bir işlem sırasında okuduğunuz stok değeri, birkaç satır sonra başka bir değere dönüştü. Bunlar hata değil — veritabanının hangi yalıtım seviyesinde çalıştığının doğal sonuçlarıdır.
Bu yazı, işlem yalıtımını ve seçim ölçütlerini ele alıyor.
Yalıtım Neyi Çözer
Aynı anda çalışan işlemler birbirinin verisini görebilir:
- Bir işlem veriyi değiştirir.
- Diğeri aynı veriyi okur.
- Ne göreceği seviyeye bağlıdır.
Üçüncü adım tüm konunun özüdür: yalıtım seviyesi, henüz tamamlanmamış veya tamamlanmış ama sonradan değişmiş verinin size görünüp görünmeyeceğini belirler — aynı sorgu, farklı seviyelerde farklı cevap verir.
Bu, veritabanının hatası değil tasarım tercihidir.
Daha yüksek yalıtım daha çok tutarlılık, daha çok kilit demektir.
Daha düşük yalıtım daha çok hız, daha çok belirsizlik demektir.
Üç Klasik Anomali
| Anomali | Ne olur |
|---|---|
| Kirli okuma | Tamamlanmamış değişiklik görülür |
| Tekrarlanamayan okuma | Aynı satır iki kez farklı okunur |
| Hayalet okuma | Yeni satırlar ortaya çıkar |
Birinci satır en tehlikelisidir ve neyse ki en kolay engellenenidir: kirli okumada, geri alınacak bir değişikliği okuyup ona göre karar verirsiniz — var olmayan bir stoktan satış yapmak bu şekilde mümkün hâle gelir.
Çoğu veritabanı varsayılan olarak bunu zaten engeller.
İkinci ve üçüncü satırlar ise raporlarda tutarsızlık üretir.
Uzun süren toplama sorgularında belirgindir.
Seviyeler ve Karşılıkları
- En düşük seviye hiçbirini engellemez.
- Orta seviyeler bir kısmını engeller.
- En yüksek seviye hepsini engeller.
Üçüncü madde bedelsiz değildir: en yüksek yalıtım seviyesi tam tutarlılık sağlar ama işlemleri sıraya sokar — eşzamanlılık düşer ve yoğun sistemlerde işlemler birbirini beklemeye başlar.
Bu nedenle her yerde en yükseği kullanmak doğru değildir.
Seçim, işin tutarlılık ihtiyacına göre yapılmalıdır.
Çoğu web uygulaması orta seviyelerle çalışır.
Varsayılanı Bilmek
- Her veritabanının varsayılanı farklıdır.
- Kod bunu varsaymamalıdır.
- Taşımada davranış değişir.
Üçüncü madde beklenmedik hatalar üretir: bir veritabanından diğerine geçerken varsayılan yalıtım seviyesi değişebilir ve aynı kod farklı davranmaya başlar — testlerde görünmeyen bu fark, üretimde tutarsızlık olarak ortaya çıkar.
Bu tür hatalar yalnızca yük altında görülür.
Kritik işlemlerde seviye açıkça belirtilmelidir.
Varsayıma dayalı davranış, taşınabilirliği bozar.
Anlık Görüntü Yaklaşımı
- Okuma, işlem başındaki hâli görür.
- Okumalar yazmaları engellemez.
- Tutarlı bir görüntü sunar.
İkinci madde modern veritabanlarının en önemli özelliğidir: anlık görüntü yönteminde okuyan işlemler yazan işlemleri beklemez ve yazanlar da okuyanları engellemez — bu, eşzamanlılığı yüksek tutarken tutarlı okuma sağlar.
Uzun raporlar bu sayede sistemi kilitlemez.
Bedeli, eski sürümlerin bir süre saklanmasıdır.
Çok uzun süren işlemler bu birikimi büyütür.
Uzun İşlemlerin Bedeli
| Etki | Sonuç |
|---|---|
| Eski sürümler temizlenemez | Disk büyür |
| Kilitler uzun tutulur | Diğerleri bekler |
| Geri alma maliyeti artar | Hata pahalı olur |
Birinci satır sinsi bir disk sorunu üretir: açık kalmış tek bir uzun işlem, veritabanının eski satır sürümlerini temizlemesini engeller ve disk sessizce şişer — sorun işlem kapanana kadar çözülmez.
Unutulmuş bir yönetim oturumu bile bunu yapabilir.
İşlemler mümkün olduğunca kısa tutulmalıdır.
Kullanıcı girdisi beklerken işlem açık bırakılmamalıdır.
Açık Kilit Almak
- Satır okuma sırasında kilitlenebilir.
- Diğer işlemler bekler.
- Yarış koşulu engellenir.
Üçüncü madde belirli senaryolarda zorunludur: stok düşme veya bakiye güncelleme gibi işlemlerde okunan satırı kilitlemek, iki işlemin aynı değeri okuyup ikisinin de düşmesini engeller — yalıtım seviyesi tek başına bunu her zaman garanti etmez.
Kilit yalnızca gereken satırlarda alınmalıdır.
Geniş kilitler eşzamanlılığı düşürür.
Kilit sırası tüm kodda aynı olmalıdır.
Karşılıklı Kilitlenme
- İki işlem birbirini bekler.
- Veritabanı birini iptal eder.
- Uygulama tekrar denemelidir.
Üçüncü madde çoğu uygulamada eksiktir: karşılıklı kilitlenme normal bir durumdur ve veritabanı işlemlerden birini iptal ederek çözer — uygulamanın bu hatayı yakalayıp işlemi yeniden denemesi beklenir.
Yakalanmayan bu hata kullanıcıya hata sayfası olarak yansır.
Yeniden deneme genellikle başarılı olur.
Kilitlerin hep aynı sırada alınması sıklığı azaltır.
Yalıtım davranışını gözlemleyebilmek ve ayarları değiştirebilmek tam veritabanı erişimi gerektirir; VDS sunucu kiralama çözümleri ile veritabanı yapılandırmanızı doğrudan yönetebilirsiniz.
Sonuç
Aynı sorgunun farklı cevap vermesi hata değil, yalıtım seviyesinin sonucudur: seviye, tamamlanmamış veya sonradan değişmiş verinin size görünüp görünmeyeceğini belirler. En yüksek seviyeyi her yerde kullanmayın — tam tutarlılık sağlar ama işlemleri sıraya sokar. İşlemleri kısa tutun, kritik güncellemelerde satırı açıkça kilitleyin ve karşılıklı kilitlenme hatasını yakalayıp yeniden deneyin.
Sıkça Sorulan Sorular (SSS)
Aynı sorgu neden farklı sonuç veriyor?
Yalıtım seviyeniz eşzamanlı değişikliklerin görünmesine izin veriyor olabilir. Seviye, tamamlanmamış veya sonradan değişmiş verinin size görünüp görünmeyeceğini belirler; aynı sorgu farklı seviyelerde farklı cevap verir. Bu bir hata değil, tasarım tercihidir.
En yüksek seviyeyi kullansam olmaz mı?
Olur ama pahalıdır. Tam tutarlılık sağlar ama işlemleri sıraya sokar; eşzamanlılık düşer ve yoğun sistemlerde işlemler birbirini beklemeye başlar. Çoğu web uygulaması orta seviyelerle çalışır.
Veritabanı diski neden sessizce şişiyor?
Açık kalmış uzun bir işlem olabilir. Bu, veritabanının eski satır sürümlerini temizlemesini engeller ve sorun işlem kapanana kadar çözülmez. Unutulmuş bir yönetim oturumu bile buna yol açabilir; işlemleri kısa tutun.
Karşılıklı kilitlenme hatası alıyorum, ne yapmalıyım?
Bu normal bir durumdur; veritabanı işlemlerden birini iptal ederek çözer ve uygulamanın hatayı yakalayıp yeniden denemesi beklenir. Yeniden deneme genellikle başarılı olur. Kilitleri tüm kodda aynı sırada almak sıklığı azaltır.
