Bedste VPS til databasehosting: vælg efter din arbejdsbelastning

To databaser kan fylde lige meget og kræve forskellige VPS-opsætninger. Den ene læser få rækker igen og igen; den anden skriver vedvarende, bygger store indeks eller skal gendannes hurtigt efter fejl. Valget begynder med disse forskelle, før udbyderne sammenlignes.

En selvadministreret VPS indebærer ansvar for databasedriften. PostgreSQL, MySQL og MariaDB kræver forskellige hukommelsesbudgetter; gendannelseskapacitet skal planlægges sammen med primærserveren. Startopsætningen skal have plads til backup og vedligeholdelse og bestå en repræsentativ belastningstest.

Dimensionér databasebelastningen før abonnementsvalget

Mål aktive data og indeks, samtidige forespørgsler ved spidsbelastning, vækst og gendannelseskrav før CPU, RAM og disk vælges. Tilføj ressourcer efter den målte begrænsning. Medregn vedligeholdelsesplads og applikationens spidsforbrug ved delt vært; budgettet skal dække både travlhed og normal drift.

Arbejdssættet er data og indeks, der bruges så ofte, at RAM-lagring hjælper. Lagret størrelse omfatter også kolde data. Åbne forbindelser er heller ikke aktive forespørgsler: inaktive klienter og samtidige sorteringer kræver forskellig CPU og RAM. Registrér begge, forespørgselstype og læse-/skrivefordeling.

Udled købskrav af en repræsentativ travl periode:

• Mål applikationens maksimale RAM-forbrug, hvis den deler VPS.
• Registrér data-/indeksstørrelse, anslået arbejdssæt, samtidige operationer og vækst i den planlagte kapacitetsperiode.
• Mål logproduktion og find den største forventede indeksopbygning, tabelomskrivning eller vedligeholdelse.
• Fastlæg p95-latensmål, acceptabelt datatab og mål for gendannelsestid.
• Vælg applikationsplacering og test forbindelsen til databasen.

PostgreSQLs overvågningsdokumentation anbefaler databasestatistik sammen med operativsystemværktøjer. Mål CPU, hukommelsespres og diskaktivitet sammen med forespørgsels- og committider. Undersøg øget latens under backup, selv hvis en tomgangstest ser fin ud.

Dedikerede vCPU'er giver vedvarende adgang til tildelt CPU. De er ikke en hel fysisk server eller en IOPS-garanti. Vurdér CPU, RAM og lageradfærd separat. Overstiger målte krav VPS-mulighederne, undersøg dedikeret hardware frem for at slutte ud fra navnet på et større abonnement.

Match SQL-belastning med en startopsætning

Brug PostgreSQL 16, MySQL 8.4 med InnoDB eller MariaDB 11.4 med InnoDB som alternative miljøer efter kompatibilitet. De er ikke udskiftelige motorer eller påstande om seneste version. Notér installeret patchversion før test; eksemplerne angiver ikke udbyderens imageversion.

Placér lille applikation og database sammen

Ved antaget 3 GB database, 1 GB varmt sæt og fem aktive enkle indekserede forespørgsler testes 2 vCPU'er, 4 GB RAM og 60 GB nominel SSD eller NVMe. Forbindelsen er lokal, men begge skal passe i fælles RAM-spidsbudget.

Antag 90/10 læsning/skrivning, 1 GB månedlig vækst og ingen lange rapporter under backup. Delt CPU kan fungere til tolerant staging. Vælg dedikeret tildeling ved vedvarende konkurrence og dårlige svartider; produktionssammenligningen bruger kun dedikerede vCPU'er.

Foreslået RAM-fordeling, alle tal i GB:

Tilpas InnoDB-poolen i MySQL/MariaDB til budgettet. En procent for dedikeret database anvendt på hele værten vil bruge applikationens RAM. For PostgreSQL tælles delte buffere og operationshukommelse separat i databasebudget og reserve. Mål samlet spidsforbrug før godkendelse af hver mulighed.

Diskeksempel: 5 GB OS/log, 3 GB data/indeks, 4 GB motorlog, 3 GB midlertidigt og 6 GB vækst, i alt 21 GB. Resten dækker filsystemoverhead og midlertidigt arbejde, ikke backupopbevaring på primærserveren.

