Veritabanlarında Atomiklik: Güvenilir İşlemlerin Belkemiği

Atomiklik, veritabanı sistemlerinde temel bir kavramdır. Bir işlemin ya tamamen başarılı olması ya da hiç çalışmaması gerektiği anlamına gelir. Herhangi bir şey yarıda başarısız olursa, her şey hiç olmamış gibi geri alınır.

Peki bu neden bu kadar önemli, diye sorabilirsiniz. Bir banka hesabından diğerine para transfer ettiğinizi hayal edin. "Gönder"e bastınız, uygulama bir saniye yükleniyor ve sonra bir şeyler ters gidiyor. Para hesabınızdan çıkıyor ama diğerine ulaşmıyor. Şimdi para… yok oldu. İşte atomikliğin tam da engellemek için tasarlandığı senaryo budur.

Daha önce ACID'i duymuş olabilirsiniz. Veritabanlarının işlerin dağılmamasını sağlamak için kullandığı dört temel özelliğin bir kümesidir. Atomiklik bu listenin ilkindedir ve iyi bir nedenle: O olmadan, gerisi (Tutarlılık, Yalıtım ve Dayanıklılık) pek anlam ifade etmez.

Bu yazıda, atomikliğin ne anlama geldiğini, nasıl çalıştığını ve bankacılık ile e-ticaret gibi gündelik sistemlerde neden bu kadar kritik olduğunu inceleyeceğiz. Ayrıca farklı veritabanlarının bunu nasıl uyguladığını ve kaçınılmaz olarak bir şeyler ters gittiğinde işleri iyi idare edebilen atomik sistemleri nasıl tasarlayabileceğinizi de göreceğiz.

Atomiklik Nedir?

Atomiklik, veritabanındaki bir işlemin bölünemez olduğu anlamına gelir. Ya her adım planlandığı gibi ilerleyerek tamamlanır ya da hiç çalışmaz. Ara yol yoktur. Yarıda kalmış güncellemeler, kısmen kaydedilen veriler, bazı şeylerin başarıyla tamamlandığı bazılarının ise tamamlanmadığı garip bir araf yoktur.

DBMS'de Atomiklik. Kaynak: Arpit Bhayani

İşlemin bir parçası başarısız olursa, her şey hiç olmamış gibi geri alınır. Atomikliği bu kadar güçlü bir güvence yapan şey budur. O olmadan, özellikle birden fazla şeyin sıralı olarak gerçekleşmesi gereken sistemlerde, verilerinizi bozuk veya tutarsız bir durumda bırakma riskiyle sürekli karşı karşıya kalırsınız.

Atomikliğin sistemi ayakta tuttuğu (ya da bozduğu) birkaç gerçek dünya senaryosuna bakalım:

Örnek 1: Banka havalesi

Diyelim ki vadesiz hesabınızdan birikim hesabınıza 100$ aktarıyorsunuz.

İşlem iki bölümden oluşur:

1. Vadesizden 100$ düş
2. Birikime 100$ ekle

Atomiklik olmadan, bir ağ aksaklığı veya sunucu çökmesi nedeniyle birinci adım tamamlanıp ikinci adım başarısız olabilir. Tebrikler, paranız boşluğa karıştı. Atomiklik, her iki adımın birlikte başarılı olmasını ya da hiçbirinin olmamasını sağlar. Bir şeyler ters giderse, 100$ başlangıçta olduğu yerde kalır.

Örnek 2: Stok ve sipariş işleme

Çevrimiçi olarak son sınırlı üretim plakayı satın alıyorsunuz. Sistem şunları yapmalı:

1. Stoktan bir adet düş
2. Siparişinizi onayla

Atomiklik olmadan, stok azaltılabilir ama sipariş onaylanmadan sistem çöker. Şimdi mağaza stokta kalmadığını sanır, ama plakayı kimse alamaz. 

Çevrimiçi alışveriş yaparken bunun bana bu kadar sık olması şaşırtıcı. Genellikle sekmeyi kapatırım ve mühendislerine bol şans dilerim; ancak büyük olasılıkla o siteden bir daha alışveriş yapmam. Çekirdek satın alma işlevlerini güvenilir hale getiremiyorlarsa kişisel bilgilerimi nasıl işleyeceklerini kim bilir?

Örnek 3: Uçuş rezervasyon sistemi

Uçuş rezervasyonu genellikle sadece bir koltuk seçmekten ibaret değildir. Sistem şunları yapmalıdır:

