IOPS vs. Throughput: Die richtigen Leistungsmetriken für Ihre Datenbank auswählen

Von Mirko Peters · 2026-08-11 · Aktualisiert 2026-08-26

Wenn Architekten und Datenbankadministratoren eine leistungsstarke Infrastruktur für anspruchsvolle Workloads wie SQL Server planen, sehen sie sich oft einer Flut technischer Akronyme und Speicherspezifikationen gegenüber. Zu den wichtigsten, aber häufig missverstandenen Metriken gehören IOPS und Durchsatz. Wählen Sie bei der Bereitstellung des Speichers die falsche Metrik, kann das zu trägen Abfr

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Wenn Architekten und Datenbankadministratoren eine leistungsstarke Infrastruktur für anspruchsvolle Workloads wie SQL Server planen, sehen sie sich oft einer Flut technischer Akronyme und Speicherspezifikationen gegenüber. Zu den wichtigsten, aber häufig missverstandenen Metriken gehören IOPS und Durchsatz. Wählen Sie bei der Bereitstellung des Speichers die falsche Metrik, kann das zu trägen Abfragen, ausgebremsten Systemen und verschwendeten Budgets führen. Zu verstehen, wie Ihre Datenbank Daten tatsächlich liest und schreibt, ist der erste Schritt zu einer belastbaren Architektur.

In diesem Beitrag erläutern wir die grundlegenden Unterschiede zwischen IOPS und Durchsatz, untersuchen, wie sie sich auf intensive Datenbank-Workloads auswirken, betrachten typische architektonische Engpässe wie Grenzwerte virtueller Maschinen und zeigen, wie gemeinsam genutzte Speichermodelle moderne Cloud-Umgebungen verändern.

Einführung in Datenbank-Leistungsmetriken

Speicherleistung lässt sich nicht über einen Kamm scheren. Wenn Sie Cloud-Speicher oder klassische SAN-Hardware betrachten, nennen Hersteller beeindruckende Werte dazu, wie schnell Daten bewegt werden können und wie viele Operationen ein Datenträger verarbeiten kann. Eine Datenbank-Engine verhält sich jedoch völlig anders als ein Videostreaming-Dienst oder ein großer Dateiserver. Während ein Videoserver große, kontinuierliche Datenströme durch eine Leitung pumpen muss, verbringt eine Datenbank ihre Zeit damit, bestimmte Zeilen zu suchen, Transaktionsprotokolle zu aktualisieren und Seiten im Speicher zwischenzuspeichern.

Um eine Umgebung zu entwerfen, die unter Last nicht einbricht, müssen Sie zunächst die unterschiedlichen Eigenschaften Ihrer Workloads verstehen. Dazu gehört eine genaue Betrachtung der beiden Säulen der Speicherleistung: Input/Output Operations Per Second (IOPS) und Megabyte pro Sekunde (Durchsatz).

IOPS definieren: Warum Datenbanken auf kleine Lese- und Schreibvorgänge setzen

IOPS steht für Input and Output Operations Per Second (Ein- und Ausgabeoperationen pro Sekunde). Die Kennzahl gibt an, wie viele einzelne Speicheranfragen ein Gerät in einer Sekunde verarbeiten kann. Bei intensiven Datenbankplattformen wie SQL Server sind IOPS meist die wichtigste Metrik.

Datenbanken sind von Natur aus transaktional. Wenn sich ein Benutzer bei einer Anwendung anmeldet, liest oder schreibt die Datenbank in der Regel nicht eine riesige Datei mit mehreren Gigabyte auf einmal. Stattdessen führt sie Tausende winziger, gezielter Operationen aus. Sie liest vielleicht eine 8-KB-Datenseite, um ein Benutzerprofil abzurufen, schreibt einige hundert Byte in ein Transaktionsprotokoll oder aktualisiert einen Index. Da diese Operationen so klein sind, ist die Fähigkeit des Speichersubsystems, eine hohe Anzahl einzelner Befehle zu verarbeiten, also seine IOPS-Kapazität, der wichtigste Treiber der Leistung. Benötigt Ihre Datenbank 10.000 IOPS, um mit den Benutzertransaktionen Schritt zu halten, der Datenträger liefert aber nur 3.000, stauen sich die Abfragen, Sperren kaskadieren und die Antwortzeiten der Anwendung brechen massiv ein.

Durchsatz definieren: Wann Bandbreite am wichtigsten ist

Während IOPS die *Anzahl* der Operationen misst, misst der Durchsatz das *Volumen* der über einen Zeitraum bewegten Daten, typischerweise angegeben in Megabyte pro Sekunde (MB/s). Stellen Sie sich IOPS als die Anzahl der Autos auf einer Autobahn vor und den Durchsatz als das Gesamtgewicht der Ladung, die sie transportieren.

Es gibt Szenarien, in denen der Durchsatz weit wichtiger ist als IOPS. Denken Sie an eine nächtliche Datenbanksicherung, einen umfangreichen Import in ein Data Warehouse oder analytische Abfragen, die Millionen von Zeilen einer Tabelle durchsuchen. Bei diesen Aufgaben kommt es weniger darauf an, wie viele einzelne Anfragen pro Sekunde verarbeitet werden, sondern wie schnell ein kontinuierlicher Strom großer Datenmengen eingelesen oder exportiert werden kann. Wenn Sie eine umfangreiche Datenmigration auf einem Speicher ausführen, der hohe IOPS, aber nur geringe Durchsatzgrenzen bietet, dauert die Migration Stunden länger als erwartet, weil die Datenleitung schlicht nicht breit genug ist.

Anwendungs-Workloads auf Speicherkonfigurationen abbilden

