Derin Dalış: NoSQL Veri Tabanı Rehberi

Serinin ilk yazısında SQL ve ilişkisel veri tabanlarına giriş yapmış, DDL ifadelerini ve CRUD işlemlerini görmüştük. Bu bölümde ise madalyonun diğer yüzü var: NoSQL. Dört ana ailesini, SQL ile aralarındaki gerçek farkları ve ölçeklemenin neden bu tartışmanın merkezinde olduğunu ele alacağım.

NoSQL Veri Tabanı Nedir?

İsimden başlayalım, çünkü yanıltıcı. NoSQL "SQL yok" demek değil, açılımı Not only SQL, yani "sadece SQL değil". Terim tek bir teknolojiyi değil, ilişkisel modelin dışında kalan bir grup veri tabanını kapsıyor. Ortak noktaları sabit bir şema dayatmamaları ve baştan birden fazla makineye yayılmak üzere tasarlanmış olmaları. Kaydın yapısı zaman içinde değişiyorsa ya da veri tek bir sunucuya sığmayacak kadar büyüyorsa gündeme geliyorlar.

SQL ve NoSQL Veri Tabanları arasındaki farklara geçmeden önce, eğer göz atmadıysanız Derin Dalış: SQL ve İlişkisel Veri Tabanı Rehberi başlıklı yazıma göz atmanızı öneririm.

Burada CAP teoremine değinmek gerekiyor. Teorem, dağıtık bir sistemin tutarlılık (Consistency), erişilebilirlik (Availability) ve bölünme toleransı (Partition tolerance) özelliklerinden üçünü birden garanti edemeyeceğini söyler. Burada çoğu kişinin atladığı bir ayrıntı var. Ağ bölünmesi sizin seçtiğiniz bir şey değil, er geç yaşanır. Yani gerçek tercih üç şık arasında değil, bölünme anında tutarlılıktan mı yoksa erişilebilirlikten mi vazgeçeceğiniz arasında. Banka bakiyesi okuyorsanız tutarlılığı, ürün yorumlarını gösteriyorsanız erişilebilirliği seçersiniz.

Consistency: Dağıtık sistemdeki tüm node’ların aynı veriye sahip olması durumu.

Availability: Sisteme yapılan her isteğin başarılı olarak sonuçlanması durumu. (En güncel veriye sahip olmasa bile)

Partition Tolerance: Mevcut node’lardan bir kısmında network veya başka bir sebeple erişilmezlik meydana geldiğinde, sistemin çalışmasına devam etmesi durumu.

NoSQL Veri Tabanı Türleri

• Anahtar/Değer (Key/Value) depolanan veri tabanları
• Sütun tabanlı veri tabanları
• Grafik tabanlı veri tabanları
• Belge (Document) tabanlı veri tabanları

1. Belge (Document) tabanlı veri tabanları

Document tabanlı veri tabanlarında, veriler document olarak isimlendirilen .JSON, .BSON veya .XML formatındaki belgelerde depolanır. Veri tabanındaki belgeler esnek bir şema yapısına sahiptir, belgeler aynı şema yapısında olmak zorunda değildir. Koleksiyon adı verilen belge gruplarında saklanırlar. İki belge arasındaki ilişki de dinamik bir ilişki yoktur, bu sebeple foreign key kullanımına gerek yoktur.

MongoDB ve CouchDB örnek verilebilir.

2. Anahtar/Değer (Key/Value) tipi depolanan veri tabanları

Anahtar-değer tipi depolama, NoSQL veri tabanının en basit biçimidir. Basitlik, ölçeklenebilirlik ve hız sunar. Veri tabanındaki her veri, anahtar/değer çiftlerinde depolanır.

Redis örnek verilebilir.

3. Sütun tabanlı veri tabanları (Column-Oriented)

Sütun tabanlı veri tabanlarında, veriler sütunlarda depolanır, satırlar kullanılmaz. Ölçeklenebilir, sıkıştırılabilir (compression) ve çok duyarlıdır (very responsive). Sütun yönelimli veri tabanları, daha az bellek tüketimi sağlar; çünkü sadece istenen verilere bellek tüketimi yapılır. Çok işlemli veri okumaları için sütun yönelimli veri tabanları, daha az bellek tüketimi sağlar; çünkü sadece istenen verilere bellek tüketimi yapılır.

Cassandra ve HBase örnek verilebilir.

4. Grafik tabanlı veri tabanları

Grafik tabanlı veritabanları, elemanlar arasındaki ilişkiye odaklanır. Verileri veritabanında node (düğüm) şeklinde depolar. Node’lar arasındaki bağlantılara links (bağlantılar) veya relationships (ilişkiler) denir.

Neo4J örnek verilebilir.