Forbind via lokal socket eller localhost. Test holdbare commits med aktiv app og backup, inklusive synkronisering (fsync), der beder OS skrive til varigt lager. Accepteres RPO på 24 timer som datatabsvindue og RTO på fire timer som gendannelsesmål, foreslå natlig native backup uden for noden og bevis tiden ved øvelse. Ved overskredet RAM-, latens- eller gendannelsesbudget: adskil, opskalér eller revidér efter forespørgsels-/indeksdiagnose.

Adskil en transaktionel SQL-database

Med ekstern applikation kan et eksempel på 12 GB SQL-data og 6 GB varmt sæt starte test på 2 dedikerede vCPU'er, cirka 16 GB RAM og 50 GB lokalt lager. Det antager 20 aktive indekserede forespørgsler, korte skrivninger og lav vedvarende beregning; større operationer kan sprænge budgettet.

Antag 90/10 læsning/skrivning og 1 GB månedlig vækst over tre måneder. Dette er udbydertabellens reference. Enheder varierer: sammenlign faktisk tilgængelig RAM og brugbare filsystembytes før budgettering.

For PostgreSQL-VPS starter PostgreSQL 16s vejledning om delte buffere ved 25% systemhukommelse på dedikeret databasevært med mindst 1 GB RAM. OS-cache bruges også. Forslag på 16 GB: 4 GB delte buffere, 2 GB OS/agenter, 2 GB forespørgsels-/forbindelses-/vedligeholdelsesreserve og 8 GB filcache/frirum.

Reserven er ikke en work_mem-indstilling. PostgreSQLs dokumentation om forespørgselsoperationers hukommelse beskriver, at separate sorteringer og hashes hver kan tildele RAM under samtidige sessioner. Hashes bruger også hash_mem_multiplier. Begræns efter tilladt samtidighed; høje værdier pr. operation kan overskride værten trods nok delte buffere.

Til MySQL-VPS anbefaler Oracles MySQL-8.4-bufferpoolvejledning normalt 50–75% RAM med hensyn til OS og andre tildelinger. Test 8 GB InnoDB og behold resten til andre forbrugere og spidser.

MariaDB kræver en anden beregning. Dets vejledning om hukommelsestildeling starter ved 60–70% tilgængelig RAM efter OS/tjenester for overvejende InnoDB. Ved 13 GB er det 7,8–9,1 GB; 8 GB passer som start. MyISAM eller Aria kræver separat cache. Motorbudgetterne er alternativer: læg dem ikke sammen.

Disk: 12 GB data/indeks + 3 GB vækst + 5 GB OS + 4 GB log + 8 GB midlertidigt/vedligeholdelse = 32 GB. En 50-GB-disk giver cirka 18 GB nominelt før overhead. Kræv mindst 15 GB målt fri plads; flere logs eller større omskrivninger ugyldiggør eksemplet.

Placér app og database tæt med testet privat forbindelse hvor muligt, autentificering, adgangskontrol og kryptering. Test forespørgsels- og holdbar commitlatens under checkpoints, flush og backup. Afsæt uafhængigt backuplager; næste eksempel uddyber det. Opskalér ved mættede ressourcer, for lidt plads eller fejlede gendannelsesmål efter query-/indeksdiagnose.

Budgettér større arbejdssæt eller vedvarende skrivning

For antaget 100 GB data og 16 GB varmt sæt testes 4 dedikerede vCPU'er, 32 GB RAM og cirka 300 GB NVMe med separat app. Eksemplet tillader 30 aktive blandede forespørgsler og 60/40 læsning/skrivning; mål udførelse og lagerpres før udvidelse.

Antag 10 GB vækst månedligt i tre måneder. PostgreSQL: 8 GB delte buffere, 4 GB OS/query/vedligeholdelse og 20 GB filcache/frirum. For MySQL/MariaDB er cirka 16 GB InnoDB et alternativ efter øvrige reserver. PostgreSQL-indstillinger kan ikke overføres direkte.

Lager omfatter igangværende arbejde: 100 GB data/indeks + 30 GB vækst + 30 GB gemte/ventende logs + 60 GB største midlertidige/vedligeholdelsesopgave + 10 GB OS = 230 GB. Cirka 70 GB nominelt er tilbage. Større tabelomskrivning kræver ny beregning selv ved beskeden daglig vækst.

PostgreSQLs dokumentation om rutinemæssig vacuum skelner mellem VACUUM, der gør døde rækkers plads genbrugelig, og VACUUM FULL, der skriver ny tabelkopi og midlertidigt kræver ekstra plads. En disk kun lidt større end datasættet kan forhindre nødvendig pladsfrigørende vedligeholdelse.

