Nejlepší VPS pro databáze: vyberte podle své zátěže

Dvě databáze mohou zabírat stejně místa a potřebovat odlišný VPS. Jedna opakovaně čte několik řádků; druhá trvale zapisuje, vytváří velké indexy nebo se musí rychle obnovit po výpadku. Výběr začíná těmito rozdíly, ještě před srovnáním poskytovatelů.

Nespravovaný VPS znamená odpovědnost za provoz databáze. PostgreSQL, MySQL a MariaDB potřebují jiné paměťové rozpočty; kapacitu obnovy plánujte s primárním serverem. Počáteční konfigurace musí mít rezervu na zálohy a údržbu a projít reprezentativním testem.

Změřte databázovou zátěž před výběrem tarifu

Před volbou CPU, RAM a disku změřte aktivní data a indexy, souběžné dotazy ve špičce, růst a požadavky obnovy. Přidávejte zdroje podle naměřeného omezení. Zahrňte místo na údržbu i špičku aplikace při společném hostování; rozpočet musí zvládnout běžný i vytížený provoz.

Pracovní sada zahrnuje často používaná data a indexy, kterým prospívá pobyt v RAM. Uložený objem zahrnuje i studená data. Otevřená spojení nejsou aktivní dotazy: nečinní klienti a souběžná řazení mají jiné nároky. Zaznamenejte obojí, podobu dotazů a poměr čtení/zápisu.

Odvoďte nákupní požadavky z reprezentativního vytíženého období:

• Změřte špičkovou paměť aplikace, bude-li VPS sdílet.
• Zaznamenejte velikost dat/indexů, odhad pracovní sady, souběžné operace a růst v plánovaném horizontu.
• Změřte tvorbu logů a určete největší očekávanou tvorbu indexu, přepis tabulky či údržbu.
• Určete cílovou latenci p95, přijatelnou ztrátu dat a dobu obnovy.
• Rozhodněte o umístění aplikace a otestujte cestu k databázi.

Dokumentace monitorování PostgreSQL doporučuje kombinovat databázové statistiky s nástroji OS. Sledujte CPU, tlak na RAM a disk spolu s časy dotazů a commitů. Nárůst latence při záloze vyžaduje šetření, i když kontrola nečinného serveru vyhoví.

Dedikované vCPU poskytují trvalý přístup k přidělenému CPU. Neznamenají celý fyzický server ani záruku IOPS. CPU, RAM a chování úložiště posuzujte odděleně. Překračují-li změřené požadavky dostupné VPS, zvažte dedikovaný hardware místo odhadů podle názvu většího tarifu.

Přiřaďte zátěži SQL počáteční konfiguraci

Podle kompatibility použijte PostgreSQL 16, MySQL 8.4 s InnoDB nebo MariaDB 11.4 s InnoDB jako alternativní příklady. Motory nejsou zaměnitelné a nejde o tvrzení o nejnovější verzi. Před testem zaznamenejte verzi opravy; příklady neurčují verzi obrazu poskytovatele.

Umístěte malou aplikaci a databázi společně

Při předpokladu 3 GB databáze, 1 GB horké sady a pěti aktivních jednoduchých indexovaných dotazů testujte 2 vCPU, 4 GB RAM a nominálně 60 GB SSD/NVMe. Spojení je místní, ale oba procesy se musejí vejít do společné paměťové špičky.

Předpokládejte čtení/zápis 90/10, růst 1 GB měsíčně a žádné dlouhé reporty při záloze. Sdílené CPU může stačit tolerantnímu stagingu. Při dlouhodobém soupeření a špatné odezvě zvolte dedikované; produkční srovnání níže používá jen dedikované vCPU.

Návrh paměťového rozpočtu, vše v GB:

Pool InnoDB MySQL/MariaDB vměstnejte do tohoto rozpočtu. Procento pro dedikovaný databázový server použité na celý hostitel odebere RAM aplikaci. U PostgreSQL počítejte sdílené buffery a paměť operací odděleně v rámci přídělu a rezervy. Před přijetím kterékoliv varianty změřte společnou špičku.

Příklad disku: 5 GB OS/logy, 3 GB data/indexy, 4 GB logy motoru, 3 GB dočasně a 6 GB růst; celkem 21 GB. Nominální zbytek pokryje režii a přechodnou práci, neospravedlňuje uchovávání záloh na primárním serveru.

