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.
Mimari ve çalışma modeli
Veritabanı donanımı veri boyutuna değil çalışma kümesine, sorguya ve commit yoluna göre seçilir. CPU tek-thread performansı ve paralellik, RAM cache ve çalışma alanı, storage ise log ve veri I/O davranışı üzerinden değerlendirilir. Ortalama IOPS veya disk kapasitesi yoğun saat transaction gecikmesini açıklamayabilir.
- 1Transaction profili
- 2CPU/bellek çalışma kümesi
- 3Log/veri depolaması
- 4Yoğun saat ve büyüme
Tasarım parametreleri
- Çalışma kümesi
- Toplam veri boyutu ile aktif veri/indeks kümesini ayırın; cache hit tek başına sorgu başarısı değildir.
- I/O ve commit
- Random read, checkpoint ve log flush yükünü farklı test edin; IOPS yanında p99 gecikmesini kaydedin.
- İş yükü ve sorgu dağılımı
- Okuma/yazma oranı, bağlantı sayısı, transaction süresi ve yoğun sorguları ölçün. Veritabanı boyutu tek başına donanım gereksinimini açıklamaz.
- Bellek ve depolama
- Çalışma kümesi, günlük yazması, geçici alan ve checkpoint davranışını ayrı inceleyin. Güvenilir yazma garantisi performans kadar önemlidir.
- Kurtarma zinciri
- Başlangıç yedeği, gerekli günlükler, yapılandırma ve anahtarların birlikte geri getirilebildiğini sınayın.
- Erişim ve değişiklik
- Uygulama rolü, yönetici rolü ve schema değişiklik yetkisini ayırın. Üretimde indeks veya parametre değişimini kontrollü yapın.
Hesap ve uygulama örneği
Örnek 1 TB veritabanında aktif çalışma kümesi 80 GB olabilir; bu durum bütün verinin RAM’de bulunması gerektiğini göstermez. Log yazması ve rastgele veri okumasını aynı pilotta fakat ayrı metriklerle ölçün. Yüzde 30 büyüme varsayımını veri, sorgu ve bağlantı sayısı için ayrı uygulayın.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| NVMe var ama transaction yavaş | Commit flush, kilit veya tek thread sınırlayıcı olabilir. | Bekleme türünü log/data I/O ve yürütme planıyla eşleştirin. |
| CPU düşük, sorgu yavaş | Kilit, I/O veya istemci beklemesi baskın olabilir. | Yürütme planını ve bekleme türünü aynı sorgu için inceleyin. |
| Replica bağlı ama verisi eski | Gönderme, uygulama veya transaction beklemesi gerilik yaratabilir. | Son uygulanmış işlem ve kaynağın commit zamanını karşılaştırın. |
| Disk sürekli büyüyor | Günlük tutma, açık transaction, replication slot veya bakım ihtiyacı etkili olabilir. | Ürünün desteklediği istatistikleri inceleyin; günlükleri elle silmeyin. |
Kabul ve doğrulama kontrolleri
- Commit gecikmesi, çalışma kümesi ve büyümeyi disk kapasitesinden ayrı raporlayın.
- Temsilî transactionları ve sorguları gerçek veri dağılımıyla test edin.
- Ayrı hedefe restore yapıp uygulama kayıtlarını doğrulayın.
- Yetkisiz okuma ve schema değişikliği denemelerini test kimliğiyle reddedin.
- Failover sonrasında tek yetkili yazıcı ve doğru bağlantı hedefini doğrulayın.
- Bakım sırasında kilit, günlük hacmi ve gecikme değişimini ölçün.
İlgili kavramlar
IOPS ve blok boyutu
IOPS saniyedeki I/O işlem sayısını, MB/s ise taşınan veri miktarını anlatır. Aynı IOPS sayısı farklı blok boyutlarında çok farklı bant genişliği üretir. Örneğin 10.000 işlem/s × 4 KiB yaklaşık 39,1 MiB/s eder. Okuma/yazma oranı, rastgele veya sıralı erişim ve veri koruma mekanizması sonucu değiştirir. Bir benchmark sonucunu üretim uygulamasına doğrudan taşımak yerine gerçek blok dağılımını ve eşzamanlılığı ölçün. Diskin yüksek IOPS göstermesi, uygulama yanıtının iyi olduğu anlamına gelmez; gecikme de birlikte incelenmelidir.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Kuyruk ve eşzamanlılık
Kuyruk, bir kaynağın işleyebildiğinden daha hızlı gelen işleri tutar. Eşzamanlılığı artırmak belirli bir noktaya kadar kapasite kullanımını yükseltir; sonra bekleme süresini büyütür. Durağan durumda Little yasası L = λ × W ilişkisidir: ortalama sistemdeki iş sayısı, tamamlanan iş hızı ile ortalama toplam sürenin çarpımıdır. Birimler tutarlı olmalıdır. 2.000 işlem/s ve 5 ms toplam süre yaklaşık 10 eşzamanlı iş demektir. Bu ilişki tasarım tahminidir; kuyruk sınırları, ani yük ve çok değişken servis süreleri ayrıca ölçülmelidir.
NUMA yerelliği
NUMA sistemlerde işlemci, kendisine yakın bellekle uzak düğüm belleğine farklı maliyetle erişebilir. Bir sanal makinenin vCPU ve bellek boyutu, fiziksel düğüm kapasitesi ve hypervisor yerleştirmesiyle birlikte değerlendirilir. Daha fazla vCPU vermek her zaman hız kazandırmaz; yerellik kaybı ve zamanlama beklemesi performansı düşürebilir. Fiziksel topolojiyi, VM içindeki görünen topolojiyi ve gerçek iş yükünün bellek davranışını birlikte kaydedin. Değişikliği aynı yük altında önce/sonra karşılaştırın; yalnız CPU yüzdesi yerine uygulama gecikmesini ve uzak bellek etkisini inceleyin.
Yazma dayanımı ve aşınma
SSD seçimi yalnız kapasite ve ilk gün hızına göre yapılmamalıdır. TBW, DWPD, garanti süresi, güç kaybı koruması ve iş yükünün yazma davranışı birlikte değerlendirilir. DWPD hesaplarında üreticinin tanımladığı kapasite ve garanti koşulları esas alınır. Veritabanı logları, küçük rastgele yazmalar ve geçici iş dosyaları aşınmayı farklı etkiler. SMART veya üretici sağlık verisini izleyin; sıcaklık, medya hatası ve kalan dayanım sinyallerini birlikte yorumlayın. Yazma amplifikasyonu nedeniyle uygulamanın yazdığı veri miktarı, NAND üzerindeki yazma miktarıyla aynı olmayabilir.
Kalıcılaştırma ve güç kaybı
Commit edilmiş verinin güç kaybından sonra korunması veritabanı, işletim sistemi, dosya sistemi, kontrolcü ve diskin yazma garantilerinin birleşimine bağlıdır. Yazma önbelleği ve flush davranışını bilmeden performans için güvenlik ayarlarını kapatmayın. Güç kaybı korumalı depolama faydalıdır fakat bütün zincirin doğru yapılandırıldığını tek başına kanıtlamaz. Üretim yerine kontrollü laboratuvarda arıza ve recovery testi yapın. Veri bütünlüğünü örnek dosya açılmasıyla değil, uygulama kayıtları ve desteklenen tutarlılık kontrolleriyle doğrulayın.