Veritabanı Barındırma için En İyi VPS: İş Yükünüze Uygun Yapıyı Seçin

İki veritabanı aynı disk alanını kullanıp farklı VPS yapıları gerektirebilir. Biri az sayıda satırı tekrar okur; diğeri sürekli yazar, büyük indeksler oluşturur veya arızadan hızlı dönmelidir. En iyi veritabanı VPS'sini seçmek, sağlayıcı karşılaştırmasından önce bu farklarla başlar.

Yönetilmeyen VPS alırken veritabanını işletme sorumluluğunu da alırsınız. PostgreSQL, MySQL ve MariaDB farklı bellek bütçeleri ister; kurtarma kapasitesi ana sunucuyla birlikte tasarlanmalıdır. Başlangıç yapısı yedekleme ve bakım için pay bırakmalı, temsili yük testini geçmelidir.

Plan Seçmeden Önce Veritabanı Yükünü Boyutlandırın

CPU, RAM ve diskten önce etkin veri ve indeksleri, zirvedeki eşzamanlı sorguları, büyümeyi ve kurtarma gereksinimlerini ölçün. Kaynağı ölçülen kısıta göre artırın. Paylaşılan sunucuda bakım alanını ve uygulama zirvesini ekleyin; bütçe yoğun ve olağan dönemleri karşılamalıdır.

Çalışma kümesi, bellekte kalmaktan yararlanacak sıklıkta erişilen veri ve indekslerdir. Depolanan boyut soğuk kayıtları da içerir. Açık bağlantılar etkin sorgu değildir: boşta istemciler ve eşzamanlı sıralamalar farklı CPU/RAM ister. İkisini, sorgu biçimini ve okuma/yazma oranını kaydedin.

Satın alma koşullarını temsili yoğun dönemden çıkarın:

• VPS paylaşılacaksa uygulamanın en yüksek belleğini ölçün.
• Veri ve indeks boyutunu, tahmini çalışma kümesini, eşzamanlı işleri ve planlanan kapasite dönemindeki büyümeyi kaydedin.
• Günlük üretimini ve beklenen en büyük indeks oluşturma, tablo yeniden yazma veya bakım işlemini ölçün.
• p95 gecikme hedefini, kabul edilebilir veri kaybını ve geri yükleme süresini belirleyin.
• Uygulamanın yerini seçin ve veritabanına giden yolu test edin.

PostgreSQL'in izleme belgeleri, veritabanı istatistiklerini işletim sistemi araçlarıyla birleştirmeyi önerir. CPU, bellek baskısı ve disk etkinliğini sorgu ve commit süreleriyle ölçün. Boşta sunucu iyi görünse bile yedek sırasında artan gecikmeyi inceleyin.

Ayrılmış vCPU, tahsis edilen CPU'ya sürekli erişim sağlar; tüm fiziksel sunucu veya IOPS garantisi değildir. CPU, RAM ve depolamayı ayrı değerlendirin. Ölçülen ihtiyaçlar VPS seçeneklerini aşarsa büyük plan adına bakarak tahmin yürütmek yerine ayrılmış donanımı inceleyin.

SQL Yükünü Başlangıç Yapısıyla Eşleştirin

Uyumluluğa göre PostgreSQL 16, InnoDB ile MySQL 8.4 veya InnoDB ile MariaDB 11.4'ü alternatif örnek ortamlar olarak kullanın. Motorlar birbirinin yerine geçmez ve en güncel sürüm iddiası değildir. Testten önce kurulu yama sürümünü kaydedin; örnekler sağlayıcı imaj sürümünü belirtmez.

Küçük Uygulama ve Veritabanını Birlikte Barındırın

3 GB veri, 1 GB sıcak küme ve beş etkin basit indeksli sorgu varsayımıyla 2 vCPU, 4 GB RAM ve nominal 60 GB SSD/NVMe test edin. Bağlantı yereldir, ancak uygulama ve veritabanı ortak zirve bellek bütçesine sığmalıdır.