1. Koltuk ataması yap
2. Koltuk uygunluğunu güncelle
3. Kartınızı çek

İkinci adım başarısız olup üçüncü adım gerçekleşirse, var olmayan bir koltuk için ödeme yapmış olursunuz. Pek ideal değil.

Örnek 4: Veritabanı ve arama indeksini senkronize etme

Diyelim ki uygulamanız bir ürünün açıklamasını ana veritabanında güncelliyor. Aynı zamanda, kullanıcıların ürünü yeni açıklamayla bulabilmesi için arama indeksini de güncellemesi gerekir.

Veritabanı güncellemesi başarılı olup indeks güncellemesi başarısız olursa, kullanıcılar güncel olmayan sonuçlar görür ya da ürünü hiç bulamaz.

Atomiklik Neden Önemlidir

Peki atomiklik neden bu kadar büyük bir mesele? 

Bir işlemin kesintiye uğraması için sayısız neden olabilir. Elektrik kesintisi, sunucu çökmesi veya işlemin yarısında bir ağ zaman aşımı olabilir. Atomiklik uygulanmazsa, işlem yalnızca kısmen tamamlanabilir. Artık veritabanınız tuhaf bir durumda kalır: bazı değişiklikler uygulanmış, diğerleri uygulanmamış ve bu karmaşayı geri almanın kolay bir yolu yoktur.

İşte veri hatalarının gerçekten sinsice davrandığı yer burasıdır. Kullanıcılar ilk başta yanlış bir şey fark etmeyebilir, ancak zamanla işler tutarsızlaşır. Analitikleriniz garip görünür, siparişler kaybolur, hesaplar tutmaz veya insanlar az önce kaydettiklerini bulamadıkları için destek talepleri artar.

Atomiklik, şunları sağlayarak tüm bunları önler:

• Bir işlem ya tamamen gerçekleşir ya da hiç gerçekleşmez
• Bir şeyler yarıda başarısız olsa bile sistem temiz şekilde kurtarılabilir
• Sistem çöküşlerinde veya eşzamanlı erişimde bile verileriniz tutarlı kalır

Ayrıca diğer ACID özellikleriyle yakından bağlantılıdır. Atomiklik olmadan tutarlılık çöker; çünkü verilerin yarısı eksikken kuralları uygulayamazsınız ve yalıtım bozulur; çünkü diğer kullanıcılar tamamlanmamış bir işlemden kısmi veriler görebilir.

Şunlarla uğraşıyorsanız özellikle önemlidir:

• Bir eylemin diğerine bağlı olduğu çok adımlı işlemler.
• İlişkili verilerin senkron tutulması gereken çok satırlı veya çok tablolı güncellemeler.
• İşlemin bölümlerinin farklı makinelerde veya veritabanlarında gerçekleştiği dağıtık sistemler.

Pratikte Atomiklik Nasıl Çalışır

"Ya hep ya hiç" basitliğinin ardında şaşırtıcı derecede karmaşık bir sistem yatar. Bir veritabanı bir işlemi yürütürken her adımı etkin biçimde izler, hazırlar ve korur.

İşte olup bitenlere üst düzey bir bakış:

İşlem yaşam döngüsü

1. İşlemi başlat: Sistem, yaklaşan değişiklikleri veritabanının geri kalanından yalıtarak bir işlemin başlangıcını işaretler.
2. İşlemi yürüt: Buna tüm insert, update, delete komutlarınız veya yaptığınız diğer SQL sihri dahildir.
3. Commit veya rollback: Tüm işlemler başarılı olursa işlem commit edilir ve değişiklikler kalıcı hale gelir. Herhangi bir şey başarısız olursa tüm işlem geri alınır.

Günlükleme ve journaling

Atomikliği sağlamak için veritabanları, bir şeyler gerçekten gerçekleşmeden önce nelerin olacağını yazar. Bu günlükler ayrı saklanır ve bir tür yedek plan görevi görür.

Sistem bir işlemin ortasında çökerse, günlük başvurularak tamamlanmamış değişiklikler geri alınabilir, tamamlananlar güvenle yeniden uygulanabilir ve veritabanı temiz, tutarlı bir duruma geri getirilebilir.

Bu yaklaşıma bazen Write-Ahead Logging (WAL) veya journaling denir ve çökme kurtarmanın kilit bir parçasıdır.

Geri alma ve kurtarma