Připojte se místním socketem či localhost. Testujte trvalé commity při běhu aplikace a zálohy včetně synchronizace (fsync), jež žádá OS o zápis na trvalé médium. Přijímá-li vlastník RPO 24 hodin jako okno ztráty a RTO čtyři hodiny jako dobu obnovy, navrhněte noční nativní zálohu mimo uzel a dokažte obnovu cvičením. Nesplněnou paměť, latenci či obnovu řešte oddělením, zvětšením nebo úpravou návrhu po diagnostice dotazů/indexů.

Oddělte transakční databázi SQL

Pro vzdálenou aplikaci může příklad 12 GB SQL s 6 GB horké sady začít testovat na 2 dedikovaných vCPU, RAM třídy 16 GB a místním disku třídy 50 GB. Předpokládá 20 aktivních indexovaných dotazů, krátké zápisy a málo trvalých výpočtů; větší operace mohou rozpočet zneplatnit.

Počítejte s 90/10 čtení/zápis a růstem 1 GB měsíčně po tři měsíce. To je reference tabulky. Jednotky se liší: před přidělením porovnejte skutečně dostupnou RAM a použitelné bajty souborového systému.

Pro PostgreSQL VPS začíná doporučení pro sdílené buffery PostgreSQL 16 na 25 % RAM dedikovaného databázového serveru s alespoň 1 GB. PostgreSQL používá i cache OS. Návrh 16 GB: 4 GB buffery, 2 GB OS/agenti, 2 GB rezerva dotazů/spojení/údržby a 8 GB souborová cache/rezerva.

Rezerva není nastavení work_mem. Dokumentace paměti operací dotazu PostgreSQL vysvětluje, že jednotlivá řazení a hashe mohou přidělovat paměť při více souběžných relacích. Hashe používají i hash_mem_multiplier. Limity nastavte podle povoleného souběhu; vysoká paměť na operaci může překročit hostitel i při dostatečných bufferech.

Pro MySQL VPS doporučení buffer poolu MySQL 8.4 Oracle obvykle uvádí 50–75 % RAM s ohledem na OS a jiné příděly. Testujte 8 GB InnoDB, zbytek ponechte ostatním a špičkám.

MariaDB vyžaduje jiný výpočet. Její pokyny k přidělení paměti začínají u převážně InnoDB na 60–70 % RAM po odečtení OS/služeb. Při 13 GB je to 7,8–9,1 GB; start 8 GB vyhovuje. MyISAM či Aria potřebují vlastní cache. Rozpočty motorů jsou alternativy, nesčítejte je.

Disk: 12 GB data/indexy + 3 GB růst + 5 GB OS + 4 GB logy + 8 GB dočasně/údržba = 32 GB. Disk 50 GB ponechá asi 18 GB nominálně před režií. Požadujte nejméně 15 GB změřeného volného místa; více logů nebo přepisů příklad zneplatní.

Umístěte aplikaci blízko databáze s testovanou soukromou cestou, je-li podporována, ověřováním, řízením přístupu a šifrováním. Měřte dotazy a trvalé commity při checkpointu, flushi a záloze. Přidělte nezávislé zálohování; níže je návrh. Po diagnostice zvětšete při saturaci, nedostatku místa či nesplněné obnově.

Plánujte větší pracovní sady či trvalý zápis

Pro předpokládaných 100 GB dat a 16 GB horké sady testujte 4 dedikované vCPU, 32 GB RAM a přibližně 300 GB NVMe s oddělenou aplikací. Příklad připouští 30 aktivních smíšených dotazů a čtení/zápis 60/40; před rozšířením měřte výpočty i úložiště.

Předpokládejte 10 GB růstu měsíčně po tři měsíce. PostgreSQL: 8 GB buffery, 4 GB OS/dotazy/údržba a 20 GB souborová cache/rezerva. MySQL/MariaDB mohou alternativně začít s asi 16 GB InnoDB po ostatních rezervách. Parametry PostgreSQL nepřenášejte.

Disk zahrnuje probíhající práci: 100 GB data/indexy + 30 GB růst + 30 GB uchované/čekající logy + 60 GB největší dočasná/údržbová operace + 10 GB OS = 230 GB. Zůstává asi 70 GB nominálně. Větší přepis vyžaduje přepočet i při malém denním růstu.