SQL Veri Tabanı ve NoSQL Veri Tabanı Arasındaki Farklar

Bu iki teknolojinin en temel farkı; SQL veri tabanları ilişkiseldir, NoSQL veri tabanları ise ilişkisel değildir.

İlişkisel Veri Tabanları, (RDBMS) transaction (işlem) tabanlı sistemlerdir. NoSQL Veri Tabanları ise bu kurallara tamamen uygun değildir. ACID kuralları olarak adlandırılan ve her bir harfin kısaltması olan Atomicity, Consistency, Isolation, Durability, veri bütünlüğünü sağlamak ve hatayı minimuma indirmek için gerekli kurallardır.

Şema: SQL tarafında tablo yapısı önden tanımlanır ve veri tabanı buna uymayan kaydı reddeder. NoSQL tarafında şema esnektir, ama şema kaybolmaz; yalnızca doğrulama sorumluluğu veri tabanından uygulama koduna geçer.

SQL veri tabanları dikey olarak ölçeklenebilirken (vertically scalable), NoSQL veri tabanları yatay olarak ölçeklenebilir (horizontally scalable).

SQL veri tabanları tablo tabanlıdır (table-based), NoSQL veri tabanları ise doküman (document), key-value (anahtar-değer), graph ya da geniş kapsamlı veri yapılarını kullanır.

İşlemler (transaction): Birden fazla kaydı ya hep ya hiç mantığıyla güncellemeniz gerekiyorsa ilişkisel tarafın işi hala daha rahat. Yine de bu ayrım eskisi kadar keskin değil; örneğin MongoDB 4.0’dan beri çok dokümanlı ACID işlemleri destekliyor.

Ölçeklendirme (Scaling) Nedir?

Dikey ölçekleme: Mevcut sunucuya daha fazla CPU, RAM veya disk eklemek. Uygulamada hiçbir değişiklik gerektirmediği için en kolay yol, ama bir tavanı var ve o tavana yaklaştıkça donanım maliyeti orantısız biçimde artıyor. İlişkisel veri tabanları geleneksel olarak bu yolu izler.

Yatay ölçekleme: Tek bir makineyi büyütmek yerine havuza yeni makineler eklemek. Tavanı yok ama bedeli var: veri artık parçalara bölünüyor, dolayısıyla makineler arası tutarlılık ve sorgulama sizin probleminiz oluyor. NoSQL veri tabanları bu iş için tasarlandı. Şunu da eklemek lazım, artık ilişkisel tarafta da okuma replikaları ve dağıtık motorlarla yatay ölçekleme mümkün; ayrım eskisi kadar net değil.

Sonuç

Toparlarsak, iki yaklaşım arasındaki seçim "hangisi daha iyi" sorusunun cevabı değil. Verinizin şekli ne kadar oturmuş ve tutarlılık ihtiyacınız ne kadar sıkı, mesele bu.

Kayıtlar arasında sıkı ilişkiler varsa, birden fazla tabloyu tek işlemde güncellemeniz gerekiyorsa ve ACID garantileri şart ise ilişkisel tarafta kalın. Kayıt yapısı sık değişiyorsa, veri tek makineye sığmıyorsa ya da erişim deseniniz baştan belli ve tek bir anahtar üzerinden ilerliyorsa NoSQL rahat ettirir.

Son bir nokta: ikisi arasında seçim yapmak zorunda değilsiniz. Pek çok sistem asıl veriyi ilişkisel tarafta tutup önbelleği Redis’e, arama dizinini ayrı bir motora bırakıyor. Sorulacak soru "hangi veri tabanını kullanayım" değil, "bu veri parçası için hangisi uygun" olmalı.

Serinin ilk yazısı SQL ve ilişkisel veri tabanlarını konu alıyordu. Bu ikinci bölümde NoSQL ailelerini, iki yaklaşım arasındaki farkları ve ölçekleme yöntemlerini ele aldık.

Bu konuda bilginizi derinleştirmek isterseniz, Eric Brewer'in CAP Teoremi'ni de okumanızı öneririm. Serinin devamına aşağıdan erişebilirsiniz. Ayrıca, tüm yazılarıma da göz atmayı unutmayın. Şimdilik hoşça kalın!

Referanslar

SQL vs NoSQL Database Differences Explained

What is NoSQL?

SQL databases are vertically scalable,data like documents or JSON

Types of NoSQL Databases

Horizontal Vs. Vertical Scaling

Microservice Mimari’lerde Veritabanı Tasarımı

Y. Gökşen, “Veri Büyüklüklerinin Veri tabanı Yönetim Sistemlerinde Meydana Getirdiği Değişim: NoSQL”, Bilişim Teknolojileri Dergisi, 8-3, 2015