Legjobb VPS adatbázisokhoz: válasszon a terheléséhez illő rendszert

Két adatbázis ugyanannyi lemezt használhat, mégis más VPS-t igényelhet. Az egyik kevés sort olvas ismételten, a másik folyamatosan ír, nagy indexeket épít vagy gyors helyreállítást kíván. A választás ezekkel a különbségekkel kezdődik, a szolgáltatók összevetése előtt.

Nem menedzselt VPS-nél az adatbázis üzemeltetése is az Ön felelőssége. A PostgreSQL, MySQL és MariaDB eltérő memóriakeretet igényel; a helyreállítást az elsődleges szerverrel együtt kell tervezni. A kezdő rendszer hagyjon tartalékot mentésre és karbantartásra, majd teljesítsen reprezentatív terheléstesztet.

Csomagválasztás előtt mérje fel a terhelést

CPU, RAM és lemez előtt mérje az aktív adatokat/indexeket, csúcsidei párhuzamos lekérdezéseket, növekedést és helyreállítást. A mért korláthoz adjon erőforrást. Számoljon karbantartási hellyel és közös gépen az alkalmazás csúcsával; a keret bírja a csúcsot és a normál üzemet.

A munkakészlet a RAM-ban tartásból profitáló, gyakran elért adat és index. A tárolt méret hideg adatot is tartalmaz. Nyitott kapcsolat nem aktív lekérdezés: tétlen kliens és párhuzamos rendezés más CPU-t és RAM-ot kíván. Mérje mindkettőt, a lekérdezés jellegét és az olvasás/írás arányát.

Reprezentatív forgalmas időszakból vezesse le a vásárlási igényeket:

• Mérje az alkalmazás memóriacsúcsát, ha megosztja a VPS-t.
• Rögzítse az adat/index méretét, becsült munkakészletet, párhuzamos műveleteket és a tervezett időszak növekedését.
• Mérje a naplóképzést és a legnagyobb várható indexépítést, táblaátírást vagy karbantartást.
• Határozza meg a p95 késleltetést, megengedett adatvesztést és helyreállítási időt.
• Válassza ki az alkalmazás helyét és tesztelje az adatbázishoz vezető utat.

A PostgreSQL monitorozási dokumentációja adatbázis-statisztikát és operációsrendszer-eszközöket javasol együtt. Mérjen CPU-t, memórianyomást és lemezaktivitást a lekérdezés- és commitidőkkel. A mentés alatti késleltetésnövekedést akkor is vizsgálja, ha a tétlen szerver jól teljesít.

A dedikált vCPU folyamatos hozzáférést ad a kiosztott CPU-hoz, nem egész fizikai szervert vagy IOPS-garanciát. Értékelje külön a CPU-t, RAM-ot és tárolóviselkedést. Ha a mért igény meghaladja a VPS-kínálatot, dedikált hardvert vizsgáljon, ne nagyobb csomagnévből következtessen.

Párosítsa az SQL-terhelést kezdő konfigurációval

Kompatibilitás szerint PostgreSQL 16, InnoDB-s MySQL 8.4 vagy InnoDB-s MariaDB 11.4 legyen az alternatív példakörnyezet. Nem felcserélhető motorok, és nem a legfrissebb verzió állítása. Teszt előtt jegyezze fel a javítási verziót; a példák nem adják meg a szolgáltatói lemezkép verzióját.

Kis alkalmazás és adatbázis közös gépen

Feltételezett 3 GB adat, 1 GB forró készlet és öt aktív egyszerű indexelt lekérdezés esetén teszteljen 2 vCPU-t, 4 GB RAM-ot és névleges 60 GB SSD/NVMe-t. A kapcsolat helyi, de mindkettő férjen a közös memóriacsúcsba.

Feltételezzen 90/10 olvasás/írást, havi 1 GB növekedést és hosszú riportok nélkül mentést. Megosztott CPU elég lehet toleráns tesztkörnyezetnek. Tartós versengés miatti rossz válasznál dedikáltat válasszon; a későbbi éles csomagok csak dedikált vCPU-t használnak.

Javasolt RAM-keret, minden szám GB:

Illessze a MySQL/MariaDB InnoDB-poolját e keretbe. Dedikált adatbázis százalékát az egész gépre alkalmazva elfogy az alkalmazás RAM-ja. PostgreSQL-nél külön számoljon megosztott pufferekkel és műveleti memóriával az adatbázis keretében/tartalékában. Mindkét lehetőség előtt mérje a közös csúcsot.

Lemezpélda: 5 GB OS/napló, 3 GB adat/index, 4 GB motornapló, 3 GB ideiglenes és 6 GB növekedés, összesen 21 GB. A névleges maradék fájlrendszer-többletre és átmeneti munkára kell, nem indokol mentéstartást az elsődlegesen.

