SQL mi NoSQL mu: Seçim Rehberi

Yeni bir projeye başlarken en erken verilen ve en geç değiştirilen karar veritabanı seçimidir. Bir ay sonra web sunucunuzu değiştirebilir, altı ay sonra ön yüz kütüphanenizi bırakabilirsiniz; ama veritabanı seçimi kodun her katmanına sızar ve iki yıl sonra "bunu değiştirelim" demek koca bir proje anlamına gelir. SQL mi NoSQL mu sorusu bu yüzden ciddiye alınmayı hak eder — ama internette bulacağınız cevapların çoğu ya moda ya da ideoloji temellidir, mühendislik temelli değil.

Bu rehberde soruyu ideolojiden arındırıp karar kriterlerine indirgeyeceğiz. Önce "NoSQL" etiketinin altında birbirinden tamamen farklı dört ayrı aile olduğunu göreceğiz, sonra ilişkisel veritabanlarının hangi işleri gerçekten daha iyi yaptığını konuşacağız, ardından somut bir kontrol listesiyle kendi projeniz için cevabı bulacaksınız. Sonunda da çoğu ekibin ulaştığı gerçekçi sonuca geleceğiz: doğru soru "hangisi" değil, "hangi veri hangi motorda" olabilir.

"NoSQL" Aslında Tek Bir Şey Değil#

NoSQL, bir teknoloji değil bir şemsiye terimdir ve altında birbirine hiç benzemeyen sistemler durur. Bunları tek bir kategori sanmak, karar verirken yaptığınız ilk ve en büyük hatadır. Pratikte dört aile vardır:

Doküman veritabanları (MongoDB, Couchbase) veriyi iç içe geçmiş JSON benzeri belgeler hâlinde saklar. Şema esnektir, aynı koleksiyondaki iki belge farklı alanlara sahip olabilir. Bir varlığın tüm bilgisini tek okumada almak istediğinizde güçlüdür.

Anahtar-değer depoları (Redis, Memcached) en yalın modeldir: bir anahtar, bir değer. Sorgulama yeteneği neredeyse yoktur ama gecikme mikrosaniye düzeyindedir. Önbellek, oturum saklama ve sayaçlar için biçilmiş kaftandır; ayrıntılar için Memcached nedir yazısına bakabilirsiniz.

Geniş kolonlu depolar (Cassandra, HBase) satırları partition'lara böler ve yatay ölçeklenmeyi mimarinin temeli yapar. Yazma hacmi çok yüksek, sorgu desenleri sabit sistemler için tasarlanmıştır. Ayrıntısı Apache Cassandra nedir yazısında.

Graf veritabanları (Neo4j, JanusGraph) ilişkileri birinci sınıf vatandaş yapar. "Bu kişinin arkadaşlarının arkadaşları arasında şu ilgi alanına sahip olanlar" gibi çok adımlı ilişki sorgularında ilişkisel JOIN zincirlerini ezer.

Bu tablonun son satırı önemlidir. İlişkisel veritabanları hiçbir kategoride "en iyi" değildir ama tüm kategorilerde "yeterince iyi"dir ve bu, çoğu proje için doğru cevabın ne olduğunu büyük ölçüde belirler.

İlişkisel Veritabanları Bugün Ne Yapabiliyor#

SQL tarafına dair kararınızı on yıl önceki bilgilerle vermeyin. Modern PostgreSQL ve MySQL, "NoSQL'e geçme" gerekçelerinin çoğunu ortadan kaldıracak özellikler kazandı. En başta JSON desteği geliyor: PostgreSQL'in jsonb tipi, indekslenebilir ve içinden sorgulanabilir şemasız veri saklamanıza izin verir.

-- Yarı yapılandırılmış veriyi ilişkisel tabloda saklamak
CREATE TABLE urunler (
    id          bigserial PRIMARY KEY,
    sku         text NOT NULL UNIQUE,
    fiyat       numeric(12,2) NOT NULL,
    ozellikler  jsonb NOT NULL DEFAULT '{}'::jsonb,
    olusturuldu timestamptz NOT NULL DEFAULT now()
);

-- jsonb içinde arama yapabilmek için GIN indeksi
CREATE INDEX idx_urun_ozellik ON urunler USING gin (ozellikler);

-- Belge veritabanı gibi sorgulama, ama transaction ve JOIN da elde
SELECT sku, fiyat, ozellikler->>'renk' AS renk
FROM urunler
WHERE ozellikler @> '{"kategori": "klavye", "kablosuz": true}'
  AND fiyat < 2500
ORDER BY fiyat;

