Moet een ontwikkelaar databases op de computeknode of de opslagnode bewaren?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Should a Developer Keep Databases on the Compute Node or the Storage Node? - Zima Store Online

Houd actieve databasebestanden standaard op opslag met lage latentie naast de compute en gebruik vervolgens de storage-node voor back-ups, dumps, replica's en archieven.

Die standaard verandert wanneer de storage-node een doelbewust ontworpen block-storagepad, gemeten latentie, de juiste duurzaamheidssemantiek en een herstelvoordeel biedt dat de extra afhankelijkheid rechtvaardigt. De beslissing draait niet simpelweg om lokale versus netwerkcapaciteit: transactielogboeken, databestanden, back-ups, uploads van applicaties en wegwerpdatabases voor tests hebben verschillende schrijfpatronen en gevolgen bij storingen.

Scheid databasestatus van dumps en back-ups

Breng elk databasegerelateerd pad in kaart voordat je een node kiest. De primaire datadirectory en het transactielogboek zijn actieve status; ze vereisen een consistente schrijfvolgorde en voorspelbare latentie. Logische dumps, base-back-ups, gearchiveerde logboeken, exports en door de applicatie geüploade bestanden hebben andere toegangspatronen en kunnen vaak veilig via het netwerk worden opgeslagen.

Mount niet één NAS-share en plaats daar alles in. Houd het actieve databasevolume gescheiden van back-upbestemmingen en bulkgegevens van applicaties. Zo kun je elke rol afzonderlijk afstemmen, monitoren, vullen, snapshotten, herstellen en migreren, zonder te doen alsof alle permanente bytes hetzelfde medium nodig hebben.

Voor kortlevende branchdatabases of CI-tests kan de herbouwtijd belangrijker zijn dan duurzaamheid. Plaats die op snelle lokale scratch-opslag en maak ze opnieuw aan vanuit migraties of geschoonde seeds. Behandel voor de dagelijkse servicedatabase van een ontwikkelaar een defecte lokale SSD als een herstelincident en zorg dat de externe kopie actueel genoeg is om aan het opgegeven herstelpunt te voldoen.

Meet het schrijfpad voordat je een node kiest

Databaseprestaties hangen van meer af dan sequentiële doorvoer. Meet de latentie van synchrone commits, willekeurige lees- en schrijfbewerkingen, de wachtrijdiepte tijdens back-upverkeer en het gedrag wanneer het netwerkpad hapert. Een 10GbE-verbinding kan grote bestanden snel verplaatsen en toch latentie en een extra storingspunt aan elke transactie toevoegen.

Een gepubliceerde PostgreSQL-vergelijking liet zien dat lokale NVMe een lagere en voorspelbaardere latentie leverde dan de geteste cloudservices met netwerkopslag, en wees tegelijkertijd op de voordelen van de elasticiteit en duurzaamheid van netwerkopslag. Die PostgreSQL-benchmarks voor lokale en netwerkgekoppelde opslag vormen geen garantie voor een thuislab, maar laten wel zien waarom de plaatsing van een database werkbelastingmetingen vereist en niet alleen een beoordeling van de interfacesnelheid.

Voer een representatieve test uit met hetzelfde bestandssysteem, dezelfde synchronisatie-instellingen, databaseversie, dataset en gelijktijdigheid als gepland voor de service. Start tijdens de test een grote back-up of mediaoverdracht op het opslagnetwerk. Als de staartlatentie of committijd onvoorspelbaar wordt, compenseert centrale capaciteit het gedeelde pad niet.

Plaats primaire databestanden standaard dicht bij de compute

Voor één ontwikkelaar, één compute-node en bescheiden databases bieden lokale SSD's in een mirrorconfiguratie of een herstelbaar lokaal volume meestal het duidelijkste eigenaarschap. Het databaseproces, de databestanden en het write-ahead-logboek vallen samen uit, terwijl de storage-node back-ups ontvangt via een databasebewust proces in plaats van een permanent geopend bestandssysteem op afstand te hosten.

