IOPS vs. throughput: de juiste prestatiemetrics kiezen voor je database

By Mirko Peters · 2026-08-11 · Updated 2026-08-26

Wanneer architecten en databasebeheerders een krachtige infrastructuur willen ontwerpen voor zware workloads zoals SQL Server, komen ze al snel terecht in een lawine van technische afkortingen en opslagspecificaties. Tot de belangrijkste, maar ook vaakst verkeerd begrepen metrics behoren IOPS en throughput. Als je bij het inrichten van je opslag de verkeerde metric kiest, leidt dat tot trage queri

Automatically translated with AI from the original post. Read the English original

Wanneer architecten en databasebeheerders een krachtige infrastructuur willen ontwerpen voor zware workloads zoals SQL Server, komen ze al snel terecht in een lawine van technische afkortingen en opslagspecificaties. Tot de belangrijkste, maar ook vaak verkeerd begrepen metrics behoren IOPS en throughput. Als je bij het inrichten van je opslag de verkeerde metric kiest, leidt dat tot trage queries, vastlopende systemen en verspild budget. Begrijpen hoe je database data daadwerkelijk leest en schrijft, is de eerste stap naar een robuuste architectuur.

In dit artikel bespreken we de fundamentele verschillen tussen IOPS en throughput, kijken we hoe ze van toepassing zijn op intensieve databaseworkloads, bekijken we veelvoorkomende architectonische knelpunten zoals limieten van virtuele machines, en onderzoeken we hoe gedeelde opslagmodellen de situatie veranderen voor moderne cloudomgevingen.

Inleiding tot databaseprestatiemetrics

Opslagprestaties zijn niet voor iedereen hetzelfde. Wanneer je naar cloudopslag of traditionele SAN-hardware kijkt, gooien leveranciers met indrukwekkende cijfers over hoe snel data kan worden verplaatst en hoeveel bewerkingen een schijf kan verwerken. Een databasemotor gedraagt zich echter totaal anders dan een videostreamingdienst of een grote bestandsserver. Waar een videoserver grote, continue datastromen door een pijp moet persen, besteedt een database haar tijd aan het zoeken naar specifieke rijen, het bijwerken van transactielogs en het cachen van pagina's in het geheugen.

Om een omgeving te ontwerpen die onder druk niet bezwijkt, moet je eerst de specifieke eigenschappen van je workloads begrijpen. Dat begint met een diepgaande blik op de twee pijlers van opslagprestaties: Input/Output Operations Per Second (IOPS) en megabytes per seconde (throughput).

IOPS definiëren: waarom databases vertrouwen op kleine reads en writes

IOPS staat voor Input and Output Operations Per Second. Het is een maat voor het aantal afzonderlijke opslagverzoeken dat een apparaat in één seconde kan verwerken. Voor intensieve databaseplatforms zoals SQL Server is IOPS meestal de belangrijkste metric.

Databases zijn van nature transactioneel. Wanneer een gebruiker inlogt op een applicatie, leest of schrijft de database doorgaans niet in één keer een enorm bestand van meerdere gigabytes. In plaats daarvan voert ze duizenden kleine, gerichte bewerkingen uit. Ze leest misschien een datapagina van 8 KB om een gebruikersprofiel op te halen, schrijft een paar honderd bytes naar een transactielog of werkt een index bij. Omdat deze bewerkingen zo klein zijn, wordt het vermogen van het opslagsubsysteem om een groot volume afzonderlijke opdrachten te verwerken, oftewel de IOPS-capaciteit, de belangrijkste drijver van de prestaties. Als je database 10.000 IOPS nodig heeft om gelijke tred te houden met gebruikerstransacties, maar je opslagschijf er maar 3.000 kan leveren, dan ontstaan er wachtrijen met queries, lopen locks op en kelderen de responstijden van de applicatie.

Throughput definiëren: wanneer bandbreedte het meest telt

Waar IOPS het *aantal* bewerkingen meet, meet throughput het *volume* aan data dat in een bepaalde periode wordt verplaatst, meestal uitgedrukt in megabytes per seconde (MB/s). Zie IOPS als het aantal auto's dat over een snelweg rijdt, en throughput als het totale gewicht van de lading die ze vervoeren.

Er zijn scenario's waarin throughput veel belangrijker is dan IOPS. Denk aan een nachtelijke databasebackup, een grote import naar een datawarehouse of analytische queries die miljoenen rijen in een tabel doorzoeken. Bij deze taken draait het er minder om hoeveel afzonderlijke verzoeken er per seconde worden verwerkt; het gaat erom hoe snel een continue stroom van zware data kan worden ingelezen of geëxporteerd. Als je een grote datamigratie uitvoert op opslag met een hoge IOPS maar een lage throughputlimiet, dan duurt de migratie uren langer dan verwacht, omdat de datapijp simpelweg niet breed genoeg is.

Applicatieworkloads koppelen aan opslagconfiguraties

