SQL mu NoSQL mu? Doğru Database'i Seçmenin Gerçek Rehberi

"Bu proje için hangi database kullanmalıyım?" — en sık sorulan mimari sorulardan biri. Ve maalesef en sık yanlış yanıtlanan.

Çoğu geliştirici bu soruya alışkanlıkla ya da moda akımlara göre cevap verir. "NoSQL daha hızlı" (yanlış). "SQL daha güvenilir" (bağlı). "MongoDB her şeye uyar" (kesinlikle hayır). Doğru soru "hangisi daha iyi?" değil, "hangi database hangi problemi çözer?"

İlişkisel Database'ler (SQL): Temel Kavramlar

SQL database'leri, verileri tablolarda satır ve sütunlar halinde saklar. Tablolar arasında ilişkiler tanımlanır. Bu ilişkiler sayesinde karmaşık sorgular çalıştırılabilir.

ACID garantisi, SQL database'lerinin en güçlü özelliğidir:

Atomicity — bir işlem ya tamamen gerçekleşir ya da hiç gerçekleşmez. Banka transferinde para bir hesaptan çıktı ama diğerine girmedi diye bir durum olmaz.

Consistency — her işlem database'i geçerli bir durumdan başka bir geçerli duruma taşır. Tanımlı kurallara uymayan veri asla yazılamaz.

Isolation — eş zamanlı işlemler birbirini etkilemez. Aynı veriyi aynı anda iki farklı işlem değiştirmeye çalıştığında sistem bunu doğru yönetir.

Durability — tamamlanan işlem kalıcıdır. Sistem çökmesi bile onaylanmış veriyi kaybettirmez.

-- Klasik ilişkisel yapı örneği
CREATE TABLE users (
    id          SERIAL PRIMARY KEY,
    email       VARCHAR(255) UNIQUE NOT NULL,
    created_at  TIMESTAMP DEFAULT NOW()
);

CREATE TABLE orders (
    id          SERIAL PRIMARY KEY,
    user_id     INTEGER REFERENCES users(id),
    total       DECIMAL(10,2) NOT NULL,
    status      VARCHAR(50) DEFAULT 'pending',
    created_at  TIMESTAMP DEFAULT NOW()
);

-- JOIN ile ilişkili veriyi çek
SELECT u.email, COUNT(o.id) as order_count, SUM(o.total) as total_spent
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
GROUP BY u.id
ORDER BY total_spent DESC;

Ne zaman SQL kullanmalı?

Veriler arasında net ilişkiler var ve bu ilişkileri sorgularken kullanacaksanız. Finansal işlemler, sipariş yönetimi, kullanıcı hesapları — ACID garantisinin kritik olduğu her yerde. Schema'nız önceden bellidir ve büyük bölümü değişmeyecektir.

NoSQL Database'leri: Farklı Problemler İçin Farklı Çözümler

"NoSQL" aslında tek bir şey değildir. Birbirinden çok farklı dört ana kategori var ve her biri farklı bir problemi çözer.

1. Document Database'ler (MongoDB, Firestore)

Veriyi JSON benzeri dokümanlar halinde saklar. Her dokümanın farklı alanları olabilir — schema esnektir.

// MongoDB örneği - kullanıcı profili
{
  "_id": "64a7f3b2c1d2e3f4a5b6c7d8",
  "email": "ali@example.com",
  "profile": {
    "name": "Ali Yılmaz",
    "avatar": "https://cdn.example.com/avatars/ali.jpg",
    "bio": "Backend Developer"
  },
  "preferences": {
    "theme": "dark",
    "notifications": {
      "email": true,
      "push": false
    }
  },
  "tags": ["javascript", "nodejs", "docker"]
}

İlişkisel bir database'de bu veri users, profiles, preferences ve tags tablolarına bölünürdü. MongoDB'de tek sorguda tüm veri gelir.

Ne zaman document database kullanmalı? Her kullanıcının farklı özelliklere sahip olduğu katalog sistemleri, içerik yönetim sistemleri, kullanıcı profilleri. Schema'nın sık değişeceği, iç içe ve esnek yapılı veriler.

2. Key-Value Store'lar (Redis, DynamoDB)

En basit NoSQL türü. Bir anahtar verilir, bir değer döner. Son derece hızlı — Redis genellikle bellek üzerinde çalışır ve mikrosaniye cinsinden yanıt verir.

// Redis örneği
await redis.set('session:user:123', JSON.stringify(sessionData), 'EX', 3600);
const session = await redis.get('session:user:123');