90/10 okuma/yazma, aylık 1 GB büyüme ve yedek sırasında uzun rapor olmamasını varsayın. Paylaşılan CPU, toleranslı hazırlık ortamına yetebilir. Sürekli kaynak rekabeti yanıtları bozuyorsa ayrılmış seçin; sonraki üretim karşılaştırması yalnızca ayrılmış vCPU kullanır.

Önerilen RAM dağılımı; tüm değerler GB:

MySQL/MariaDB InnoDB havuzunu bu sınıra sığdırın. Ayrılmış veritabanı yüzdesini tüm sunucuya uygulamak uygulamanın RAM'ini tüketir. PostgreSQL'de paylaşılan tamponları ve işlem belleğini veritabanı payı ve rezervinde ayrı hesaplayın. Her iki seçeneği kabul etmeden birleşik zirveyi ölçün.

Disk örneği: OS/günlük 5 GB, veri/indeks 3 GB, motor günlükleri 4 GB, geçici alan 3 GB ve büyüme 6 GB; toplam 21 GB. Nominal kalan, dosya sistemi gideri ve geçici işleri karşılar; yedekleri ana sunucuda tutma gerekçesi değildir.

Yerel soket veya localhost kullanın. Uygulama ve yedek aktifken dayanıklı commitleri, OS'den kalıcı diske yazmasını isteyen senkronizasyonu (fsync) da test edin. Sorumlu 24 saatlik RPO, yani veri kaybı penceresi, ve dört saatlik RTO, yani kurtarma hedefi kabul ediyorsa düğüm dışına gece yerel motor yedeği önerin ve süreyi tatbikatta kanıtlayın. RAM, gecikme veya kurtarma bütçesi tutmazsa sorgu/indeks teşhisinden sonra ayırın, büyütün veya tasarımı değiştirin.

İşlemsel SQL Veritabanını Ayırın

Uygulama başka yerdeyse örnek 12 GB SQL verisi ve 6 GB sıcak küme, 2 ayrılmış vCPU, 16 GB sınıfı RAM ve 50 GB sınıfı yerel diskte teste başlayabilir. 20 etkin indeksli sorgu, kısa yazma ve düşük sürekli hesaplama varsayılır; ağır işlemler bütçeyi geçersiz kılabilir.

Üç ay boyunca aylık 1 GB büyüme ve 90/10 okuma/yazma varsayın. Sağlayıcı tablosunun referansı budur. Birimler değiştiğinden tahsis öncesi gerçek kullanılabilir RAM ve dosya sistemi baytlarını karşılaştırın.

PostgreSQL VPS için PostgreSQL 16'nın paylaşılan tampon rehberi, en az 1 GB RAM'li ayrılmış veritabanında sistem belleğinin %25'inden başlar. OS önbelleği de kullanılır. 16 GB önerisi: 4 GB tampon, 2 GB OS/ajan, 2 GB sorgu/bağlantı/bakım rezervi, 8 GB dosya önbelleği/pay.

Rezerv bir work_mem ayarı değildir. PostgreSQL'in sorgu işlem belleği belgeleri, ayrı sıralama ve hashlerin çoklu oturumlarda ayrı RAM ayırabildiğini açıklar. Hashler ayrıca hash_mem_multiplier kullanır. İzin verilen eşzamanlı işe göre sınır koyun; işlem başına yüksek değer yeterli tampon olsa bile sunucuyu aşabilir.

MySQL VPS için Oracle'ın MySQL 8.4 tampon havuzu rehberi, OS ve diğer payları hesaba katarak genellikle %50–75 RAM önerir. 8 GB InnoDB test edin; kalanı diğer tüketimler ve zirvelere bırakın.

MariaDB farklı hesap ister. Bellek tahsis rehberi, ağırlıklı InnoDB'de OS/hizmetlerden kalan RAM'in %60–70'inden başlar. 13 GB kalıyorsa 7,8–9,1 GB eder; 8 GB başlangıç uygundur. MyISAM veya Aria ayrı önbellek ister. Motor bütçeleri alternatiftir, toplamayın.

Disk: 12 GB veri/indeks + 3 GB büyüme + 5 GB OS + 4 GB günlük + 8 GB geçici/bakım = 32 GB. 50 GB sınıfı disk, giderlerden önce yaklaşık 18 GB nominal pay bırakır. En az 15 GB ölçülen boşluk isteyin; fazla günlük veya büyük yeniden yazmalar örneği geçersiz kılar.

