Ölçekleme kararını önce yük tipine göre ayırın
Bir veritabanı yavaşladığında ilk soru “kaç CPU lazım?” değildir. İlk soru yükün ne olduğudur: okuma mı arttı, yazma mı arttı, bağlantı mı doldu, disk mi büyüdü, analitik sorgular mı OLTP trafiğini eziyor?
Okuma yükü artıyorsa replica veya cache işe yarayabilir. Yazma yükü artıyorsa indeks maliyeti, transaction süresi, partitioning veya shard tasarımı konuşulur. Analitik sorgular büyüyorsa OLTP motorunu zorlamak yerine ClickHouse gibi ayrı bir okuma modeli kurmak daha doğru olabilir.
- CPU yüksekliği tek başına ölçek gerekçesi değildir.
- Bağlantı limiti doluyorsa önce pool ve uygulama davranışı incelenir.
- Okuma ve yazma yükü ayrı ölçülmeden replica kararı verilmez.
- Analitik yük büyüyorsa ayrı OLAP motoru çoğu zaman daha temiz çözümdür.
Motorların ölçekleme refleksi farklıdır
PostgreSQL ve MySQL güçlü OLTP motorlarıdır; doğru indeks, kısa transaction, connection pool ve read replica ile uzun süre taşınabilirler. Ama write-heavy tek tablo büyümesi veya çok büyük tenant uçurumları varsa modelleme kararı gerekir.
MongoDB doküman modeliyle yatay büyümeyi daha erken gündeme getirebilir; fakat shard key yanlış seçilirse büyüme rahatlama değil yeni dar boğaz üretir. Redis tarafında ölçek çoğu zaman bellek, hot key ve network davranışıdır. ClickHouse ise zaten büyük okuma için tasarlanmıştır; ama shard/replica ve MergeTree tasarımı doğru değilse donanım eklemek yetmez.
Kullanım örneği: e-ticaret trafiği büyüyor
Bir e-ticaret sisteminde sipariş ve ödeme PostgreSQL veya MySQL’de kalabilir. Sepet, kampanya ve oturum için Redis kullanılabilir. Ürün görüntüleme, arama davranışı ve gelir panoları ClickHouse’a akıtılabilir.
Bu senaryoda tek veritabanını büyütmek yerine yükleri ayırmak daha sağlıklıdır. Ödeme akışında tutarlılık, cache tarafında düşük gecikme, analitik tarafta yüksek hacimli tarama gerekir. Her ihtiyacı aynı motora yüklemek ölçek değil karmaşa üretir.
Motor bazlı yük ayrımı
PostgreSQL/MySQL: sipariş, ödeme, stok hareketi, kullanıcı hesabı Redis: sepet özeti, oturum, kampanya cache, kısa süreli kilitler ClickHouse: ürün görüntüleme eventleri, funnel, satış panoları MongoDB: esnek katalog içeriği veya doküman bazlı ürün detayları
TürkDB burada neyi sadeleştirmeli?
Çok motorlu mimaride zorluk yalnızca motor seçmek değildir. Her motorun bağlantısı, yedeği, kapasitesi, olay geçmişi, maliyeti ve erişim modeli ayrı takip edilirse ekip bir süre sonra veritabanı işletmekten ürün geliştiremez hale gelir.
TürkDB’nin çözmek istediği nokta bu operasyon dağınıklığıdır: farklı motorları aynı kontrol diliyle izlemek, kapasite sinyallerini görünür kılmak, yedek ve erişim süreçlerini düzenlemek, ölçek kararını maliyet ve riskle birlikte okumak.