Maliyet artışı önce bileşenlere ayrılır
Veritabanı maliyeti tek kalem gibi görünür ama aslında birkaç farklı davranışın toplamıdır: işlem kaynağı, disk, yedek saklama, ağ trafiği, ek replikalar ve operasyonel özellikler. Hepsine aynı anda bakılmazsa yanlış tasarruf yapılabilir.
Örneğin disk büyümesi yedek saklama süresi yüzünden olabilir; CPU artışı kötü bir sorgudan gelebilir; ağ artışı yeni bir raporlama entegrasyonundan doğabilir. Aynı fatura artışı, farklı kök nedenler ister.
- Compute: CPU/RAM ve seçilen makine tierı.
- Depolama: canlı veri, indeksler, WAL/binlog/oplog, ClickHouse partları.
- Yedek: saklama süresi, snapshot sayısı, PITR penceresi.
- Network: uygulama, BI, dış raporlama veya bölge dışı trafik.
- Operasyon: HA, replica, bakım ve güvenlik özellikleri.
İlk soru: kaynak gerçekten kullanılıyor mu?
Büyük makine kötü değildir; gereksiz büyük makine kötüdür. CPU sürekli yüksekse küçültmek risklidir. Ama CPU düşük, bellek düşük, disk sadece retention yüzünden büyüyorsa başka yerden başlamalısınız.
TürkDB tarafında cluster planı ve olay geçmişi, kapasite değişikliklerinin ne zaman yapıldığını görmeye yardım eder. Bu zaman çizgisini trafik ve yayına alma geçmişiyle yan yana koymak gerekir.
Cluster ve kapasite fotoğrafı
turkdb cluster get app-db turkdb cluster events app-db --limit 50 turkdb backup list app-db
Storage artışı veri artışı demek olmayabilir
Disk artışı gördüğünüzde “müşteri büyüdü” diye sevinmeden önce içeriğini anlamak gerekir. PostgreSQL’de bloat veya WAL, MySQL’de binlog, MongoDB’de indeksler, ClickHouse’ta part ve eski partitionlar, Redis’te TTL’siz keyler maliyeti sessizce büyütebilir.
Bu yüzden depolama metriğini motorun kendi iç görünümüyle doğrulamak gerekir. Maliyet optimizasyonu bazen küçültme değil, veri yaşam döngüsünü temizlemektir.
PostgreSQL tablo ve indeks boyutu
SELECT relname, pg_size_pretty(pg_total_relation_size(relid)) AS total_size, pg_size_pretty(pg_relation_size(relid)) AS table_size, pg_size_pretty(pg_indexes_size(relid)) AS index_size FROM pg_catalog.pg_statio_user_tables ORDER BY pg_total_relation_size(relid) DESC LIMIT 20;
ClickHouse büyük tablolar
SELECT database, table, formatReadableSize(sum(bytes_on_disk)) AS disk_size, sum(rows) AS rows FROM system.parts WHERE active GROUP BY database, table ORDER BY sum(bytes_on_disk) DESC LIMIT 20;
Yavaş sorgu maliyet üretir
Performans problemi yalnızca kullanıcıyı bekletmez; faturayı da büyütür. Aynı kötü sorgu günde binlerce kez çalışıyorsa CPU, disk I/O ve önbellek baskısı üretir. Bu yüzden maliyet anomalisinde yavaş sorgu listesine bakmak şaşırtıcı derecede etkilidir.
Buradaki doğru ilişki şudur: Önce gereksiz iş yapan sorguyu azaltın, sonra kapasite kararını verin. Aksi halde verimsizliği daha pahalı bir makinede çalıştırırsınız.
- Raporlama sorguları canlı ortam OLTP üzerinde gereksiz yük yaratıyor mu?
- Pano aynı ağır agregasyonu sürekli tekrar ediyor mu?
- Önbellek hit oranı düştüğü için ana veritabanı daha çok mu okunuyor?
- Yeni indeks depolama maliyeti getirirken gerçekten sorgu maliyetini düşürüyor mu?
Tasarruf kararını riskle birlikte yazın
Maliyet düşürmek güzel; yanlış yerden kısmak pahalıdır. Yedek saklama süresi azaltmak RPO hedefini etkiler, replica kapatmak HA seviyesini değiştirir, tier küçültmek peak saatlerde gecikme yaratabilir.
Bu yüzden her tasarruf önerisinin yanında risk cümlesi olmalıdır. “Şu clusterı küçültelim” değil, “son 30 gün peak CPU %22, p95 stabil, yedek saklama süresi değişmiyor; bir alt tierı mesai dışı deneyip şu metriklerle izleyeceğiz” daha iyi bir karardır.
Maliyet karar notu
Öneri: app-db standard-4 -> standard-2 denemesi Dayanak: 30 gün peak CPU <%35, RAM <%50, p95 stabil Korunanlar: PITR penceresi ve yedek saklama süresi değişmiyor Risk: kampanya trafiğinde CPU sınırı yaklaşabilir Gözlem: 24 saat p95 gecikme, connection errors, CPU, disk I/O Rollback: standard-4'e geri dön