Veritabanı Donanım Boyutlandırma: CPU, RAM, NVMe, RAID ve IOPS
PostgreSQL, MySQL, SQL Server, Oracle, MongoDB ve MariaDB için CPU, RAM, NVMe/SSD, RAID, storage latency, IOPS, NUMA ve sanallaştırma sizing yaklaşımını öğrenin.
Bu rehber neyi çözer?
Database sunucusu boyutlandırma ürün datasheet’inden değil gerçek workload ölçümünden başlamalıdır. CPU, RAM ve storage birbirinin açığını sınırsız kapatamaz.
CPU sizing
OLTP sistemlerinde yüksek clock speed ve düşük query latency; analitik workload’larda core sayısı ve parallelism daha belirleyici olabilir.
CPU utilization yanında run queue, query CPU time, context switching, NUMA ve virtualization steal/ready time izlenmelidir.
RAM sizing
Amaç aktif data/index working set’inin mümkün olduğunca memory/cache içinde tutulmasıdır. PostgreSQL OS cache/shared_buffers, MySQL/MariaDB InnoDB buffer pool, SQL Server buffer pool ve MongoDB cache davranışları farklıdır.
Swap/paging production database için ciddi performans problemi yaratabilir.
Storage latency ve IOPS
Database storage seçiminde yalnız MB/s değil random IOPS, p95/p99 latency, queue depth ve fsync/write durability önemlidir.
NVMe özellikle log/journal/temp ve yüksek random I/O workload’larında büyük avantaj sağlar.
RAID ve redundancy
RAID10 transaction workload’larında performans + redundancy dengesi nedeniyle sık değerlendirilir; RAID5/6 write penalty ve rebuild etkisi workload’a göre analiz edilmelidir.
RAID backup değildir ve storage controller cache mutlaka power-loss korumalı olmalıdır.
Sanallaştırma
VM üzerinde database başarılı çalışabilir; CPU overcommit, NUMA alignment, ballooning, shared storage contention ve noisy-neighbor etkileri kontrol edilmelidir.
Critical database VM’lerinde kaynak rezervasyonu ve storage QoS ihtiyacı değerlendirilebilir.
Sık Sorulan Sorular
Database için kaç core gerekir?
Sabit formül yoktur. Query concurrency, CPU time ve lisanslama modeli ölçülerek sizing yapılmalıdır.
RAID10 her zaman gerekli mi?
Hayır. Workload, storage teknolojisi, cloud altyapısı ve redundancy modeli farklı olabilir; write-heavy sistemlerde sık tercih edilir.
Database sanal makinede yavaş olur mu?
Doğru kaynak ve storage tasarımıyla fiziksele çok yakın sonuç alınabilir; overcommit ve shared contention kontrol edilmelidir.
Veritabanı Altyapınızı Birlikte Değerlendirelim
Workload, güvenlik, donanım, HA ve yedekleme gereksinimlerinize göre altyapıyı birlikte planlayabiliriz.