Mål CPU, cachepres og fysisk I/O separat fra skrivelatens. Medtag midlertidige skrivninger og checkpoint-/flushperioder. NVMe og dedikeret CPU er konfiguration, ikke IOPS-garanti. Test vedvarende backup-/replikationstransfer med nærliggende privat forbindelse og uafhængig gendannelse. Hurtigere logs ændrer opbevaring og netværk. Øg kerner, RAM eller disk efter observeret begrænsning, ikke fordi næste abonnement øger alt.

Tilføj gendannelseskapacitet til produktion

15 minutters accepteret tab og en times gendannelse kræver mere end primærbudgettet. Behold separate SQL-antagelser og tilføj native backup, gemte logs, uafhængigt lager og tidsmålt øvelse. Det er planlægningsmål; kun øvelsen viser, om de nås.

PostgreSQLs dokumentation om kontinuerlig arkivering beskriver basisbackup og ubrudt WAL-arkiv til tidspunktgendannelse. Oracles MySQL-gendannelsesdokumentation bruger fuld backup efterfulgt af binære logs. MariaDBs PITR-procedure gendanner fulde/inkrementelle data før binær logafspilning. Aktivér binær logging til disse MySQL/MariaDB-forløb.

Kapacitetseksempel: hver ukomprimeret fuld/basisbackup er 12 GB. Gem tre ugentlige baser og kontinuerlige logs fra starten af den ældste. Budgettér op til 21 dage med 2 GB dagligt plus 20% margen:

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

Planlæg mindst 100 GB uafhængig backupplads uden antaget komprimering. Knyt logsletning til udløb og vellykket erstatning af backup. Kontrollér komplet kæde for hvert lovet gendannelsespunkt.

Brug backup på et uafhængigt mål med separate legitimationsoplysninger og sletterettigheder. Udbydersnapshot alene beviser ikke kæden. Øvelsen skal oprette rent mål, overføre/gendanne, afspille logs, kontrollere database-/appkonsistens og dirigere appen. Mål også klargøring og overførsel.

Kortere nedetid kan kræve uafhængig replika til hele belastningen. Budgettér CPU, RAM og disk separat; definér promovering, afskærmning af gammel primær og klientrouting. Øv rækkefølgen. Replikation erstatter ikke backup, og én VPS er ikke høj tilgængelighed. Revidér ved over en times gendannelse, arkivforsinkelse over RPO, utilstrækkelig standby eller næsten fuldt backuplager.

Hvornår skal du vælge administreret VPS?

Kan ingen reagere på alarmer eller gendanne under hændelser, køb klart defineret driftsdækning. Administreret VPS kan overtage vedligeholdelse, men kontrakten skal navngive databaseopgaver. Kontrolpanel beviser ikke dækning; administreret VPS og database er forskellige tjenester.

Forskellen mellem ansvar ved administreret og selvadministreret VPS er nyttig pr. opgave. Brug listen ved indkøb, ikke som løfte om ens tjenester. Fysisk infrastruktur er fortsat udbyderens ansvar; gæstesoftware og databasedrift kræver eksplicit ejerskab.

Nyttigt kontraktspørgsmål: ‘Hvis disken bliver fuld under backup, hvem diagnosticerer, gendanner tjenesten og kontrollerer næste backup?’ Svaret adskiller supportadgang fra resultatansvar. Spørg også til mislykket motoropgradering og utilsigtet sletning.

Administrerede databaser har egne aftaler om motorlivscyklus, backup og failover. De kan passe bedre, hvis gendannelse og opgradering skal overdrages. Udled ikke applikationsoptimering af navnet; forespørgselsdesign og appadfærd kræver stadig ejer, medmindre andet er aftalt.

Tildel hver opgave én gang med eskalation og acceptkontrol. Sammenlign pris med din tid og tilgængelighed. Selvdrift har ingen universel timepris; billig CPU løser ikke en hændelse uden ansvarlig.

Vælg VPS til ikke-SQL-belastninger

Eksemplerne skelner mellem hukommelse, dokumenter og søgeindeksering. Placér appen tæt og test forbindelser samt overførsler til backup og eventuelle replikaer.

