Sql & Veritabanı İle Uygulamalar İçin Veri Saklama Mimarisi Nasıl Yapılır?

Gereksinimler ve Ön Hazırlık

Verimli bir veri saklama mimarisi kurmak için öncelikle doğru araçlara ve ortama sahip olmalısınız. 2026 yılı itibarıyla PostgreSQL veya MySQL 8.4+ sürümleri, endüstri standartlarında yüksek performans ve güvenlik sunmaktadır.

• Veritabanı Motoru: PostgreSQL 17 veya MySQL 9.0 (JSON desteği ve gelişmiş indeksleme için).
• İstemci Araçları: DBeaver veya pgAdmin gibi görsel yönetim arayüzleri.
• Sürüm Kontrolü: Veritabanı şemalarınızı yönetmek için "Migration" (Göç) araçlarını kullanmanız zorunludur.

Adım 1: Veri Normalizasyonu ve İlişkisel Tasarım

Veri saklama mimarisinin ilk adımı, verinin tekrarlanmasını önleyen normalizasyon işlemidir. Birinci (1NF), ikinci (2NF) ve üçüncü (3NF) normal form kurallarına uygun bir yapı, veri tutarsızlıklarını minimize eder. İlişkisel bir veritabanında tablolar arasındaki bağlantıları doğru kurmak, ileride yaşanacak "join" (birleştirme) performans sorunlarının önüne geçer.

-- Kullanıcılar ve profiller için bire-bir ilişki tasarımı
CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    email VARCHAR(255) UNIQUE NOT NULL,
    password_hash TEXT NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE user_profiles (
    user_id UUID PRIMARY KEY REFERENCES users(id) ON DELETE CASCADE,
    full_name VARCHAR(100),
    bio TEXT
);

Yukarıdaki örnekte, kullanıcı kimlik bilgileri ile profil bilgilerini ayırarak tablonun genişlemesini engelledik. UUID kullanımı, dış dünyadan gelecek tahmin edilebilir ID saldırılarını önlemek için 2026 standartlarında tercih edilen bir yöntemdir.

Adım 2: İndeksleme Stratejileri ile Performans Optimizasyonu

Veri miktarı arttıkça, sorgu süreleri uzar. İndeksleme, veritabanının veriyi arama yapmadan bulmasını sağlayan bir "içindekiler tablosu" gibidir. Ancak her sütuna indeks eklemek, yazma (INSERT/UPDATE) işlemlerini yavaşlatır. Stratejik indeksleme, okuma ağırlıklı sistemlerde kritik bir başarı faktörüdür.

-- Sık sorgulanan e-posta sütunu için B-Tree indeksi
CREATE INDEX idx_users_email ON users(email);

-- JSONB verileri içinde arama yapmak için GIN indeksi (PostgreSQL)
CREATE INDEX idx_user_settings ON user_profiles USING GIN (settings);

İndekslerinizi oluştururken, uygulamanızdaki "WHERE" koşullarını analiz edin. Sadece sıkça filtrelenen sütunlara indeks atayın. "Composite" (bileşik) indeksler, çoklu sütunlu aramalarda tekil indekslerden çok daha hızlı sonuç verir.

Adım 3: Güvenli Veri Saklama ve SQL Injection Koruması

Veri güvenliği, mimarinin en önemli parçasıdır. Kullanıcıdan gelen veriyi asla doğrudan sorguya dahil etmeyin. SQL Injection saldırılarını önlemek için "Prepared Statements" (Hazırlanmış İfadeler) kullanmak zorunludur. Ayrıca, hassas verileri (şifreler gibi) asla düz metin olarak saklamayın.

-- Güvenli bir şekilde veri ekleme (Parametreli Sorgu Mantığı)
-- Uygulama kodunda (Örn: Node.js/Python) şu şekilde çalıştırılmalıdır:
-- db.query('INSERT INTO users (email, password_hash) VALUES ($1, $2)', [email, hashed_password]);

Kritik Uyarı: Şifreleri saklarken mutlaka Argon2id veya bcrypt gibi güçlü hashing algoritmaları kullanın. Veritabanı seviyesinde "Row Level Security" (Satır Seviyesinde Güvenlik) kullanarak kullanıcıların sadece kendi verilerine erişmesini sağlayın.

Adım 4: Veri Saklama Yöntemlerinin Karşılaştırması