Dokumentace běžného vacuum PostgreSQL odlišuje VACUUM, které zpřístupní místo mrtvých řádků, od VACUUM FULL, jež píše novou kopii a dočasně potřebuje další místo. Disk jen o trochu větší než data může zabránit potřebné údržbě.

Měřte CPU, tlak na cache a fyzické I/O odděleně od latence zápisu. Zahrňte dočasné zápisy a checkpoint/flush. NVMe a dedikované CPU jsou popis, ne záruka IOPS. Testujte trvalé přenosy záloh a replikace s blízkým soukromým spojením a nezávislým úložištěm. Rychlejší logy mění retenci i síť. Přidávejte jádra, RAM nebo disk podle omezení, ne protože další tarif zvyšuje vše.

Přidejte kapacitu obnovy pro produkci

Přijatelných 15 minut ztráty a hodinová obnova vyžadují víc než primární rozpočet. Zachovejte samostatné předpoklady SQL a přidejte nativní zálohy, logy, nezávislé úložiště a časované cvičení. Jsou to plánovací cíle; prokáže je jen cvičení.

Dokumentace průběžné archivace PostgreSQL popisuje základní zálohu a nepřerušený archiv WAL pro obnovu v čase. Dokumentace obnovy MySQL Oracle používá plnou zálohu a binární logy. Postup PITR MariaDB obnovuje plná/přírůstková data před přehráním binárních logů. Pro tyto postupy MySQL/MariaDB musí být binární logování zapnuté.

Příklad kapacity: každá nekomprimovaná plná/základní záloha má 12 GB. Uchovávejte tři týdenní základy a souvislé logy od začátku nejstaršího. Počítejte až 21 dní po 2 GB denně a 20% rezervu:

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

Plánujte alespoň 100 GB nezávislého zálohového místa bez předpokladu komprese. Mažte logy podle expirace a úspěšné náhrady záloh. Ověřte úplný řetězec pro každý slíbený bod obnovy.

Použijte zálohy na nezávislém cíli s oddělenými účty a mazacími právy. Snapshot poskytovatele sám nedokládá tento řetězec. Cvičení musí vytvořit čistý cíl, přenést/obnovit, přehrát logy, ověřit konzistenci databáze/aplikace a přesměrovat aplikaci. Měřte i zřízení a přenos.

Kratší výpadek může potřebovat nezávislou repliku pro celou zátěž. CPU, RAM a disk počítejte zvlášť; určete povýšení, odstavení starého primáru a směrování klientů. Nacvičte pořadí. Replikace nenahrazuje zálohy a jeden VPS není vysoká dostupnost. Upravte při obnově přes hodinu, zpoždění archivu nad RPO, slabém standby či plném zálohovém úložišti.

Kdy zvolit spravovaný VPS

Pokud nikdo nereaguje na alarmy ani neobnoví databázi při incidentu, kupte jasně definované provozní krytí. Spravovaný VPS může přenést údržbu, ale smlouva musí jmenovat databázové úkoly. Panel není důkaz; spravovaný VPS a databáze jsou různé služby.

Rozdíl mezi odpovědnostmi spravovaného a nespravovaného VPS pomáhá po úkolech. Jde o nákupní seznam, nikoli slib shodných služeb. Fyzická infrastruktura zůstává poskytovateli; hostovaný software a databáze vyžadují výslovného vlastníka.

Užitečná smluvní otázka: ‚Když při záloze dojde místo, kdo diagnostikuje, obnoví službu a ověří další zálohu?‘ Odděluje přístup k podpoře od odpovědnosti za výsledek. Ptejte se i na neúspěšný upgrade a náhodné smazání.

Spravované databáze mají vlastní dohody o životním cyklu, zálohách a přepnutí. Mohou být lepší, chcete-li předat obnovu a upgrady. Z názvu nevyvozujte ladění aplikace; návrh dotazů a chování aplikace stále potřebují vlastníka, není-li dohodnuto jinak.

Každý úkol přidělte jednou s eskalací a přejímací kontrolou. Porovnejte cenu s časem a dostupností. Vlastní správa nemá univerzální hodinovou hodnotu a levný výkon nevyřeší incident bez odpovědného.

Vyberte VPS pro zátěž mimo SQL

Příklady oddělují paměť, dokumenty a vyhledávací indexy. Přibližte aplikaci a testujte spojení i přenosy záloh a případných replik.