Jede Anwendung in Ihrem Unternehmen hat ein eigenes Speicherprofil. Eine erfolgreiche Architektur Ihrer Umgebung bedeutet, diese spezifischen Lese- und Schreibmuster der passenden Speicherkonfiguration zuzuordnen. Eine Datenbank für die Transaktionsverarbeitung (OLTP) benötigt beispielsweise hohe IOPS-Fähigkeiten, um parallele Benutzeranfragen ohne Latenzspitzen zu verarbeiten. Ein Data Lake oder ein Reporting-Server dagegen benötigt unter Umständen einen hohen Durchsatz, um analytische Abfragen zu verarbeiten.

Zur Herausforderung wird es, wenn eine Umgebung mehrere Workloads mit gegensätzlichen Lastmustern hostet. Eine SQL-Datenbank erreicht womöglich zum Monatsende bei der Finanzberichterstattung ihre Spitzenlast, ein Berichtsserver wird jeden Morgen um 8:00 Uhr stark ausgelastet, und ein Backup-System überflutet das Netzwerk über Nacht mit Datenverkehr. Früher haben Administratoren für jede einzelne Lastspitze eigene Datenträger bereitgestellt. Das führte zu massiver Überdimensionierung und ungenutzten Ressourcen.

Der Engpass bei virtuellen Maschinen: Mehr als nur Datenträger

Selbst wenn Sie die IOPS- und Durchsatzanforderungen Ihrer Datenbank sorgfältig berechnen und die schnellsten verfügbaren Datenträger bereitstellen, können Sie auf erhebliche Leistungsgrenzen stoßen. Die Ursache liegt oft nicht im Speichermedium selbst, sondern in der virtuellen Maschine, an die es angebunden ist.

Azure-VMs setzen beispielsweise je nach Größe und Stufe der gewählten VM strikte Grenzen für die gesamten Datenträger-IOPS und den Durchsatz. Sie können an eine kleine virtuelle Maschine Datenträger in Enterprise-Qualität mit extrem hoher Geschwindigkeit anbinden, die VM begrenzt den Speicherverkehr jedoch auf ihren eigenen Maximalwert. Das Speichersystem kann vielleicht 20.000 IOPS liefern, aber wenn der Pfad über die virtuelle Maschine auf 10.000 IOPS begrenzt ist, liegt genau hier Ihre Obergrenze. Prüfen Sie daher immer sowohl die Spezifikationen Ihrer Datenträger als auch die Dimensionierung Ihrer Rechenleistung, damit der Pfad zwischen beiden breit genug ist, um Ihre Lastspitzen zu bewältigen.

Wie gemeinsame Speicherpools die Leistungsplanung verändern

Um den Kreislauf aus isolierten, überdimensionierten Datenträgern für jede einzelne Workload zu durchbrechen, setzen moderne Cloud-Architekturen auf gemeinsame Speicherpools, die an klassische Storage Area Networks (SANs) erinnern. Anstatt die Leistung in getrennten, starren Containern einzuschließen, bündelt ein gemeinsames Modell Kapazität und IOPS.

In Umgebungen mit gepoolten Ressourcen skaliert die Leistung mit der Kapazität. In Azure Elastic SAN trägt beispielsweise jede 1 TiB Basiskapazität eine bestimmte Leistung zu einem zentralen Pool bei, etwa 5.000 IOPS und 200 MB pro Sekunde Durchsatz. Dieser gemeinsame Pool erlaubt es verschiedenen Volumes, aus einem gemeinsamen Leistungsbudget zu schöpfen. Benötigt Ihre Finanzdatenbank während einer intensiven Berichtsphase zusätzliche IOPS, während Ihr Data-Warehouse-System ruhig läuft, können diese Ressourcen dynamisch umverteilt werden, um die aktive Workload zu unterstützen.

Stolpersteine vermeiden: Spitzenlasten und gemeinsame Grenzen ausbalancieren

Gemeinsame Speicherpools bieten zwar enorme Flexibilität und Kostenvorteile, sie sind aber keine Patentlösung für unbegrenzte Leistung. Wenn Sie Ressourcen bündeln, setzen Sie darauf, dass statistisch nicht alle Datenbanken zur exakt gleichen Millisekunde ihre absolute Spitzenlast erreichen.

Wenn mehrere intensive Workloads gleichzeitig Lastspitzen erzeugen und ihre kombinierte Last die Grenzen des gemeinsamen Pools überschreitet, kommt es zu Drosselung. Drosselung erhöht die Latenz, verlangsamt Abfragen und kann kaskadierende Timeouts in Anwendungen auslösen. Datenbankadministratoren und Infrastrukturplaner müssen daher historische Messwerte sorgfältig analysieren, ihre gleichzeitige Spitzenauslastung verstehen und sicherstellen, dass der gemeinsame Speicherpool ausreichend Reserven hat, um überlappende Spitzenlasten ohne Leistungseinbußen aufzufangen.

Fazit: Die richtigen Kennzahlen für Ihre Datenbank wählen

Das richtige Verhältnis zwischen IOPS und Durchsatz zu finden, ist für alle entscheidend, die intensive Datenbank-Workloads in der Cloud betreiben. Wenn Sie präzise erkennen, ob Ihre Anwendungen eher kleine, schnelle Operationen oder großen Datendurchsatz benötigen, vermeiden Sie kostspielige Leistungsengpässe. Moderne Speicherkonzepte wie gemeinsame Pools können die Effizienz außerdem deutlich steigern und sorgen dafür, dass Ihre Infrastruktur intelligent mit Ihrem Geschäftswachstum skaliert. Wenn Sie tiefer einsteigen möchten, wie moderne Cloud-Speicherarchitekturen genau diese Skalierungs- und Leistungsherausforderungen lösen, sehen Sie sich unbedingt die passende Podcastfolge an: Azure Elastic SAN — Simply Explained.