Uygulamanızın ihtiyacına göre doğru depolama yöntemini seçmek, mimari başarınızı belirler. Aşağıdaki tablo, yaygın veri saklama yaklaşımlarını özetlemektedir.

Adım 5: Veritabanı Migrations ve Versiyonlama

Veritabanı şemanız zamanla değişecektir. Bu değişiklikleri manuel yapmak yerine "Migration" dosyaları ile yönetin. Bu, ekibinizdeki diğer geliştiricilerin ve üretim ortamının (production) her zaman güncel şema ile çalışmasını sağlar.

-- 2026_05_20_add_phone_to_users.sql
ALTER TABLE users ADD COLUMN phone_number VARCHAR(20);
-- İşlem başarılı mı? Hemen test edin:
SELECT column_name FROM information_schema.columns WHERE table_name = 'users';

Migration dosyalarınızı her zaman küçük ve atomik tutun. Bir dosya, tek bir mantıksal değişikliği temsil etmelidir. Bu, olası bir hata durumunda geri dönüş (rollback) yapmanızı kolaylaştırır.

Adım 6: Veri Saklama Mimarisi Testleri ve İzleme

Mimariniz kurulduktan sonra, yük altındaki davranışını test etmelisiniz. EXPLAIN ANALYZE komutu, sorgularınızın nasıl çalıştığını ve indekslerin kullanılıp kullanılmadığını görmenizi sağlar.

-- Sorgu performansını analiz etme
EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'test@example.com';

Eğer sorgu "Seq Scan" (tüm tabloyu tarama) yapıyorsa, indeksiniz eksik veya hatalı demektir. İndeks verimliliğini izlemek için düzenli aralıklarla "Slow Query Log" (yavaş sorgu günlüğü) dosyalarını kontrol edin.

Sorumluluk Reddi: Bu rehberdeki kod örnekleri genel eğitim amaçlıdır. Üretim ortamında veritabanı şeması oluştururken, veri yedekleme stratejilerinizi (Backup/Restore) mutlaka devreye alın ve veritabanı erişim yetkilerini (Least Privilege Principle) minimum seviyede tutun.

Sıkça Sorulan Sorular

SQL veritabanında büyük verileri (blob) saklamalı mıyım?

Hayır, büyük dosyaları (resim, video) veritabanında saklamak veritabanı performansını ciddi oranda düşürür. Bu dosyaları bir nesne depolama servisinde (S3 vb.) saklayıp, veritabanında sadece dosya yolunu (URL) tutmalısınız.

JSONB sütunları ne zaman tercih edilmelidir?

Veri yapınızın sık değiştiği veya belirli bir şemaya tam olarak uymadığı durumlarda JSONB kullanımı esneklik sağlar. Ancak, yoğun filtreleme yapılacak alanları mutlaka ilişkisel sütunlarda tutmalısınız.

Veritabanı bağlantı havuzu (Connection Pooling) neden gereklidir?

Her istek için yeni bir veritabanı bağlantısı açmak maliyetlidir. Connection pooling, hazır bağlantıları yeniden kullanarak uygulamanın yanıt süresini hızlandırır ve veritabanı üzerindeki yükü dengeler.

SQL Injection'dan korunmak için en etkili yol nedir?

Kullanıcı verisini asla doğrudan sorgu dizisine eklemeyin. Her zaman ORM (Object Relational Mapping) araçları veya veritabanı sürücülerinizin sunduğu parametreli sorgu yöntemlerini kullanın.

Veritabanı normalizasyonu ne zaman bozulabilir?

Okuma performansının kritik olduğu ve verinin çok nadir güncellendiği "Read-Heavy" sistemlerde, performansı artırmak için kontrollü bir şekilde "denormalizasyon" (tabloları birleştirme) yapabilirsiniz.

Veritabanı Performans İzleme ve Sorgu Analizi

Veritabanı mimariniz ne kadar iyi tasarlanmış olursa olsun, zamanla veri hacminin artmasıyla birlikte sorgu sürelerinde yavaşlamalar kaçınılmazdır. Performans darboğazlarını tespit etmek için "Query Execution Plan" (Sorgu Çalıştırma Planı) analizini düzenli olarak yapmalısınız.

Yavaş Sorguları Tespit Etme

