Herkese selam. Vladislav Rodin temas halinde. Şu anda OTUS'ta Yüksek İş Yükü Mimarlığı kursunun Kurs Lideriyim ve aynı zamanda yazılım mimarisi dersleri veriyorum.
Öğretmenlik yapmanın yanı sıra, fark etmiş olabileceğiniz gibi, Habré'deki OTUS blogu için orijinal materyaller yazıyorum ve bugünkü makaleyle kursun başlangıcına denk gelmek istiyorum. Şu anda kayıt için açık.
Giriş
В Veritabanlarındaki işlemlerin iki sorunun çözümüne hizmet ettiğinden bahsettik: Hata toleransının sağlanması ve rekabet ortamında verilere erişim. Bu görevleri tam olarak gerçekleştirmek için işlemin ACID özelliklerine sahip olması gerekir. Bugün mektup hakkında detaylı olarak konuşacağız. ben (izolasyon) bu kısaltmada.
Yalıtım
İzolasyon, rekabet ortamında verilere erişim sorununu çözüyor ve esasen yarış koşullarından korunma sağlıyor. İdeal olarak izolasyon, serileştirme anlamına gelir; bu, işlemlerin paralel olarak yürütülmesinin sonucunun, sırayla yürütülmüş gibi aynı olmasını sağlayan bir özelliktir. Bu özelliğin temel sorunu, teknik olarak sağlanmasının çok zor olması ve bunun sonucunda sistem performansı üzerinde önemli bir etkiye sahip olmasıdır. Aşağıda tartışılacak olan belirli anormalliklerin riskleri kabul edilerek izolasyonun sıklıkla zayıflatılmasının nedeni budur. Belirli anormalliklerin meydana gelme olasılığı, işlem izolasyonunun düzeyini tam olarak karakterize eder.
En bilinen anormallikler şunlardır: kirli okuma, tekrarlanamayan okuma, hayalet okuma, ancak aslında 5 tane daha var: kirli yazma, imleç kaybı güncellemesi, kayıp güncelleme, okuma çarpıklığı, yazma çarpıklığı.
Kirli yazma
Anormalliğin özü, işlemlerin kaydedilmemiş verilerin üzerine yazılabilmesidir.
Bu anormallik, yalnızca her iki işlemin gerçekleştirilmesinden sonra verilerin çakışabilmesi nedeniyle değil (resimde olduğu gibi) değil, aynı zamanda atomikliğin ihlal edilmesi nedeniyle de tehlikelidir: kaydedilmemiş verilerin üzerine yazılmasına izin verdiğimiz için, bir işlemin diğerini etkilemeden nasıl geri alınacağı açık değildir. .
Anormallik oldukça basit bir şekilde ele alınabilir: Kayda başlamadan önce kayda bir kilit takarız, böylece kilit kaldırılana kadar diğer işlemlerin kaydı değiştirmesini yasaklarız.
Kirli okuma
Kirli okuma, kaydedilmemiş verilerin okunması anlamına gelir.
Örneğe dayalı olarak eylem veya karar alınması gerektiğinde sorunlar ortaya çıkar.
Anormalliği düzeltmek için bir okuma kilidi takabilirsiniz ancak bu, performansı büyük ölçüde etkileyecektir. Geri alma işlemi için verinin başlangıç durumunun (kayda başlamadan önceki) sisteme kaydedilmesi gerektiğini söylemek çok daha basittir. Neden oradan okumuyorsunuz? Çoğu veritabanının kirli okumayı varsayılan olarak kaldırmasına yetecek kadar ucuzdur.
Kayıp güncelleme
Kayıp güncelleme, güncellemelerin kaybolması anlamına gelir ve çeviri, sorunun özünü oldukça doğru bir şekilde yansıtmaktadır:
Aslında T2 işleminin sonucu tersine döndü. Bu durum açık veya örtülü yazma kilitleri ile düzeltilebilir. Yani, ya kaydı güncelleriz ve ardından örtülü bir kilit oluşur ya da güncelleme için seçokuma ve yazma kilidinin oluşmasına neden olur. Lütfen böyle bir işlemin oldukça tehlikeli olduğunu unutmayın: "masum" okumamızla diğer okumaları engelleriz. Bazı veritabanları daha güvenlidir paylaşım için seç, verilerin okunmasına izin verir ancak değiştirilmez.
İmleç güncellemeyi kaybetti
Daha hassas kontrol için bazlar imleç gibi başka araçlar da sunabilir. İmleç, bir dizi satır içeren ve bunlar üzerinde yineleme yapmanızı sağlayan bir yapıdır. select_statement için imleç_adı bildir. İmlecin içeriği seçilerek tanımlanır.
Neden bir imlece ihtiyacınız var? Gerçek şu ki, bazı veritabanları seçme yoluyla seçilen tüm kayıtlar (okuma kararlılığı) veya yalnızca imlecin o anda bulunduğu kayıt (imleç kararlılığı) için bir kilit sunar. İmleç kararlılığıyla, büyük bir veri örneği üzerinde yineleme yaptığımızda kilit sayısını azaltmamıza olanak tanıyan kısa kilit uygulanır. Bu nedenle kayıp güncelleme anormalliği imleç için ayrı ayrı izole edilir.
Tekrarlanamayan okuma
Tekrarlanamayan okuma, işlemimizin yürütülmesi sırasında aynı kaydın 2 kez arka arkaya okunmasının farklı sonuçlara yol açmasıdır, çünkü bu iki okuma arasına başka bir işlem müdahale ederek verilerimizi değiştirip commit edilmiş olur.
Bu neden bir sorun? Resimdeki T2 işleminin amacının fiyatı 150 USD'nin altında olan tüm malları seçmek olduğunu düşünün. Başka biri fiyatı 200$ olarak güncelledi. Bu nedenle kurulu filtre çalışmadı.
Bu anormallikler, iki fazlı kilitlemeler eklendiğinde veya MVCC mekanizması kullanıldığında, ki bunu ayrı olarak tartışmak istiyorum, ortaya çıkmayı bırakır.
Hayalet okuma
Phantom, başka bir işlem tarafından eklenen verilerin okunmasıdır.
Örnek olarak bu anomali oluştuğunda en ucuz ürünün yanlış seçildiğini görebiliriz.
Hayalet okumalardan kurtulmak zaten oldukça zor. Düzenli engelleme yeterli değildir çünkü henüz var olmayan bir şeyi engelleyemeyiz. 2PL sistemleri tahmine dayalı kilitlemeyi kullanırken, MVCC sistemlerinde bir ekleme nedeniyle kesintiye uğrayabilecek işlemleri geri alan bir işlem zamanlayıcı bulunur. Hem birinci hem de ikinci mekanizma oldukça ağırdır.
Eğimi oku
İçeriği tutarlı bir şekilde değişmesi gereken birkaç tabloyla çalıştığımızda okuma çarpıklığı meydana gelir.
Diyelim ki gönderileri ve bunların meta bilgilerini temsil eden tablolarımız var:
Bir işlem tablolardan okur, diğeri bunları değiştirir:
T1 işleminin bir sonucu olarak gönderinin başlığı = İyi ve güncellendi_by = T2 var, bu da bir tür tutarsızlık.
Aslında bu tekrarlanamayan bir okumadır, ancak birkaç tablonun parçası olarak.
Bunu düzeltmek için T1 okuyacağı tüm satırlara kilit koyabilir, bu da T2 işleminin bilgileri değiştirmesini engelleyecektir. MVCC durumunda T2 işlemi iptal edilecektir. İmleçleri kullanırsak bu anormalliğe karşı koruma önemli hale gelebilir.
Eğri yaz
Bu anomaliyi bir örnekle açıklamak da daha kolaydır: Diyelim ki sistemimizde en az bir doktor görevde olmalı, ancak her iki doktor da görevlerini iptal etmeye karar verdi:
Anormallik, hiçbir doktorun görevde olmayacağı anlamına geliyordu. Bu neden oldu? Çünkü işlem başka bir işlem tarafından ihlal edilebilecek bir durumu kontrol ediyordu ve izolasyon nedeniyle bu değişikliği göremedik.
Bu aynı tekrarlanamayan okumadır. Alternatif olarak, seçimler bu kayıtlara kilit koyabilir.
Yazma çarpıklığı ve okuma çarpıklığı önceki anormalliklerin birleşimidir. Aslında hayalet bir okuma olan yazma çarpıklığını düşünebilirsiniz. Çalışanların adlarını, maaşlarını ve üzerinde çalıştıkları projeyi içeren bir tablo düşünün:
Sonuç olarak şu tabloyu görüyoruz: Her yönetici, yaptıkları değişikliğin bütçeyi aşmaya yol açmayacağını düşündü ve personel değişiklikleri yaparak maliyet aşımlarına yol açtı.
Sorunun nedeni hayalet okumadakiyle tamamen aynıdır.
Bulgular
Veritabanındaki işlem izolasyon düzeyinin gevşetilmesi, güvenlik ve performans arasında bir dengedir; bu düzeyin seçimine, belirli anormalliklerin meydana gelmesi halinde iş için potansiyel riskler temel alınarak yaklaşılmalıdır.
Kaynak: habr.com