Helyi socket vagy localhost legyen a kapcsolat. Aktív alkalmazás és mentés mellett tesztelje a tartós commitot, a szinkronizálással (fsync) együtt, amely tartós tárolóra írást kér az OS-től. Ha a tulajdonos 24 órás RPO-t, azaz veszteségi ablakot és négyórás RTO-t, azaz helyreállítási célt fogad el, javasoljon éjszakai natív mentést másik csomópontra, és gyakorlattal bizonyítsa az időt. RAM-, késleltetési vagy helyreállítási túllépésnél lekérdezés/index diagnózis után válasszon szét, méretezzen vagy tervezzen újra.

Külön tranzakciós SQL-adatbázis

Távoli alkalmazásnál a példa 12 GB SQL és 6 GB forró készlet tesztje indulhat 2 dedikált vCPU-n, 16 GB-osztályú RAM-mal és 50 GB-osztályú helyi lemezzel. Ez 20 aktív indexelt lekérdezést, rövid írásokat és kevés folyamatos számítást feltételez; nagy művelet felboríthatja.

Három hónapig havi 1 GB növekedést és 90/10 olvasás/írást feltételezzen. Ez a szolgáltatói táblázat referenciája. Eltérő egységeknél a valóban elérhető RAM-ot és használható fájlrendszerbájtokat hasonlítsa össze.

PostgreSQL VPS esetén a PostgreSQL 16 megosztottpuffer-útmutatója legalább 1 GB RAM-os dedikált adatbázisnál a rendszermemória 25%-áról indul. OS-cache is kell. A 16 GB-os javaslat: 4 GB puffer, 2 GB OS/ügynök, 2 GB lekérdezés/kapcsolat/karbantartás és 8 GB fájlcache/tartalék.

A tartalék nem work_mem-beállítás. A PostgreSQL lekérdezésműveleti memória dokumentációja szerint külön rendezések és hashek párhuzamos munkameneteknél külön RAM-ot foglalhatnak. A hashek hash_mem_multiplier-t is használnak. A megengedett párhuzamosság alapján korlátozzon; nagy műveletenkénti érték megfelelő pufferekkel is túllépheti a gépet.

MySQL VPS-hez az Oracle MySQL-8.4-pufferpool-útmutatója általában 50–75% RAM-ot javasol az OS és egyéb kiosztások figyelembevételével. Teszteljen 8 GB InnoDB-t, a maradékot más fogyasztóknak és csúcsoknak hagyva.

MariaDB-nél más számítás kell. A memóriakiosztási útmutató főleg InnoDB-nél az OS/szolgáltatások után elérhető RAM 60–70%-áról indul. 13 GB-nál ez 7,8–9,1 GB; a kezdő 8 GB megfelel. MyISAM vagy Aria külön cache-t igényel. Ezek alternatív motoronkénti keretek, ne adja össze őket.

Lemez: 12 GB adat/index + 3 GB növekedés + 5 GB OS + 4 GB napló + 8 GB ideiglenes/karbantartás = 32 GB. Az 50 GB-osztály kb. 18 GB névleges helyet hagy a többlet előtt. Legalább 15 GB mért szabad hely kell; nagyobb naplók/átírások érvénytelenítik a példát.

Legyen közel alkalmazás és adatbázis, tesztelt privát útvonallal, ha támogatott, hitelesítéssel, jogosultsággal és titkosítással. Ellenőrizze lekérdezés és tartós commit késleltetését checkpoint, flush és mentés alatt. Tervezzen független mentést; az alábbi példa kibontja. Diagnózis után telítettség, helyhiány vagy sikertelen helyreállítás esetén növeljen.

Nagy munkakészlet vagy tartós írás tervezése

Feltételezett 100 GB adat és 16 GB forró készlet esetén teszteljen 4 dedikált vCPU-t, 32 GB RAM-ot és 300 GB-osztályú NVMe-t külön alkalmazással. A példa 30 aktív vegyes lekérdezést és 60/40 olvasás/írást enged; bővítés előtt mérjen CPU-t és tárolónyomást.

Három hónapig havi 10 GB növekedést feltételezzen. PostgreSQL: 8 GB puffer, 4 GB OS/lekérdezés/karbantartás és 20 GB fájlcache/tartalék. MySQL/MariaDB-nél kb. 16 GB InnoDB alternatíva más tartalékok után. PostgreSQL-beállítást ne másoljon át.

A lemez tartalmazza az aktív munkát: 100 GB adat/index + 30 GB növekedés + 30 GB őrzött/várakozó napló + 60 GB legnagyobb ideiglenes/karbantartási művelet + 10 GB OS = 230 GB. Kb. 70 GB névleges marad. Nagyobb táblaátírást szerény napi növekedésnél is újra kell számolni.