Lokale plaatsing betekent niet één onbeschermde opstartschijf. Scheid waar praktisch het databasevolume van het besturingssysteem, monitor de vrije ruimte en de gezondheid van de schijven, reserveer capaciteit voor onderhoudswerkzaamheden en exporteer back-ups vóór upgrades. Leg de plaatsing van containers of VM's vast, zodat een scheduler de database niet op een andere node start zonder de bijbehorende status.

Gebruik lokale opslag alleen wanneer het herstelpad echt werkt. Als het vervangen van de compute-node zou vereisen dat je moet gissen naar een verouderde kopie, kan gecentraliseerde opslag een bestaand back-upprobleem blootleggen in plaats van het te veroorzaken. Los de back-up- en herstelworkflow op voordat je het datapad optimaliseert.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

Gebruik de storage-node voor back-ups, replica's en archieven

Een storage-node is waardevol wanneer die applicatieconsistente dumps, base-back-ups, gearchiveerde transactielogboeken, onveranderlijke snapshots of een databasereplica met een eigen herstelfunctie ontvangt. De node kan ook grote bijlagen of analytische exports bevatten, terwijl de latentiegevoelige databasecatalogus en logboeken lokaal blijven.

Datatoepassing	Standaardlocatie	Waarom	Vereiste test
Primaire data en transactielogboek	SSD van de compute-node	Laagste en meest voorspelbare schrijfpad	Committijd en crashherstel
Logische dumps	Storage-node	Draagbare, versie bewuste bron voor herstel	Herstellen naar een lege database
Base-back-up en gearchiveerde logboeken	Storage-node	Herstel naar een specifiek tijdstip	Herstellen naar een benoemd tijdstip
Read-replica	Een van beide nodes met een eigen volume	Schaalvergroting voor lezen of hersteloptie	Vertraging en promotieprocedure
Uploads, exports en koude analyses	Storage-node	Capaciteit is belangrijker dan transactielatentie	Impact van gelijktijdige overdracht

Tests door de community van PostgreSQL via NFS op een storage-server leverden contra-intuïtieve resultaten en configuratievragen op, geen universeel antwoord. Daarom moet je externe primaire opslag behandelen als een ontworpen uitzondering: valideer synchronisatiegedrag, foutafhandeling, mountopties, cachesemantiek en herstel op de exacte stack.

Valideer herstel na storingen en de migratietrigger

Test vier gebeurtenissen: start de database netjes opnieuw op, laat de compute-node tijdens schrijfbewerkingen crashen, onderbreek de opslagverbinding tijdens een back-up en herstel naar een lege host. Controleer het herstelpunt, de hersteltijd, controles op de database-integriteit en het gedrag bij het opnieuw verbinden van de applicatie. Een snelle normale benchmark bewijst niet dat een onderbroken schrijfpad veilig is.

De opstelling slaagt wanneer actieve data een voorspelbare latentie heeft, back-ups de primaire database niet kunnen overschrijven of blokkeren en een vervangende compute-node kan herstellen zonder ongedocumenteerde aannames over opslag. Verplaats primaire bestanden alleen naar een ontworpen storage-service wanneer de gemeten herstel- of mobiliteitsvoordelen opwegen tegen de netwerkafhankelijkheid; verplaats ze terug naar lokale opslag wanneer staartlatentie of verbindingsuitval de belangrijkste bron van incidenten wordt.

Voor de bredere architectuurkeuze helpt de ZimaSpace-vergelijking van een storage-first NAS en compute-first thuisserver bepalen welke rol stabiel moet blijven terwijl ontwikkelworkloads veranderen.

Definitieve installatieregel

Kies standaard voor lokale, beschermde SSD-opslag voor actieve databestanden en gebruik de storage-node voor geverifieerde back-ups, archieven en geselecteerde replica's. Kies alleen voor externe primaire opslag nadat je de schrijfsemantiek, staartlatentie, het gedrag bij uitval en het herstelvoordeel ervan hebt gemeten.