Bu sorgu size doküman veritabanının esnekliğini verirken, aynı tablo üzerinde JOIN, yabancı anahtar kısıtı ve tam ACID transaction kullanmaya devam edebilirsiniz. Buna ek olarak modern ilişkisel motorlar bölümlendirme (partitioning), paralel sorgu yürütme, mantıksal replikasyon ve okuma replikaları sunar. Yani "şemam esnek olmalı" ya da "çok fazla veri var" gerekçelerinin ikisi de artık tek başına NoSQL'e geçmek için yeterli değildir. İki büyük ilişkisel motoru karşılaştırmak isterseniz MySQL ve PostgreSQL karşılaştırması doğrudan bu soruya odaklanıyor.

Karar Kriterleri: Kendinize Sormanız Gereken Sekiz Soru#

Karar vermenin en hızlı yolu, projeyi genel kategorilerle değil somut sorularla test etmektir. Aşağıdaki sekiz soruyu sırayla cevaplayın:

1. Veriniz doğal olarak tablo mu, belge mi, graf mı? Sipariş–müşteri–ürün üçlüsü tablodur. Bir CMS'in sayfa içeriği belgedir. Sosyal ağ bağlantıları graftır. Zorlamayın.
2. Birden fazla varlığı atomik olarak güncellemeniz gerekiyor mu? "Stoktan düş, siparişi oluştur, bakiyeyi azalt" üçlüsü tek transaction'da olmalıysa ilişkisel motor sizi çok daha az yorar.
3. Sorgu desenleriniz oturmuş mu? Oturmadıysa ve hâlâ değişiyorsa, sorguya göre tablo tasarlamayı gerektiren sistemlerden uzak durun.
4. Gerçek veri hacminiz ne? Yüzlerce gigabayt tek bir modern sunucu için sorun değildir. "Big data" kelimesini kullanmadan önce gerçek sayıyı ölçün.
5. Yazma mı okuma mı baskın? Yazma hacmi tek sunucunun sınırını gerçekten zorluyorsa dağıtık motorlar devreye girer.
6. Bir saniyelik eski veri okumak kabul edilebilir mi? Banka bakiyesi için hayır, beğeni sayacı için evet. Bu soru doğrudan CAP teoremi ödünleşmesine bakar.
7. Ekibinizde kim işletecek? Üç düğümlü bir küme, tek sunuculu bir veritabanından katbekat fazla operasyon bilgisi ister.
8. Raporlama ve iş zekâsı ihtiyacınız var mı? Varsa ve analistler doğrudan sorgu yazacaksa SQL'in yerini tutan bir şey yok.

Bu sorulara verdiğiniz cevapların çoğu ilişkisel tarafı işaret ediyorsa, tereddüt etmeyin. NoSQL'e geçmek için ikinci, üçüncü, beşinci ve altıncı sorulardan en az ikisinin net biçimde NoSQL'i işaret etmesi gerekir.

Tipik Senaryolar ve Doğru Cevaplar#

Teoriyi somutlaştırmak için gerçek projelerde sık karşılaşılan senaryolara bakalım:

Dikkat ederseniz listenin yarısından fazlası ilişkisel tarafı gösteriyor. Bu bir tesadüf değil; tipik bir iş uygulamasının çekirdek verisi neredeyse her zaman ilişkiseldir. NoSQL, bu çekirdeğin etrafındaki özel iş yükleri için devreye girer.

Ölçeklenme Gerçeği: Dikey, Yatay ve Sharding#

"NoSQL'e geçmemiz gerekiyor çünkü ölçeklenmemiz lazım" cümlesi, sektörde en sık duyulan ve en az sorgulanan gerekçedir. Gerçek şu ki modern donanımda tek bir ilişkisel sunucu şaşırtıcı derecede uzağa gider. 32 çekirdek, 128 GB bellek ve NVMe diske sahip bir PostgreSQL sunucusu, düzgün indekslenmiş bir şema ile saniyede on binlerce sorgu ve terabaytlarca veri taşıyabilir.

Ölçeklenme yolculuğunun mantıklı sırası şudur:

1. Önce sorguları düzeltin. Yavaş sorguların çoğu eksik indeks yüzündendir; ölçüm için MySQL yavaş sorgu bulma yazısındaki yöntemi kullanın.
2. Sonra önbellek ekleyin. Aynı sonucu tekrar tekrar üreten okumaları Redis veya Memcached'e alın.
3. Sonra dikey büyütün. Daha fazla RAM ve daha hızlı disk, en ucuz ölçeklenmedir.
4. Sonra okuma replikaları ekleyin. Okuma ağırlıklı yükün büyük kısmı replikalara dağıtılabilir.
5. En son sharding ya da dağıtık motor düşünün. Buraya gelene kadar geçen süre çoğu projede yıllarla ölçülür.