Bir işlem başarısız olduğunda veritabanı pes etmez; değişiklikleri dikkatle geri alır. Değiştirilen satırlar özgün haline döndürülür, işlemin tuttuğu tüm kilitler serbest bırakılır ve kısmi güncellemeleri geri çevirmek için günlükler kullanılır.

Çökme durumunda ise, kurtarma rutinleri yeniden başlatma anında devreye girer. Günlükleri tekrar oynatır, yarım kalmış işlemleri çözümler ve veritabanının garip yarım hâller olmadan kaldığı yerden devam etmesini sağlar.

Performans ve atomiklik

Tahmin edileceği üzere, tüm bunların bir maliyeti vardır. Atomiklik şunları getirir:

• Kilitler: İşlemin ortasında başkalarının aynı veriyi değiştirmesini önlemek için
• Ek yük: Günlükleme ve geri alma mekanizmalarından kaynaklanan
• Kilitlenmeler: Birden fazla işlemin kaynakları serbest bırakmaları için birbirini beklemesi durumunda

Bu yüzden büyük işlemleri dikkatle tasarlamanız gerekir. Çok fazla işi tek seferde yaparsanız tüm sisteminizi yavaşlatabilir veya eşzamanlılık sorunlarına takılabilirsiniz.

Popüler Veritabanı Sistemlerinde Atomiklik

Atomiklik, tüm büyük veritabanlarında temel bir kavramdır, ancak uygulama şekli alttaki depolama motoruna ve tasarım felsefesine bağlı olarak biraz değişebilir. PostgreSQL ve MySQL (InnoDB) işlemlerin doğru çalıştığından nasıl emin oluyor birlikte bakalım.

PostgreSQL

Herhangi bir veri kalıcı olarak yazılmadan önce PostgreSQL, az önce bahsettiğimiz, amaçlanan her değişikliğin kaydı olan bir write-ahead log (WAL) oluşturur. Bu günlük güvenle saklanır ve işlem sırasında bir şeyler ters giderse bir kurtarma planı olarak kullanılır.

Bir işlem commit edildiğinde PostgreSQL WAL'ı kontrol eder, tüm değişikliklerin eksiksiz ve geçerli olduğunu onaylar ve ardından güncellemeleri kesinleştirir. Bir şeyler yarıda çökerse, veritabanı bu günlüğü kullanarak tamamlanmamış işleri geri alır.

Güzel olan şu ki, tüm bunlar perde arkasında otomatik olarak gerçekleşir. Geliştirici bakış açısından pürüzsüzdür: bir işlem yazarsınız ve PostgreSQL, karmaşıklığı yönetmenize gerek kalmadan atomikliği garanti eder.

İşlem tamamen commit edilene kadar diğer kullanıcılara hiçbir değişiklik görünmez. Bu, çok kullanıcılı ortamlarda tutarlılığı korur ve "yarım kaydedilmiş" gariplikleri önler.

PostgreSQL WAL. Kaynak: AlgoMaster

Kolları sıvayıp kendi veritabanlarınızı oluşturarak işlemleri test etmek istiyorsanız, PostgreSQL kursumuza göz atın.

MySQL (InnoDB)

MySQL'in InnoDB depolama motoru da atomik işlemleri destekler ve yaklaşımı hem güvenilirlik hem de performans için tasarlanmıştır.

PostgreSQL gibi, InnoDB de değişiklikleri commit etmeden önce izlemek için bir işlem günlüğü kullanır. Bir şeyler başarısız olursa, günlük her şeyi işlem öncesi duruma geri almak için kullanılır. Bu, kısmi güncellemelerin sızmasını engeller.

InnoDB'nin özellikle iyi yaptığı şeylerden biri yazmaları gruplayabilmesidir. Bu, disk I/O'yu azaltmaya ve atomikliği korurken performansı artırmaya yardımcı olur. Ayrıca geri alma sırasında değişiklikleri tersine çevirmek için undo log'ları ve çökme kurtarması için redo log'ları kullanır.

Tıpkı PostgreSQL'de olduğu gibi, bu mekanizmaları sizin yerinize veritabanına bırakabilirsiniz. Özel geri alma kodu yazmanız gerekmez.

Mühendisler ve Veri Mimarları için Önemli Noktalar

Kendi projelerinizde atomik işlemlerle çalışırken aklınızda tutmanız gereken bazı şeyler var. Esas fikir, atomikliği bir lüks değil, varsayılan olarak ele almaktır. Aynı anda birden fazla yerde veriyi değiştiren sistemler (aslında hepsi) kuruyorsanız, atomikliği temel alarak tasarlamak size zaman, akıl sağlığı ve muhtemel bir sabah 3'te olay bildirimi tasarrufu sağlayacaktır. 