Uygulama ve veritabanını yakın, destekleniyorsa test edilmiş özel yol, kimlik doğrulama, erişim kontrolü ve şifrelemeyle bağlayın. Checkpoint, flush ve yedekte sorgu/kalıcı commit gecikmesini ölçün. Bağımsız yedek alanı ayırın; aşağıdaki örnek detaylandırır. Sorgu/indeks teşhisi sonrası kaynak doyarsa, boşluk yetmezse veya kurtarma hedefi tutmazsa büyütün.

Büyük Çalışma Kümeleri veya Sürekli Yazma için Bütçe Ayırın

100 GB veri ve 16 GB sıcak küme varsayımıyla ayrı uygulama, 4 ayrılmış vCPU, 32 GB RAM ve 300 GB sınıfı NVMe test edin. 30 etkin karma sorgu ve 60/40 okuma/yazma varsayılır; artıştan önce yürütme ve disk baskısını ölçün.

Üç ay aylık 10 GB büyüme varsayın. PostgreSQL: 8 GB tampon, 4 GB OS/sorgu/bakım ve 20 GB dosya önbelleği/pay. MySQL/MariaDB için diğer tüketimler ayrıldıktan sonra yaklaşık 16 GB InnoDB alternatiftir. PostgreSQL ayarlarını diğer motorlara aktarmayın.

Disk devam eden işi içerir: 100 GB veri/indeks + 30 GB büyüme + 30 GB saklanan/bekleyen günlük + 60 GB en büyük geçici/bakım işlemi + 10 GB OS = 230 GB. Yaklaşık 70 GB nominal kalır. Daha büyük tablo yeniden yazımı, günlük büyüme küçük olsa da yeniden hesap ister.

PostgreSQL'in rutin vacuum belgeleri, ölü satır alanını kullanılabilir yapan VACUUM ile yeni tablo kopyası yazıp geçici ek alan isteyen VACUUM FULL'u ayırır. Veriden az büyük disk, alan kazandıracak bakımı engelleyebilir.

CPU yürütme, önbellek baskısı ve fiziksel I/O'yu yazma gecikmesinden ayrı ölçün. Geçici yazmaları, checkpoint/flush dönemlerini katın. NVMe ve ayrılmış CPU yapı tanımıdır, IOPS garantisi değildir. Yakın özel bağlantı ve bağımsız kurtarma alanıyla sürekli yedek/çoğaltma aktarımını test edin. Hızlı günlük üretimi saklama ve ağ ihtiyacını değiştirir. Çekirdek, RAM veya diski gözlenen kısıta göre artırın; sonraki plan hepsini artırdığı için değil.

Üretime Kurtarma Kapasitesi Ekleyin

15 dakikalık kayıp ve bir saatlik geri yükleme hedefi ana bütçenin ötesini ister. Ayrı SQL varsayımlarını koruyup motor yedekleri, saklanan günlükler, bağımsız alan ve zamanlı tatbikat ekleyin. Bunlar planlama hedefidir; yalnızca tatbikat doğrular.

PostgreSQL'in sürekli arşivleme belgeleri, temel yedek ve kesintisiz WAL ile zamana dönük kurtarmayı anlatır. Oracle'ın MySQL kurtarma belgeleri, tam yedek sonrası ikili günlük kullanır. MariaDB'nin PITR işlemi, ikili günlük tekrarından önce tam/artımlı veriyi yükler. Bu MySQL/MariaDB akışları için ikili günlük etkin olmalıdır.

Kapasite örneği: her sıkıştırılmamış tam/temel yedek 12 GB. Üç haftalık temel ve en eskisinin başlangıcından itibaren kesintisiz günlükleri tutun. Günde 2 GB ile 21 güne kadar günlük ve %20 pay hesaplayın:

(3 × 12 + 21 × 2) × 1.2 = 93.6 GB