# Gerçek boyutu ölçmeden karar vermeyin: PostgreSQL'de veritabanı boyutları
psql -c "SELECT datname, pg_size_pretty(pg_database_size(datname)) FROM pg_database ORDER BY pg_database_size(datname) DESC;"

# MySQL'de tablo bazında boyut ve satır sayısı
mysql -e "SELECT table_name, table_rows, ROUND(data_length/1024/1024) AS veri_mb, ROUND(index_length/1024/1024) AS indeks_mb FROM information_schema.tables WHERE table_schema='uygulama' ORDER BY data_length DESC LIMIT 10;"

Bu komutları çalıştırıp gerçek sayıyı gördükten sonra pek çok ekip "aslında ölçeklenme sorunumuz yokmuş, indeks sorunumuz varmış" sonucuna varır. Donanım tarafında sıkışıyorsanız da önce VDS veya bulut sunucu paketleriyle dikey büyümeyi denemek, dağıtık bir kümeye geçmekten hem ucuz hem de çok daha az risklidir.

Melez Yaklaşım: Hangi Veri Hangi Motorda#

Olgun sistemlerin neredeyse tamamı tek bir veritabanı kullanmaz. Buna polyglot persistence denir ve pratikte şöyle görünür: çekirdek iş verisi PostgreSQL'de, oturum ve önbellek Redis'te, arama Elasticsearch'te, metrikler InfluxDB'de. Her motor kendi güçlü olduğu işi yapar ve hiçbiri yapmadığı iş için zorlanmaz.

Bu yaklaşımın bedeli operasyonel karmaşıklıktır: dört ayrı sistemin yedeklenmesi, izlenmesi, güncellenmesi ve güvenliği gerekir. Bu yüzden altın kural şudur: yeni bir veritabanı motorunu ancak mevcut motorun o işi gerçekten kötü yaptığını ölçtükten sonra ekleyin. "İleride lazım olur" gerekçesiyle eklenen her motor, ekibinize kalıcı bir bakım borcu yazar.

Melez mimaride sıklıkla unutulan bir nokta da tutarlılıktır. Veriyi hem PostgreSQL'e hem Elasticsearch'e yazıyorsanız, ikisi arasında bir senkronizasyon gecikmesi ve bir "hangisi doğru" sorusu doğar. Cevabı baştan verin: bir veri için tek bir kaynak otoritesi (source of truth) belirleyin, diğerleri yalnızca türev kopya olsun.

Sık Yapılan Hatalar#

Modaya göre seçmek birinci sıradadır. Bir teknoloji konferansında beğendiğiniz mimari, sizin trafiğinizin yüz katına sahip bir şirketin problemine çözüm olarak tasarlanmıştır. Onların sorunu sizin sorununuz değilse, çözümü de sizin çözümünüz değildir.

İlişkisel veritabanını yanlış kullanıp suçlamak ikinci sıradadır. Her sorguyu SELECT * ile çeken, indeks tanımlamayan, N+1 sorgu üreten bir ORM kullanan bir uygulama yavaşladığında sorun veritabanı değildir. NoSQL'e geçtiğinizde aynı hataları oraya taşırsınız ve bu kez hata ayıklamak için elinizde EXPLAIN bile olmaz.

Şemasız olmayı şema tasarlamamak sanmak üçüncüsüdür. Doküman veritabanları şemayı veritabanından uygulamaya taşır; ortadan kaldırmaz. Şemayı yazılı bir yerde tutmazsanız, iki yıl sonra aynı koleksiyonda email, eposta ve mail alanlarını taşıyan üç kuşak belge bulursunuz ve hiçbir migration aracı size yardım edemez.

Transaction ihtiyacını küçümsemek dördüncüsüdür. "Uygulama katmanında hallederiz" cümlesi, dağıtık bir sistemde ağ kesintisi olduğunda yarım kalan işlemleri temizlemekten sorumlu olacağınız anlamına gelir. Bu, göründüğünden çok daha zor bir problemdir.

Sıkça Sorulan Sorular#

NoSQL, SQL'den daha mı hızlıdır#

Genel bir "daha hızlı" iddiası doğru değildir; hız, iş yüküne ve tasarıma bağlıdır. Anahtar bazlı tek kayıt okumasında bir anahtar-değer deposu ilişkisel motoru rahatça geçer. Buna karşılık üç tabloyu birleştiren bir raporlama sorgusunda ilişkisel motor, aynı işi uygulama katmanında yapmak zorunda kalan NoSQL çözümünden kat kat hızlıdır. Doğru soru "hangisi hızlı" değil, "benim sorgu desenim hangisinde daha az iş yapıyor" sorusudur.