İşe uygun veritabanını seçin

Tüm veritabanları atomikliği aynı şekilde ele almaz ve tüm depolama motorları eşit yaratılmamıştır. Atomiklik kullanım senaryonuz için kritikse (ör. finans, lojistik, kullanıcı durum yönetimi), veritabanınızın tam ACID işlemlerini desteklediğinden emin olun. Bu, depolama motoru seçiminin önemli olduğu MySQL kullanıyorsanız özellikle geçerlidir.

Hata durumlarına göre tasarlayın

İşlerin ters gideceğini varsayın; çünkü gidecektir. Çok adımlı işlemleri transaction içine alın ve hataları düzgün yönetin. BEGIN, COMMIT, ve ROLLBACK deyimlerinde açık olun veya bunları kaputun altında güvenle yöneten çerçeveler kullanın.

Çoğu modern ORM ve veri erişim katmanı yerleşik işlem desteği sunar. Örneğin:

• Node.js'de Prisma ve TypeORM gibi kütüphaneler, mantığı transaction() çağrısı içine alarak arka planda commit/rollback işlemlerini yönetmenizi sağlar.

• Python'da SQLAlchemy, güvenli commit ve rollback sağlamak için bağlam yöneticileri (with session.begin():) sunar.

• Java'da Spring gibi çerçeveler, metodları @Transactional ile anotasyonlayarak veritabanının her şeyi atomik olarak, birden çok fonksiyon çağrısına yayılsa bile, ele almasını sağlar.

Bu araçlar, varsayılan olarak güvenli şekilde inşa etmeyi çok daha kolaylaştırır. Özellikle uygulamanız karmaşıklaştıkça bir rollback'i unutma veya commit mantığını yanlış yönetme riskini azaltırlar.

Performans ile güvenilirliği dengeleyin

Atomiklik özellikle büyük işlemlerde belirli bir ek yük getirir. Mümkün olduğunda devasa işlemleri bölün, tüm tabloyu kilitlemekten kaçının ve işlemleri kısa ve odaklı tutun. Uzun süren işlemler çekişme, kilitlenme ve mutsuz kullanıcı riskini artırır.

Bağımlılıkları ve yalıtımı anlayın

Daha önce gördüğümüz gibi, atomiklik tek başına değil tutarlılık ve yalıtımla birlikte var olur. İlgili değişikliklerin birlikte gerçekleşmesini sağlayın ve eşzamanlı işlemlerin nasıl etkileşebileceğini düşünün. İş yükünüze uygun, işleri gereksiz yere karmaşıklaştırmayan yalıtım seviyeleri kullanın.

DBMS'de ACID Özellikleri. Kaynak: Datacamp

Gerçekçi hata senaryolarıyla test edin

Sadece mutlu patikalarınızı test etmeyin. Uygulamanız bir işlemin ortasında çöktüğünde ya da bir sorgu zaman aşımına uğradığında ne olacağını simüle edin. Sisteminizin baskı altında nasıl davrandığını görmek için failpoint'ler kullanabilir veya veritabanı hatalarını taklit edebilirsiniz.

Sonuç

Birden fazla şeyin birlikte gerçekleşmesi gereken sistemler kuruyorsanız, atomiklik isteğe bağlı değil, zorunludur. Hesaplar arası para transferi, stok güncelleme veya sistemleri senkronize etme fark etmeksizin, atomiklik verilerinizin bozuk veya yarım kalmış bir durumda sonlanmamasını sağlar.

Daha derine inmek isterseniz, neden Veritabanı Tasarımı kursumuzu almayasınız? SQL ile verileri daha verimli şekilde işlemek, depolamak ve düzenlemek için veritabanları tasarlamayı öğreneceksiniz.

Ve daha fazla pratik veritabanı tasarımı makalesi ve eğitimiyle ilgileniyorsanız, veritabanı normalleştirme serimize göz atın:

• SQL'de Normalleştirme (1NF - 5NF): Yeni Başlayanlar için Kılavuz eğitimi
• Birinci Normal Form (1NF) nedir? eğitimi
• İkinci Normal Form (2NF) nedir? eğitimi
• Üçüncü Normal Form (3NF) nedir? Eğitimi
• Geçişli Bağımlılık nedir? Eğitimi