Sıkıştırma varsaymadan en az 100 GB bağımsız yedek alanı planlayın. Günlük silmeyi yedek sonlanması ve başarılı yenilenmeye bağlayın. Vaat edilen her nokta için tam temel/günlük zincirini doğrulayın.

Ana sunucudan ayrı erişim bilgileri ve silme denetimleriyle bağımsız hedefe yedekler kullanın. Sağlayıcı anlık görüntüsü bu zinciri kanıtlamaz. Tatbikat temiz hedef sağlamalı, yedeği taşıyıp yüklemeli, günlükleri uygulamalı, veri/app tutarlılığını kontrol edip uygulamayı yönlendirmelidir. Sağlama ve aktarım süresini de ölçün.

Daha kısa kesinti tüm yükü kaldıran bağımsız replika isteyebilir. CPU, RAM ve diski ayrı bütçeleyin; yükseltme, eski ana sunucuyu yalıtma ve istemci yönlendirmesini belirleyin. Sırayı prova edin. Çoğaltma yedek değildir; tek VPS yüksek erişilebilirlik değildir. Kurtarma bir saati aşarsa, arşiv gecikmesi RPO'yu geçerse, yedek sunucu yükü kaldıramazsa veya alan dolarsa yeniden tasarlayın.

Yönetilen VPS Ne Zaman Seçilmeli?

Alarma yanıt verecek veya olayda geri yükleyecek kimse yoksa açık operasyon kapsamı satın alın. Yönetilen VPS bakım aktarabilir, ancak sözleşme veritabanı görevlerini saymalıdır. Panel kapsam garantisi değildir; yönetilen VPS ve veritabanı farklıdır.

Yönetilen ve yönetilmeyen VPS sorumlulukları farkı görev düzeyinde yararlıdır. Listeyi satın alma denetimi olarak görün, tüm hizmetlere aynı kapsam sözü değil. Fiziksel altyapı sağlayıcıda kalır; konuk yazılım ve veritabanı açık sorumlu ister.

Yararlı sözleşme sorusu: ‘Yedekte disk dolarsa kim teşhis eder, hizmeti geri getirir ve sonraki yedeği kontrol eder?’ Yanıt destek erişimini sonuç sorumluluğundan ayırır. Başarısız motor yükseltmesi ve yanlışlıkla silme için de sorun.

Yönetilen veritabanlarının motor yaşam döngüsü, yedek ve yük devretme anlaşmaları vardır. Kurtarma ve yükseltmeyi aktarmak istiyorsanız daha uygun olabilir. İsimden uygulama ayarı çıkarmayın; aksi belirtilmedikçe sorgu tasarımı ve uygulama davranışı sorumlu ister.

Her işi bir kez, eskalasyon ve kabul kontrolüyle atayın. Fiyatı zamanınız ve erişilebilirliğinizle karşılaştırın. Öz yönetimin evrensel saat değeri yoktur; ucuz hesaplama sahipsiz olayı çözmez.

SQL Dışı Yükler için VPS Seçin

Örnekler bellek, belge ve arama indeksini ayırır. Uygulamayı yakın tutup bağlantı ve kullanılan yedek/replika aktarımlarını test edin.

Redis'in yönetim rehberi, yazma ağırlıklı RDB kaydı/AOF yeniden yazımının değişen sayfalara göre normal belleğin iki katını kullanabileceğini belirtir. 2 GB veri tüm RAM'i tüketemez. Kalıcılık belgeleri dönemsel RDB görüntüsü ve AOF günlüğünü ayırır. Kabul edilen kayba göre seçip çalışırken RAM/disk zirvesini ölçün.

MongoDB'nin WiredTiger önbellek belgeleri iç ve dosya önbelleğini anlatır. Varsayılan, %50 × (RAM − 1 GB) ile 0,256 GB'den büyük olandır. Replika kümesi rehberi üç veri taşıyan üye önerir. Hakem oy verir ama veri tutmaz. Bağımsız yedek ayırın ve uygulamadan önce MongoDB kimlik doğrulamasını etkinleştirin.

