Katman · 01
OLTP
İşlem veritabanı
PostgreSQL, MySQL, MariaDB. Çok sayıda küçük okuma/yazma; satır odaklı, indekse dayalı. ACID garantisi ve düşük gecikme bu katmanın özüdür.
Veritabanı kararları çoğu zaman geri alması en pahalı kararlardır — yanlış indeks bir gece düzelir, yanlış şema ya da yanlış replikasyon modeli aylar boyunca tarafınızı tutar. Bu sayfada OLTP ile OLAP'in dengesinden replikasyon biçimlerine, PITR ile snapshot ayrımından indeks ve bağlantı havuzuna kadar veri katmanı kararlarınızı sadeleştirmek için temel kavramları topladık.
Çoğu sistemde dört farklı iş yükü iç içe geçer: ürün sayfası gibi sıcak sorgular, raporlama ve panoda toplanan analitik sorgular, oturum/önbellek gibi geçici veriler ve dosya/medya. Hepsini tek bir motorda yaşatmaya çalışmak en hızlı katmanı en yavaşına bağlar — ayrı yapıya, ayrı motor, ayrı bütçe.
PostgreSQL, MySQL, MariaDB. Çok sayıda küçük okuma/yazma; satır odaklı, indekse dayalı. ACID garantisi ve düşük gecikme bu katmanın özüdür.
ClickHouse, DuckDB, BigQuery. Az sayıda ama çok büyük tarama; sütun odaklı sıkıştırma, paralel okuma. Pano ve raporlama için OLTP'yi rahatlatır.
Redis, Memcached, Valkey. Oturum, rate limit, hesaplaması pahalı sorgu sonuçları. Kalıcılık değil hız öncelik; TTL ile invalidasyon stratejisi şarttır.
S3 uyumlu kovalar, MinIO. Görsel, video, yedek, log arşivi. Sınırsıza yakın ölçek, düşük maliyet; düşük POSIX uyumu — disk gibi değil API gibi düşünün.
Tek bir veritabanı sunucusu, bir gece donanım arızasında tüm uygulamayı götürür. Replikasyon bunun ilk savunma hattıdır: bir primary, bir veya daha çok replika. Asıl soru replikalar arası senkronizasyonun ne kadar sıkı olduğudur — sıkılık tutarlılığı artırır, yazma gecikmesini de.
Replikasyon yüksek erişilebilirlik (HA) için tek başına yeterli değildir; failover orkestrasyonu (patroni, pg_auto_failover, MySQL Group Replication, MariaDB MaxScale) ve sağlam bir oy çoğunluğu mekanizması ister.
# asenkron — yazma onayı primary'den döner
client → primary ──WAL──▶ replica₁ (gecikmeli)
│ ──WAL──▶ replica₂ (gecikmeli)
▼
ack ↑ veri kaybı riski (RPO > 0)
# senkron — en az 1 replika onayı beklenir
client → primary ══WAL══▶ replica₁ (eşzamanlı)
│ ──WAL──▶ replica₂
▼
ack ↑ RPO = 0, yazma latency ↑
# failover
primary düşer → election → replica₁ promote → uygulama yeniden yönlenirYedekleme stratejisinin asıl ölçütü restore'dur. Yedeğin diskte durduğunu görmek değil, gerçek bir veritabanını dakikalar içinde geri ayağa kaldırabildiğinizi bilmek değer üretir. Aksi hâlde elinizde bir umut vardır, plan değil. Daha geniş yedekleme stratejisi (3-2-1, RPO/RTO) için Yedekleme & Felaket Kurtarma.
Point-in-time recovery, "dün 14:32:08 öncesine dönmek" demektir. Temel bir tam yedek + WAL/binlog arşivi sayesinde geriye doğru herhangi bir saniyeye geri sarabilirsiniz; özellikle "yanlış DELETE" gibi insan hatalarında hayat kurtarır.
pg_dump, mysqldump ile SQL ya da özel formatta dışa aktarım. Sürümler arası taşımak kolaydır ama büyük veritabanlarında restore yavaştır.
pgBackRest, Percona XtraBackup ile veri dosyalarının kopyası. Büyük veride hızlı restore ve PITR için temeldir; sürüm uyumluluğu daha sıkıdır.
PITR'nin atom yakıtı. Sürekli akışta arşivlenen WAL (Postgres) ya da binlog (MySQL) sayesinde son tam yedekten herhangi bir saniyeye ilerleme mümkün olur.
# aylık restore tatbikatı — yalnızca dosya boyutuna güvenmeyin
1. en son tam yedeği farklı bir sunucuya indir
2. WAL arşivini hedef zamana kadar oynat
3. checksum & row count doğrulamasını çalıştır
4. örnek 3 sorgu ile veri tutarlılığını gözle
5. RTO ölçümünü kaydet — gerçek değer hep tahminden uzundur
# 3-2-1-1-0 kuralı
3 kopya · 2 farklı medya · 1 dış konum · 1 çevrimdışı · 0 doğrulama hatasıYavaş üretim ortamlarının en yaygın sebebi donanım değil, indekssiz tarama ile artan iş yüküdür. İndeks koymak ücretsiz değil — yazma maliyetini ve disk alanını artırır — ama doğru yere konulduğunda binlerce satır taramayı tek bir aramaya indirir. EXPLAIN çıktısı en güvenilir rehberdir.
WHERE, ORDER BY ve birleşik anahtarlar için. Sütun sırası önemlidir: en seçici alan başta olsun.CREATE INDEX … WHERE status = 'active' gibi. Çok büyük tablolarda yalnız sıcak satırları indeksleyerek hem disk hem yazma maliyetini düşürür.INCLUDE(...) ile ek sütunlar eklenir; planlayıcı satıra hiç dönmez. Sık görüntülenen liste sorgularında dramatik hız artışı sağlar.tsvector), JSONB içi sorgular ve dizi kesişimi için. MySQL'de FULLTEXT karşılığıdır.JOIN'lardır. Bağlantı havuzu (PgBouncer, ProxySQL) ise on binlerce kısa ömürlü bağlantıyı az sayıda kalıcı bağlantıya çevirir; bunsuz Postgres uzun süre dayanamaz. İkisi de izleme olmadan farkına varılmayan kayıplardır.
Snapshot, aynı depolama altyapısında alınan anlık disk görüntüsüdür; donanım kaybında veriyle birlikte gider. Yedek, başka medyada ve tercihen başka coğrafyada saklanan bağımsız kopyadır. Snapshot hız, yedek dayanıklılık verir — biri diğerinin yerini tutmaz.
ACID ilişkisel veritabanlarının verdiği güçlü garantidir: işlem ya tam biter ya hiç olmamış gibi geri sarılır. BASE dağıtık NoSQL dünyasından gelir — eventual consistency, yüksek erişim, gevşek tutarlılık. Sipariş/ödeme gibi alanlar ACID ister; arama indeksi ya da analitik BASE'le yaşar.
Read replica yalnız okuma trafiğini taşımak için açılan replikadır; failover hedefi olarak yapılandırılmamış olabilir. Hot standby primary'nin yerine geçmeye hazır, replikasyonu gerçek zamanlı izlenen ve düzenli failover tatbikatına giren replikadır. İsmi karıştırılır; rolü ayrıdır.
At-rest disk üzerindeki verinin şifreli durmasıdır (LUKS, TDE); disk çalınırsa veri okunamaz. In-transit ağ üzerindeki iletişimin şifreli olmasıdır (TLS); sniff edilen trafik anlamsız kalır. İkisi farklı tehditleri kapsar — biri diğerini gereksiz kılmaz.
Hot sık erişilen, milisaniyelik gecikmeli, görece pahalı depolamadır (NVMe, standart S3). Cold nadir erişilen, dakikalardan saatlere uzayan geri çağırma süresine sahip ucuz depolamadır (S3 Glacier). Arşiv stratejisinin can damarı bu kademelemedir.
Veritabanı motorlarının resmi dokümantasyonu ve PITR / replikasyon konularında temel referanslar.
Mevcut topolojinizi, yedekleme planınızı ve indeks sağlığınızı masaya yatıralım — RPO/RTO hedeflerinize ulaşan sade bir veri mimarisini birlikte planlayalım.