Redis' administrationsvejledning advarer om, at skrivetunge RDB-lagringer eller AOF-omskrivninger kan bruge dobbelt normal RAM afhængigt af ændrede sider. Datasættet på 2 GB må derfor ikke fylde al hukommelse. Persistensdokumentationen skelner mellem periodiske RDB-snapshots og AOF-log. Vælg efter acceptabelt tab og mål RAM-/diskspidser under kørsel.

MongoDBs WiredTiger-cachedokumentation beskriver intern cache og filcache. Standard er største værdi af 50% × (RAM − 1 GB) og 0,256 GB. Replica-set-vejledningen anbefaler tre databærende medlemmer. Arbiter stemmer uden data. Afsæt uafhængig backup og indfør MongoDB-autentificering før tilslutning af appen.

Elastics JVM-indstillingsdokumentation anbefaler automatisk heapstørrelse. Manuelt bruges samme minimum/maksimum og højst 50% ledig RAM. Vejledningen om små klyngers modstandsdygtighed beskriver to databærende, masteregnede knuder plus ren stemmeafgører. Konfigurér replikaer og klientrouting til dataknuder; afgøreren tilføjer en stemme, ikke en kopi. Revidér diskbudget ved udtømt merge-/opbevaringsreserve før flere dokumenter.

Sammenlign selvadministrerede abonnementer til din opsætning

Filtrér separat transaktionel SQL på mindst 2 dedikerede vCPU'er, cirka 16 GB RAM og 50 GB lokalt. Bestået minimum gør kun til testkandidat. Forskellige CPU-/diskpakker, enheder og betalingsbindinger forhindrer hardwarelighed eller præstationsrangering.

Reference: selvadministreret Linux i Tyskland eller nært Centraleuropa med få data og mere RAM. Nærhed garanterer ikke ens latens. Privat forbindelse hvor understøttet; tilbud beholder standard offentlig IPv4. Antag trafik under alle kvoter.

DigitalOceans valgvejledning nævner Memory-Optimized til SQL/NoSQL og cache. Jeg anbefaler pakken til lidt disk og meget RAM. Hukommelsesoptimeret VPS er ikke kun SQL. Viser måling lagerkapacitet eller vedvarende lagerbehov som begrænsning, vurder Storage-Optimized separat.

Alle fem opfylder minimum med forskellige CPU-/diskreserver. De kan støtte vækst, men beviser ikke hurtigere database uden test. Hetzners liste garanterer ikke bestillingslager. Akamai dokumenterer SSD til G7 Dedicated. Vultrs Optimized Memory er adskilt fra delt High Frequency Compute.

Vores dedikerede tildeling passer til selvdrift til viste pris. Sammenlign ressourcer, valuta, betalingsbinding og IPv4 før samlet værdivurdering.

Ejerskabspris: compute + adresse + uafhængig backupplads/anmodninger/transfer + gendannelsestestkapacitet + valgfri standby. Ukendte gebyrer er ikke nul. Indhent aktuelle gendannelsespriser og kontrollér abonnement, sted og opgraderingsvej før binding. Udled ikke årsregning af et afrundet månedsbeløb.

Efter valg af kompatibel SQL-motor forkorter vores etklikapps installationen. PostgreSQL, MySQL og MariaDB vælges separat; ét valg installerer ikke alle tre. Patches, optimering og gendannelse forbliver dit ansvar.

Ofte stillede spørgsmål

Viser PostgreSQLs cachetræfrate langsomt lager?

Nej. PostgreSQLs I/O-statistikdokumentation forklarer, at OS-cache kan levere læsning uden diskadgang. Kombinér træfrate med OS-I/O og forespørgselstider. Raten alene skelner ikke fysisk forsinkelse fra læsning af kernehukommelse.

Kan et logisk PostgreSQL-dump bruges til WAL-baseret tidspunktgendannelse?

Nej. PostgreSQLs krav til kontinuerlig arkivering siger, at logiske dumps mangler data til WAL-afspilning. Dump gendanner indfanget tilstand; WAL-gendannelse kræver egnet basisbackup og kontinuerligt arkiveret WAL. Vælg format efter gendannelsesmetode.

Skal MongoDB-cache bruge værts-RAM i en container?

Brug containerens tilgængelige hukommelse. MongoDBs vejledning om containerhukommelse advarer om, at WiredTiger nogle gange overser en lavere containergrænse. Hold cache under grænsen med plads til andre processer; samlet værts-RAM kan overvurdere det tilgængelige.