// Rate limiting için sayaç
await redis.incr('api:requests:user:123');
await redis.expire('api:requests:user:123', 60);

// Cache
await redis.setex('product:456', 300, JSON.stringify(productData));

Ne zaman key-value store kullanmalı? Session yönetimi, cache, rate limiting, leaderboard, gerçek zamanlı sayaçlar. Hızın her şeyden önemli olduğu ve verinin basit yapıda kaldığı durumlar.

3. Column-Family Store'lar (Apache Cassandra, HBase)

Veriyi satır yerine sütun grupları olarak saklar. Çok büyük veri setleri üzerinde yüksek yazma hızı gerektiğinde öne çıkar.

Cassandra'nın tasarımı Facebook'un inbox arama özelliği için yapılmıştır. Milyarlarca mesaj, saniyede milyonlarca yazma işlemi — ilişkisel bir database bu yükü kaldıramaz.

Ne zaman column-family store kullanmalı? IoT sensör verileri, log analitik, zaman serisi verileri, coğrafi dağıtık ve yüksek yazma hızı gerektiren sistemler.

4. Graf Database'leri (Neo4j, Amazon Neptune)

Veriyi düğümler (nodes) ve kenarlar (edges) olarak saklar. İlişkilerin kendisinin veri olduğu durumlar için biçilmiş kaftan.

// Neo4j - Cypher sorgu dili
// Ortak arkadaşları bul
MATCH (user:Person {name: "Ali"})-[:FRIENDS_WITH]->(friend)
      -[:FRIENDS_WITH]->(suggestion:Person)
WHERE NOT (user)-[:FRIENDS_WITH]->(suggestion)
  AND user <> suggestion
RETURN suggestion.name, COUNT(friend) AS mutual_friends
ORDER BY mutual_friends DESC
LIMIT 10

Bu sorguyu SQL ile yazmak mümkün ama karmaşık self-join'ler gerektirir ve büyük veri setlerinde son derece yavaşlar.

Ne zaman graf database kullanmalı? Sosyal ağlar, öneri sistemleri, fraud detection, knowledge graph'lar. İlişkilerin kendisini sorgulamanın önemli olduğu her yer.

Karşılaştırma: Hangi Durumda Hangisi?

Senaryo	Önerilen Database	Neden
E-ticaret siparişleri	PostgreSQL	ACID, ilişkisel veri
Kullanıcı session'ları	Redis	Hız, TTL desteği
Ürün kataloğu	MongoDB	Esnek schema
Sosyal ağ bağlantıları	Neo4j	İlişki sorguları
IoT sensör log'ları	Cassandra	Yüksek yazma hızı
Arama motoru	Elasticsearch	Full-text search

Polyglot Persistence: Tek Database Yetmez

Modern uygulamaların çoğu tek bir database türüyle çalışmaz. Bu yaklaşıma polyglot persistence denir — her veri türü için en uygun storage seçilir.

Bir e-ticaret platformu düşünün:

PostgreSQL — kullanıcı hesapları ve sipariş geçmişi (ACID kritik) Redis — session yönetimi ve sayfa cache'i (hız kritik) Elasticsearch — ürün arama (full-text search kritik) MongoDB — ürün kataloğu (esnek schema kritik)

Her database kendi güçlü olduğu alanda çalışır.

CAP Teoremi: Distributed Database'lerde Gerçek Hayat

Distributed sistemlerde üç garantiyi aynı anda sağlamak imkânsızdır: Consistency (tutarlılık), Availability (erişilebilirlik), Partition Tolerance (ağ bölünmesi toleransı). Herhangi ikisini seçebilirsiniz, üçünü birden seçemezsiniz.

Bu yüzden büyük ölçekli sistemler tutarlılıktan taviz verir — eventual consistency. Yazdığınız veri anında her sunucuya yansımayabilir ama bir süre sonra tüm sunucular aynı veriye ulaşır. Twitter'da beğeni sayısının bazen bir saniye gecikmeli güncellenmesi bundan kaynaklanır.

Sonuç: Doğru Soru

"SQL mı NoSQL mı?" yanlış soru. Doğru sorular şunlar:

Verilerim arasındaki ilişkiler ne kadar karmaşık? ACID garantisine gerçekten ihtiyacım var mı? Read mi, write mi ağırlıklı? Ne kadar veri, ne kadar hız? Schema sabit mi, değişken mi?

Bu soruların cevapları database seçiminizi belirler. Ve çoğu zaman cevap birden fazla database'i birlikte kullanmaktır.