A PostgreSQL rutin vacuum dokumentációja megkülönbözteti az elhalt sorok helyét újrahasznosíthatóvá tevő VACUUM-ot a VACUUM FULL-tól, amely új táblapéldányt ír és ideiglenes pluszhelyet kér. Alig nagyobb lemez megakadályozhatja a helyfelszabadító karbantartást.

CPU-t, cache-nyomást és fizikai I/O-t külön mérjen az írási késleltetéstől. Vegye bele az ideiglenes írást és checkpoint/flush időszakot. NVMe és dedikált CPU leírás, nem IOPS-garancia. Teszteljen tartós mentési/replikációs átvitelt közeli privát kapcsolattal és független tárolóval. Gyorsabb naplók változtatják a megőrzést és hálózatot. Magot, RAM-ot vagy lemezt a korlát szerint növeljen, ne mert a következő csomag mindet emeli.

Helyreállítási kapacitás az éles rendszerhez

15 perc megengedett veszteség és egyórás helyreállítás több az elsődleges keretnél. Tartsa meg a külön SQL-feltételezéseket, adjon natív mentést, naplókat, független tárolót és időmért gyakorlatot. Ezek tervezési célok, csak a gyakorlat igazolhatja őket.

A PostgreSQL folyamatos archiválási dokumentációja alapmentést és megszakítatlan WAL-t ír le időpontra állításhoz. Az Oracle MySQL-helyreállítási dokumentációja teljes mentést és bináris naplókat használ. A MariaDB PITR-eljárása teljes/növekményes adatot állít vissza a naplóvisszajátszás előtt. E MySQL/MariaDB-eljárásokhoz engedélyezze a bináris naplózást.

Példa: minden tömörítetlen teljes/alapmentés 12 GB. Őrizzen három heti alapot és folytonos naplókat a legrégebbi kezdetétől. Legfeljebb 21 nappal, napi 2 GB-bal és 20% tartalékkal számoljon:

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

Legalább 100 GB független mentést tervezzen tömörítés feltételezése nélkül. Naplót mentéslejárathoz és sikeres pótláshoz kötve töröljön. Minden ígért ponthoz ellenőrizze a teljes láncot.

Használjon független célra mentést az elsődlegestől külön hitelesítőkkel és törlési jogokkal. Szolgáltatói pillanatkép önmagában nem bizonyítja a natív láncot. A gyakorlat hozzon létre tiszta célt, vigye át/állítsa vissza a mentést, játssza vissza a naplókat, ellenőrizze adatbázis/app egyezését és irányítsa át az appot. A létrehozást és átvitelt is mérje.

Rövidebb leállás független, teljes terhelést bíró replikát igényelhet. CPU, RAM és lemez külön kell; határozza meg előléptetést, régi elsődleges kizárását és kliensútvonalat. Gyakorolja. Replikáció nem mentés, egy VPS nem magas rendelkezésre állás. Tervezzen újra egy órán túli helyreállítás, RPO-t túllépő naplókésés, gyenge standby vagy betelő mentés esetén.

Mikor válasszon menedzselt VPS-t?

Ha nincs, aki riasztásra reagál vagy visszaállít, vegyen pontos üzemeltetési lefedettséget. Menedzselt VPS átvehet karbantartást, de a szerződés nevezze meg a feladatokat. Vezérlőpanel nem bizonyítja ezt; menedzselt VPS és adatbázis eltérő szolgáltatás.

A menedzselt és nem menedzselt VPS feladatai közti eltérés feladatonként hasznos. Ez beszerzési lista, nem egységes szolgáltatásígéret. Fizikai infrastruktúra a szolgáltatóé; vendégszoftver és adatbázis egyértelmű felelőst kér.

Hasznos szerződéses kérdés: „Ha mentés közben betelik a lemez, ki diagnosztizál, állít helyre és ellenőrzi a következő mentést?” Ez elválasztja támogatás elérését az eredményfelelősségtől. Kérdezze hibás frissítésre és véletlen törlésre is.

Menedzselt adatbázisnak saját életciklus-, mentési és átállási megállapodása van. Jobb lehet, ha helyreállítást és frissítést adna át. Ne következtessen apphangolásra a névből; lekérdezés és appviselkedés továbbra is felelőst kér, ha nincs más megállapodás.

Minden feladatot egyszer osszon ki eszkalációval és átvételi ellenőrzéssel. Hasonlítsa árát idejéhez és elérhetőségéhez. Önálló kezelésnek nincs univerzális óradíja; olcsó gép nem old meg gazdátlan incidenst.

VPS választása nem SQL-terheléshez

A példák memóriát, dokumentumot és keresőindexet választanak szét. Legyen közel az app; tesztelje kapcsolatát és a használt mentési/replikaátvitelt.