Administrátorský průvodce Redis varuje, že zápisově náročné uložení RDB nebo přepis AOF může podle změněných stránek spotřebovat dvojnásobek běžné RAM. 2 GB dat proto nesmějí zaplnit vše. Dokumentace perzistence odlišuje pravidelné snapshoty RDB od logu AOF. Volte podle přijatelné ztráty a měřte špičky RAM/disku za běhu.

Dokumentace cache WiredTiger MongoDB popisuje vnitřní a souborovou cache. Výchozí je větší z 50 % × (RAM − 1 GB) a 0,256 GB. Pokyny pro replica set doporučují tři datové členy. Arbitr hlasuje, data nemá. Zajistěte nezávislé zálohy a před připojením aplikace nastavte ověřování MongoDB.

Dokumentace JVM Elastic doporučuje automatický heap. Ručně nastavte stejné minimum/maximum a nejvýše 50 % dostupné RAM. Pokyny pro odolnost malých clusterů popisují dva datové uzly způsobilé být masterem a čistě hlasovací rozhodčí uzel. Nastavte repliky a klienty na datové uzly; rozhodčí přidává hlas, ne kopii. Vyčerpá-li slučování/retence rezervu, upravte disk před dalšími dokumenty.

Porovnejte nespravované tarify pro svou konfiguraci

Pro oddělené transakční SQL filtrujte alespoň 2 dedikované vCPU, RAM třídy 16 GB a 50 GB místně. Splněné minimum znamená jen kandidáta k testu. Různé balíčky, jednotky a závazky neumožňují rovnost hardwaru ani výkonnostní žebříček.

Reference: vlastní Linux v Německu či blízké střední Evropě, malá data a více RAM. Blízkost neznamená stejnou latenci. Soukromá cesta, kde podporována; nabídky zahrnují standardní veřejnou IPv4. Předpokládejte přenos pod všemi limity.

Výběrová dokumentace DigitalOcean uvádí Memory-Optimized pro SQL/NoSQL a cache. Doporučuji tento balíček pro malý disk a velkou RAM. Paměťově optimalizovaný VPS není jen SQL. Ukážou-li měření kapacitu či dlouhodobý nárok na disk jako omezení, posuďte Storage-Optimized zvlášť.

Všech pět splňuje minimum s různými rezervami CPU/disku. Mohou podpořit růst, ale bez testu nedokazují rychlejší databázi. Katalog Hetzner nezaručuje sklad. Akamai pro G7 Dedicated uvádí SSD. Vultr Optimized Memory je odlišný od sdíleného High Frequency Compute.

Naše dedikované přidělení odpovídá vlastní správě za uvedenou cenu. Porovnejte zdroje, měnu, závazek účtování a IPv4 před posouzením celkové hodnoty.

Celkové náklady: výkon + adresa + nezávislé zálohové úložiště/požadavky/přenos + kapacita pro test obnovy + volitelný standby. Neznámé poplatky nejsou nula. Získejte aktuální ceny obnovy a ověřte tarif, místo a upgrade před závazkem. Roční fakturu neodvozujte násobením zaokrouhleného měsíčního ekvivalentu.

Po volbě kompatibilního SQL motoru naše aplikace na kliknutí zkrátí instalaci. PostgreSQL, MySQL a MariaDB jsou samostatné volby; jedna neinstaluje všechny. Opravy, ladění a obnova zůstávají na vás.

Často kladené otázky

Ukazuje poměr zásahů cache PostgreSQL pomalé úložiště?

Ne. Dokumentace statistik I/O PostgreSQL vysvětluje, že cache OS může čtení obsloužit bez disku. Kombinujte zásahy s I/O systému a časy dotazů. Poměr sám nerozliší fyzické zpoždění od čtení z paměti jádra.

Lze logický dump PostgreSQL použít pro obnovu v čase přes WAL?

Ne. Požadavky průběžné archivace PostgreSQL uvádějí, že logické dumpy nemají informace pro přehrání WAL. Dump obnoví zachycený stav; WAL obnova vyžaduje vhodný základ a souvislý archiv WAL. Formát volte podle metody obnovy.

Má cache MongoDB v kontejneru používat RAM hostitele?

Použijte paměť dostupnou kontejneru. Pokyny pro paměť kontejnerů MongoDB varují, že WiredTiger někdy nižší limit nezohlední. Nastavte cache pod něj s rezervou pro ostatní procesy; celková RAM hostitele může dostupnou kapacitu nadhodnotit.