Elastic'in JVM ayar belgeleri otomatik heap önerir. Elle ayarlarsanız minimum/maksimumu eşitleyip kullanılabilir RAM'in %50'sini aşmayın. Küçük küme dayanıklılık rehberi, veri taşıyan ve master olabilen iki düğüm ile yalnızca oy veren hakemi anlatır. Replika kurup istemciyi veri düğümlerine yönlendirin; hakem oy ekler, kopya değil. Birleştirme/saklama disk rezervini tüketirse yeni belgeden önce bütçeyi düzeltin.

Gereken Yapı için Yönetilmeyen Planları Karşılaştırın

Ayrı işlemsel SQL için en az 2 ayrılmış vCPU, 16 GB sınıfı RAM ve 50 GB yerel disk arayın. Asgariyi geçen yalnızca test adayıdır. Farklı CPU/disk paketleri, birimler ve faturalama taahhütleri donanım eşitliği veya performans sıralaması sağlamaz.

Referans: Almanya veya yakın Orta Avrupa'da az veri, daha çok RAM'li öz yönetimli Linux. Yakınlık eşit gecikme demek değildir. Destekleniyorsa özel yol; fiyatlarda standart genel IPv4 korunur. Aktarımın tüm kotaların altında olduğunu varsayın.

DigitalOcean seçim belgeleri Memory-Optimized'ı SQL/NoSQL ve önbellek için sayar. Küçük disk ve yüksek RAM ihtiyacına bu paketi öneririm. Bellek optimizasyonu yalnız SQL demek değildir. Ölçüm depolama kapasitesi veya sürekli depolama talebini kısıt gösteriyorsa Storage-Optimized'ı ayrı değerlendirin.

Beşi de farklı fazla CPU/diskle asgariyi karşılar. Pay büyümeyi destekleyebilir ama testsiz hız üstünlüğü göstermez. Hetzner listesi sipariş stoku garantisi değildir. Akamai G7 Dedicated için SSD belirtir. Vultr Optimized Memory, paylaşılan High Frequency Compute'dan ayrıdır.

Ayrılmış kaynaklarımız gösterilen fiyatta öz yönetim yapısına uyar. Toplam değer öncesi kaynak, para birimi, fatura taahhüdü ve IPv4 ücretlerini karşılaştırın.

Toplam sahiplik: hesaplama + adres + bağımsız yedek alanı/istek/aktarım + kurtarma test kapasitesi + isteğe bağlı yedek sunucu. Bilinmeyen ücret sıfır değildir. Güncel kurtarma fiyatını alın; taahhütten önce plan, konum ve yükseltme yolunu doğrulayın. Yuvarlanmış aylık eşdeğeri çarparak yıllık fatura çıkarmayın.

Uyumlu SQL motoru seçilince tek tık uygulamalarımız kurulumu kısaltır. PostgreSQL, MySQL ve MariaDB ayrı seçimlerdir; biri üçünü kurmaz. Yama, ayar ve kurtarma sorumluluğu sizde kalır.

SSS

PostgreSQL Önbellek İsabet Oranı Yavaş Diski Gösterir mi?

Hayır. PostgreSQL'in I/O istatistik belgeleri, OS önbelleğinin diske gitmeden okumayı karşılayabileceğini açıklar. İsabeti OS I/O ve sorgu süreleriyle değerlendirin. Oran tek başına fiziksel disk gecikmesini çekirdek belleğinden okumadan ayıramaz.

Mantıksal PostgreSQL Dökümü WAL Tabanlı Zamansal Kurtarmada Kullanılır mı?

Hayır. PostgreSQL'in sürekli arşivleme gereksinimleri, mantıksal dökümün WAL tekrarı için bilgi içermediğini belirtir. Döküm alınan durumu yükler; WAL kurtarma uygun temel yedek ve sürekli WAL arşivi ister. Biçimi kurtarma yöntemine göre seçin.

Konteynerde MongoDB Önbelleği Sunucu RAM'ini Kullanmalı mı?

Konteynere açık belleği kullanın. MongoDB'nin konteyner bellek rehberi, WiredTiger'ın daha düşük sınırı bazen dikkate almadığını söyler. Diğer işlemlere pay bırakarak önbelleği sınır altında tutun; toplam host RAM'i kullanılabilir belleği fazla gösterebilir.