Küçük bir projeye hangisiyle başlamalıyım#

Neredeyse her durumda ilişkisel bir veritabanıyla, tercihen PostgreSQL ile başlayın. Şemasız veri ihtiyacınız varsa jsonb kolonu bunu karşılar, ölçeklenme ihtiyacınız doğarsa okuma replikası ve bölümlendirme uzun süre yeter. Projeniz büyüdüğünde spesifik bir darboğaz ortaya çıkarsa, o darboğaz için özel bir motoru sonradan eklemek her zaman mümkündür. Tersi, yani dağıtık bir NoSQL kurulumundan ilişkisele dönmek çok daha zahmetlidir.

MongoDB transaction destekliyor mu#

Modern MongoDB sürümleri çok belgeli ACID transaction desteği sunar, ancak bu desteğin bir maliyeti ve bazı sınırları vardır; replica set ya da sharded küme yapılandırması gerektirir ve yoğun kullanıldığında performansı belirgin biçimde etkiler. MongoDB'nin tasarım felsefesi, ilgili veriyi tek bir belgede toplayarak çoklu belge transaction ihtiyacını en aza indirmektir. Uygulamanız sürekli çok belgeli transaction'a ihtiyaç duyuyorsa, bu genellikle veri modelinin ilişkisel olduğunun işaretidir.

Aynı projede hem SQL hem NoSQL kullanabilir miyim#

Evet ve bu, olgun sistemlerde oldukça yaygındır. Çekirdek iş verisini ilişkisel bir motorda tutup, önbelleği Redis'e, tam metin aramayı bir arama motoruna, metrikleri bir zaman serisi veritabanına vermek son derece makul bir mimaridir. Dikkat etmeniz gereken tek şey, her ek motorun yedekleme, izleme ve güvenlik açısından size kalıcı bir operasyon yükü getirdiğidir. Yeni bir motoru ancak ölçülmüş bir ihtiyaç varsa ekleyin.

Şemasız veritabanı gerçekten şema gerektirmiyor mu#

Şema ortadan kalkmaz, sadece yeri değişir. Veritabanı artık alan adlarını ve tiplerini denetlemediği için bu sorumluluk tamamen uygulama koduna geçer. Pratikte bu, uygulama katmanında bir doğrulama şeması tanımlamanız ve belge sürümlerini yönetmeniz gerektiği anlamına gelir. Bunu yapmazsanız veriniz zamanla tutarsızlaşır ve hangi alanın hangi kuşak belgede bulunduğunu kimse bilemez hâle gelir.

Veritabanını sonradan değiştirmek ne kadar zor#

Beklediğinizden çok daha zor. Veri taşıma işi teknik olarak çözülebilir olsa da, sorgu mantığı, transaction sınırları, hata yönetimi ve performans varsayımları kodun her yerine dağılmıştır. Bir ORM kullanmak taşımayı kolaylaştırmaz; ORM'ler motorlar arası farkları gizlemeye çalışırken çoğu zaman en kritik farkları da gizler. Bu yüzden ilk seçimi ciddiye almak, sonradan değiştirmeye güvenmekten çok daha akıllıcadır.

Kapanış#

SQL mi NoSQL mu sorusunun dürüst cevabı şudur: çoğu proje için ilişkisel bir veritabanı doğru başlangıçtır ve NoSQL, ölçülmüş belirli bir darboğaz için sonradan eklenen özel bir araçtır. Aklınızda kalması gereken dört alışkanlık şunlar: kararı moda üzerinden değil veri şekli ve tutarlılık ihtiyacı üzerinden verin; "çok veri var" demeden önce gerçek boyutu ölçün; ölçeklenmede önce indeks, önbellek ve dikey büyümeyi tüketin; ve her yeni motoru kalıcı bir operasyon borcu olarak görüp gerçekten gerektiğinde ekleyin.

Hangi motoru seçerseniz seçin, altındaki donanım ve işletim kalitesi performansın yarısını belirler. Tek sunuculu ilişkisel bir kurulum için VDS ve bulut sunucu paketleri fazlasıyla yeterlidir; yüksek yazma hacimli dağıtık kümeler için dedicated sunucu tarafına bakabilirsiniz. Kurulum, ayar ve yedek planını kendiniz üstlenmek istemiyorsanız sunucu yönetimi hizmetimiz bu işi devralır; uygulamanız paylaşımlı bir ortamda çalışacaksa web hosting paketlerimizde hazır MySQL/MariaDB altyapısı gelir.