We raden u aan “alles op S3 te zetten” om de rekening te verlagen. Behalve dat uw PostgreSQL al op een NVMe-blokvolume draait – en een DBA u eraan herinnert dat databases niet in buckets leven.
Blokopslag (volume gekoppeld aan een VPS, cloudschijf, SAN) stelt een /dev/sdb-apparaat bloot dat is geformatteerd in ext4 of XFS. De basisengine daar doet willekeurige lees-/schrijfbewerkingen, fsyncs en vergrendelingen. Objectopslag legt sleutels bloot; elke PUT vervangt het gehele object. Het verwarren van de twee modellen op het gebied van gegevens die elke seconde veranderen, is een van de kostbaarste architectonische fouten.
Blok versus object: toegang tot semantiek
| nodig | Blokkeer schijf | Objectopslag |
|---|---|---|
| MySQL / PostgreSQL / MongoDB lokaal | Ja | Nee |
| Redis-persistentie AOF/RDB | Ja | Nee |
| Onveranderlijke foto-upload | Mogelijk maar zwaar | Ideaal |
| Gearchiveerde logbestanden met alleen toevoegen | Blokkeren en vervolgens draaien → object | Ideaal (levenscyclus) |
| Frequente gedeeltelijke veranderingen | Ja (offset schrijven) | Nee (volledig object herschrijven) |
| Crash-consistente snapshots | Ja (met voorzorgsmaatregelen) | Versiebeheer per object |
Door een database op S3 te zetten “omdat deze schaalbaar is”, wordt voorbijgegaan aan het feit dat de schaalbaarheid van databases afhangt van replicatie, en niet van HTTP PUT’s.
Gegevens die vaak veranderen: blijf in één blok
Relationele motoren. Gegevensmap, WAL, binlog: p99-latentie en ingerichte IOPS bepalen de ondersteuning. Hiervoor bestaan “Database-geoptimaliseerde” cloudaanbiedingen of NVMe-volumes.
Persistente caches. Redis AOF, bestandssessies: frequente kleine schrijfbewerkingen - slechte objectpassing.
Legacy POSIX-applicaties. ERP dat honderden kleine tijdelijke bestanden schrijft in /tmp/app: blok of lokale SSD.
Lokale stateful containers. Genoemd Docker-volume voor Elasticsearch of Prometheus TSDB: bijgevoegd blok, reguliere snapshots.
Beste blokpraktijken: snapshots vóór grote upgrade; IOPS-monitoring en vrije ruimte met 80% alert; afzonderlijke gegevens en besturingssysteem op twee volumes voor gericht herstel.
Gegevens die weinig of één keer veranderen: object wint
Gebruikersmedia. Eén keer schrijven, veel lezen via CDN.
Back-ups en dumps. pg_dump gecomprimeerd naar bucket met een retentie van 30 dagen — klassiek en voordelig.
Koude logboeken. Lokale rotatie 48 uur per blok, aggregatie naar koudeklasse-emmer.
CI-artefacten. Binaire bestanden met versieversie, onveranderlijk door hash.
Scaleway, OVHcloud en hyperscalers factureren blok en object afzonderlijk: vergelijk uitgaand wanneer de database herstelt van S3 naar een nieuw volume.
De slecht uitgevoerde hybride valstrik
Gezond patroon: gebaseerd op NVMe, objectbestanden, metadata in SQL.
Toxisch patroon: basis op blok en kritische applicatiebestanden alleen op blok zonder back-upobject - verlies van volume = totaal verlies. Giftig omgekeerd patroon: probeer SQLite op NFS gemonteerd vanaf een objectgateway – latentie en corruptie.
Het hoogtepunt: de S3-factuur is niet de architectuurfactuur
Beslis en ga vooruit zonder blinde vlek
Vermeld elke datastore met zijn schrijfsnelheid: bewerkingen per seconde, gemiddelde grootte, veranderlijk of onveranderlijk. Plaats de basis en deksels op een blok van formaat na de IOPS-meting onder reële belasting. Exporteer back-ups en media om bezwaar te maken met levenscyclusregels.
Test blokvolumeherstel en herstel van geïsoleerde objecten – niet alleen het maken van de back-up. Blader door blok- en objectaanbiedingen in onze vergelijking. Voor applicatiebestanden versus NAS, zie Objectopslag of NAS.
Veelgestelde vragen
Kan MySQL worden gehost op objectopslag?
Niet in standaardproductie. MySQL vereist een blokbestandssysteem met lage latentie. Object voor stortplaatsen en archieven.
Wanneer vervangt S3 een blokvolume?
Bestanden worden één keer geschreven en vervolgens gelezen, via SDK/CDN. Frequente herschrijvingen geven de voorkeur aan het blok.
Zijn bloksnapshots voldoende als back-up?
Niet alleen. Combineer snapshots, externe objectexport en hersteltests.
Hoe kies ik de IOPS-grootte?
Profiel in piek: IOPS aanhoudend, latentie p99. Vermijd blinde over- en ondermaats.
Voordat u een database "naar de cloud" migreert, één vraag: hoeveel willekeurige schrijfbewerkingen per seconde? Als u het niet weet, heeft de blokschijf nog geen grootte - en S3 is niet het antwoord.