Elke applicatie in je organisatie heeft een eigen opslagkarakter. Een goede architectuur vertaalt die specifieke lees- en schrijfpatronen naar de juiste opslagconfiguratie. Zo heeft een transactionele (OLTP-)database hoge IOPS-capaciteit nodig om gelijktijdige gebruikersverzoeken af te handelen zonder latentiepieken. Een data lake of een rapportageserver heeft daarentegen juist vaak hoge throughput nodig om analytische queries snel te verwerken.

De uitdaging ontstaat wanneer een omgeving meerdere workloads met conflicterende patronen host. Een SQL-database kan piekbelasting hebben tijdens de maandafsluitende financiële rapportage, een rapportageserver kan elke ochtend om 8:00 uur pieken, en een back-upsysteem kan 's nachts het netwerk overspoelen met verkeer. Vroeger zetten beheerders voor elke afzonderlijke piek aparte schijven klaar, wat leidde tot enorme overprovisioning en ongebruikte resources.

De bottleneck van de virtuele machine: meer dan alleen schijven

Ook als je de IOPS- en doorvoerbehoefte van je database zorgvuldig berekent en de snelste beschikbare schijven inricht, kun je nog steeds tegen ernstige prestatiegrenzen aanlopen. De boosdoener is vaak niet het opslagmedium zelf, maar de virtuele machine waaraan het is gekoppeld.

Azure-virtuele machines hanteren bijvoorbeeld strikte limieten voor de totale schijf-IOPS en doorvoer, afhankelijk van de grootte en het niveau van de gekozen VM. Je kunt enterprise-grade, supersnelle schijven koppelen aan een bescheiden VM-grootte, maar dan begrenst de VM het opslagverkeer tot de eigen maximumdrempel. Het opslagsysteem kan misschien 20.000 IOPS leveren, maar als het virtuele-machinepad je beperkt tot 10.000 IOPS, dan is dat je plafond. Controleer daarom altijd zowel je schijfspecificaties als de dimensionering van je rekenkracht, zodat het pad ertussen breed genoeg is voor je piekbelasting.

Hoe gedeelde opslagpools de prestatieplanning veranderen

Om de cyclus van het inrichten van geïsoleerde, te grote schijven voor elke afzonderlijke workload te doorbreken, kijken moderne cloudarchitecturen naar gedeelde opslagpools, die doen denken aan traditionele Storage Area Networks (SAN's). In plaats van prestaties vast te zetten in afzonderlijke, starre containers, bundelt een gedeeld model capaciteit en IOPS.

In omgevingen die gepoolde resources gebruiken, schalen de prestatiecijfers mee met de capaciteit. In Azure Elastic SAN levert elke 1 TiB basiscapaciteit bijvoorbeeld een vaste hoeveelheid prestaties bij aan een centrale pool, zoals 5.000 IOPS en 200 MB per seconde doorvoer. Via deze gedeelde pool kunnen verschillende volumes putten uit een gezamenlijk prestatiebudget. Als je financiële database tijdens een zware rapportageperiode extra IOPS nodig heeft terwijl je magazijnsysteem rustig is, dan kunnen die resources dynamisch worden ingezet om de actieve workload te ondersteunen.

Valkuilen vermijden: pieken en gedeelde limieten in balans brengen

Gedeelde opslagpools bieden ongelooflijke flexibiliteit en kostenbesparingen, maar ze zijn geen wondermiddel voor onbeperkte prestaties. Resources bundelen betekent dat je vertrouwt op de statistische kans dat niet elke database precies tegelijkertijd zijn absolute piekbelasting bereikt.

Als meerdere intensieve workloads tegelijk pieken en hun gezamenlijke vraag de limieten van de gedeelde pool overschrijdt, treedt throttling op. Throttling veroorzaakt latentie, vertraagt query's en kan leiden tot cascaderende applicatietime-outs. Database-administrators en infrastructuurplanners moeten daarom historische metrics zorgvuldig analyseren, hun gelijktijdige piekgebruik begrijpen en ervoor zorgen dat de gedeelde opslagpool voldoende ruimte heeft om overlappende piekbelastingen moeiteloos op te vangen.

Conclusie: kies de juiste metrics voor je database

Het vinden van de juiste balans tussen IOPS en doorvoer is essentieel voor iedereen die intensieve databaseworkloads in de cloud beheert. Door nauwkeurig vast te stellen of je applicaties tekortkomen in kleine, snelle bewerkingen of in enorme databandbreedte, voorkom je kostbare prestatieknelpunten. Bovendien zorgt het omarmen van moderne opslagparadigma's, zoals gedeelde pools, voor een aanzienlijke efficiëntiewinst, waardoor je infrastructuur slim meeschaalt met de groei van je bedrijf. Wil je dieper ingaan op hoe moderne cloudopslagarchitecturen deze schaal- en prestatie-uitdagingen oplossen? Bekijk dan ook de bijbehorende podcastaflevering: Azure Elastic SAN — Simply Explained.