A Redis adminisztrációs útmutatója szerint írásintenzív RDB-mentés/AOF-átírás a módosult lapok alapján kétszeres RAM-ot is kérhet. A 2 GB adat nem foglalhat el mindent. A tartóssági dokumentáció időszakos RDB-pillanatképet és AOF-naplót különít el. A megengedett veszteség szerint válasszon, futás közben RAM/lemezcsúcsot mérve.

A MongoDB WiredTiger-cache dokumentációja belső és fájlcache-t ír le. Alapérték az 50% × (RAM − 1 GB) és 0,256 GB közül a nagyobb. A replikakészlet-útmutató három adatot tartó tagot javasol. Az arbiter szavaz, adatot nem tart. Tervezzen független mentést és az app előtt MongoDB-hitelesítést.

Az Elastic JVM-beállítási dokumentációja automatikus heapet javasol. Kézzel egyenlő minimum/maximum, legfeljebb az elérhető RAM 50%-a kell. A kis klaszterek ellenállósági útmutatója két adatot tartó, masterképes és egy csak szavazó döntő csomópontot ír le. Állítson replikát és klienskapcsolatot adatcsomópontokra; a döntő szavazatot ad, nem másolatot. Betelő összevonási/megőrzési tartaléknál új dokumentum előtt számolja át a lemezt.

Önállóan kezelt csomagok összehasonlítása

Külön tranzakciós SQL-hez legalább 2 dedikált vCPU, 16 GB-osztályú RAM és 50 GB helyi lemez kell. A minimum teljesítése csak tesztjelöltség. Eltérő csomagok, egységek és fizetési vállalások miatt nincs hardverazonosság vagy teljesítményrangsor.

Referencia: önálló Linux Németországban vagy közeli Közép-Európában, kis adat és több RAM. Közelség nem egyenlő késleltetés. Privát út ahol támogatott; az árak megtartják a szabványos nyilvános IPv4-et. Feltételezett átvitel minden kvóta alatt.

A DigitalOcean választási dokumentációja SQL/NoSQL és cache célra sorolja a Memory-Optimizedot. Kis lemezhez, nagy RAM-hoz ezt ajánlom. Memóriaoptimalizálás nem SQL-kizárólagosság. Ha mérés tárolókapacitást vagy tartós lemezigényt mutat korlátnak, a Storage-Optimizedot külön értékelje.

Mind az öt teljesíti a minimumot eltérő CPU/lemez tartalékkal. Ez segítheti a növekedést, de teszt nélkül nem bizonyít sebességelőnyt. Hetzner-lista nem készletgarancia. Akamai SSD-t ír a G7 Dedicatedhez. Vultr Optimized Memory más, mint a megosztott High Frequency Compute.

Dedikált kiosztásunk megfelel az önálló konfigurációnak a jelzett áron. Teljes érték előtt erőforrást, valutát, számlázási vállalást és IPv4-díjat hasonlítson.

Tulajdonlási költség: számítás + cím + független mentéstároló/kérések/átvitel + helyreállítási tesztkapacitás + opcionális standby. Ismeretlen díj nem nulla. Kérjen aktuális helyreállítási árakat és ellenőrizze a csomagot, helyet és bővítést vállalás előtt. Kerekített havi megfelelőből ne szorozzon éves számlát.

Kompatibilis SQL-motor kiválasztása után egykattintásos appjaink rövidítik a telepítést. PostgreSQL, MySQL és MariaDB külön választás; egy nem telepíti mindhármat. Javítás, hangolás és helyreállítás Önre marad.

Gyakran Ismételt Kérdések

Jelzi a PostgreSQL cache-találati aránya a lassú lemezt?

Nem. A PostgreSQL I/O-statisztikai dokumentációja szerint OS-cache lemez nélkül is kiszolgálhat olvasást. Találati arányt OS-I/O-val és lekérdezésidővel együtt nézzen. Önmagában nem különbözteti meg a fizikai késést a kernelmemóriából olvasástól.

Jó a logikai PostgreSQL-dump WAL-alapú időpont-helyreállításhoz?

Nem. A PostgreSQL folyamatos archiválási feltételei szerint a logikai dumpból hiányzik a WAL-visszajátszás információja. A dump rögzített állapotot állít vissza; WAL-hoz megfelelő alapmentés és folytonos archívum kell. A formátumot a helyreállítási mód szerint válassza.

Használja a MongoDB-cache a gazdagép RAM-ját konténerben?

A konténernek elérhető RAM-ot használja. A MongoDB konténermemória-útmutatója figyelmeztet: WiredTiger néha nem veszi figyelembe a kisebb korlátot. Cache maradjon alatta más folyamatoknak hellyel; az összes host-RAM túlbecsülheti az adatbázis keretét.