PostgreSQL veya MySQL gibi sistemlerde, belirli bir sürenin üzerinde çalışan sorguları loglamak, optimizasyon için ilk adımdır. Aşağıdaki örnek, PostgreSQL üzerinde 500ms'den uzun süren sorguları yakalamak için kullanılan konfigürasyon yaklaşımını gösterir:

-- PostgreSQL için yavaş sorgu loglama ayarı (postgresql.conf)
log_min_duration_statement = 500 
log_statement = 'none'
log_duration = on

-- Çalışan bir sorgunun performansını analiz etmek için:
EXPLAIN ANALYZE SELECT * FROM siparisler WHERE kullanici_id = 123;

EXPLAIN ANALYZE komutu, veritabanının sorguyu nasıl işlediğini, hangi indeksleri kullandığını ve hangi aşamada (Sequential Scan vs Index Scan) zaman kaybettiğini detaylıca raporlar.

Veritabanı Bölümleme (Partitioning) Stratejileri

Çok büyük tablolarda (milyonlarca satır), veriyi fiziksel olarak daha küçük parçalara bölmek, okuma ve yazma işlemlerini hızlandırır. Bu işleme "Partitioning" denir. Özellikle zaman serisi verilerinde (loglar, finansal işlemler) tarih bazlı bölümleme en etkili yöntemdir.

PostgreSQL ile Tablo Bölümleme Örneği

Aşağıdaki örnekte, siparişler tablosunu aylık bölümlere ayıran bir yapı oluşturulmuştur:

-- Ana tabloyu oluşturma
CREATE TABLE siparisler (
    id SERIAL,
    tarih TIMESTAMP NOT NULL,
    tutar DECIMAL
) PARTITION BY RANGE (tarih);

-- Ocak ayı bölümü
CREATE TABLE siparisler_2023_01 PARTITION OF siparisler
    FOR VALUES FROM ('2023-01-01') TO ('2023-02-01');

-- Şubat ayı bölümü
CREATE TABLE siparisler_2023_02 PARTITION OF siparisler
    FOR VALUES FROM ('2023-02-01') TO ('2023-03-01');

Bu mimari sayesinde veritabanı, sorgu tarihine göre sadece ilgili bölüme (partition) odaklanır ve tüm tabloyu taramak yerine çok daha küçük bir veri setini işler. Bu da sistemin ölçeklenebilirliğini doğrudan artırır.

Veritabanı Bağlantı Yönetimi ve Hata Ayıklama

Uygulama tarafında veritabanı bağlantılarının düzgün yönetilmemesi, "Too many connections" hatasına ve sistemin kilitlenmesine yol açar. Bağlantı havuzu (Connection Pooling) kullanırken, bağlantıların "timeout" sürelerini ve maksimum bağlantı sayılarını doğru ayarlamak kritiktir.

• Connection Leak (Bağlantı Sızıntısı): Açılan bağlantıların kapatılmaması durumudur. Her zaman try-finally veya using blokları ile bağlantıların serbest bırakıldığından emin olun.
• Deadlock (Kilitlenme): İki farklı işlemin birbirinin kilitlediği satırlara erişmeye çalışmasıdır. İşlemlerinizi her zaman aynı tablo sırasıyla yapmaya özen gösterin.

# Python/SQLAlchemy ile güvenli bağlantı kullanımı
from sqlalchemy import create_engine

engine = create_engine(
    "postgresql://user:pass@localhost/db",
    pool_size=10,
    max_overflow=20,
    pool_timeout=30
)

# Bağlantıyı her zaman context manager ile yönetin
with engine.connect() as connection:
    result = connection.execute("SELECT * FROM kullanicilar")
    # İşlem bittiğinde bağlantı otomatik havuza döner

Sonuç

SQL & Veritabanı ile veri saklama mimarisi, uygulamanızın temel taşıdır. Doğru normalizasyon, stratejik indeksleme ve güvenlik odaklı yaklaşımlar ile sürdürülebilir bir sistem inşa edebilirsiniz. Bu rehberde öğrendiğiniz adımları kendi projelerinizde uygulayarak, veritabanı performansınızı ve güvenliğinizi bir üst seviyeye taşıyabilirsiniz. Bir sonraki adım olarak, veritabanı replikasyonu ve "Read/Write Splitting" (Okuma/Yazma ayrımı) konularını araştırarak mimarinizi daha da ölçeklenebilir hale getirebilirsiniz.