Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In dieser Referenz werden Skalierbarkeits- und Leistungsziele für Azure Storage beschrieben. Die hier aufgeführten Skalierbarkeits- und Leistungsziele sind High-End-Ziele, aber sie sind erreichbar. In allen Fällen hängt die Anforderungsrate und Bandbreite, die Ihr Speicherkonto erreicht, von der Größe der gespeicherten Objekte, den verwendeten Zugriffsmustern und dem Typ der Arbeitsauslastung ab, die Ihre Anwendung ausführt.
Testen Sie Ihren Dienst, um festzustellen, ob die Leistung Ihren Anforderungen entspricht. Wenn möglich, vermeiden Sie plötzliche Spitzen im Traffic und stellen Sie sicher, dass der Traffic gut über die Partitionen verteilt ist.
Wenn Ihre Anwendung den Grenzwert erreicht, den eine Partition für Ihre Workload verarbeiten kann, gibt Azure Storage einen Fehlercode 503 (Server ausgelastet) oder einen Fehlercode 500 (Operation Timeout) zurück. Wenn 503-Fehler auftreten, sollten Sie Ihre Anwendung so anpassen, dass für erneute Versuche eine exponentielle Backoff-Strategie verwendet wird. Der exponentielle Backoff verringert die Last auf der Partition und mildert Spitzen im Datenverkehr zu dieser Partition.
Für die Service-Level Agreement (SLA) für Azure Storage-Konten siehe SLA für Storage Accounts.
Skalierungsziele für Blob-Speicher
| Ressource | Ziel |
|---|---|
| Maximale Größe eines einzelnen Blobcontainers | Identisch mit maximaler Speicherkontokapazität |
| Maximale Anzahl von Blöcken in einem Blockblob oder einem Anfügeblob | 50.000 Blöcke |
| Maximale Größe eines Blocks in einem Blockblob | 4.000 MiB |
| Maximale Größe eines Blockblobs | 50.000 x 4.000 MiB (ca. 190,7 TiB) |
| Maximale Größe eines Blocks in einem Anfügeblob | 4 MiB |
| Maximale Größe eines Anfügeblobs | 50.000 × 4MiB (ca. 195GiB) |
| Max. Größe eines Seitenblobs | 8 TiB2 |
| Maximale Anzahl gespeicherter Zugriffsrichtlinien pro Blobcontainer | 5 |
| Zielanforderungsrate für einen einzelnen Block Blob | Bis zu 3.000 Anforderungen pro Sekunde |
| Zielanforderungsrate für ein einzelnes Seiten-BLOB | Bis zu 500 Anforderungen pro Sekunde |
| Zieldurchsatz für ein einzelnes Seitenblob | Bis zu 60 MiB pro Sekunde2 |
| Zieldurchsatz für ein einzelnes Blockblob | Bis zur Eingangs-/Ausgangsbegrenzung des Speicherkontos1 |
1 Der Durchsatz für ein einzelnes Blob hängt von mehreren Faktoren ab. Diese Faktoren sind jedoch nicht auf Parallelität, Anforderungsgröße, Leistungsstufe, Geschwindigkeit der Quelle für Uploads und Ziel für Downloads beschränkt. Laden Sie größere Blobs oder Blöcke hoch, um von den Leistungsverbesserungen für Blockblobs mit hohem Durchsatz zu profitieren. Rufen Sie insbesondere den Put-Blob-Vorgang oder Put-Block-Vorgang mit einer Blob- oder Blockgröße auf, die größer als 256 KiB ist.
2 Seitenblobs werden noch nicht in Konten mit aktiviertem hierarchischem Namespace unterstützt.
In der folgenden Tabelle werden die maximal zulässigen Block- und Blob-Größen für die Dienstversion beschrieben.
| Dienstversion | Maximale Blockgröße (über Put Block) | Maximale Blob-Größe (über Put Block List) | Maximale Blob-Größe über einen einzelnen Schreibvorgang (über Put Blob) |
|---|---|---|---|
| Ab Version 2019-12-12 | 4.000 MiB | Ungefähr 190,7 TiB (4.000 MiB x 50.000 Blöcke) | 5.000 MiB |
| Version 2016-05-31 bis Version 2019-07-07 | 100 MiB | Ungefähr 4,75 TiB (100 MiB x 50.000 Blöcke) | 256 MiB |
| Versionen vor 2016-05-31 | 4 MiB | Ca. 195 GiB (4 MiB x 50.000 Blöcke) | 64 MiB |
Heiße Partitionen: Erkennung, Überwachung und Abmilderung
Azure Blob Storage verteilt Daten und Anfragen über Partitionen hinweg, um Workloads skalieren zu können. Ein Speicherkonto kann über verfügbare Kapazitäten und Durchsatz verfügen, während Workloads, die den Datenverkehr auf eine enge Bandbreite von Partitionsschlüsseln konzentrieren, auf Partitionsebene Durchsatzbeschränkungen erfahren.
Wenn eine einzelne Partition deutlich mehr Datenverkehr erhält als andere Partitionen, wird sie zu einer heißen Partition. Der Partitionsschlüssel für einen Blob kombiniert den Speicherkontonamen, den Containernamen und den Blob-Namen, sodass sequentielle oder nur anhängende Benennungsschemata den Datenverkehr auf eine einzelne Partition konzentrieren können.
Wenn eine Partition heiß wird, kann Ihre Anwendung eine erhöhte Latenz beobachten und HTTP 503 (Server Busy) oder HTTP 500 (Operation Timeout) Antworten erhalten, bevor das Speicherkonto seine dokumentierten Skalierbarkeitsgrenzen erreicht.
Um heiße Partitionen zu mindern:
Vermeiden Sie sequentielle oder nur angehängte Blob-Benennungsschemata, die den Datenverkehr auf einer einzigen Partition konzentrieren.
Verwenden Sie eine exponentielle Backoff-Wiederholungsstrategie, wenn Drosselungsfehler auftreten.
Erhöhe die Anfrageraten schrittweise, wenn du neue Arbeitslasten einführst.
Um Throttling zu erkennen und die Quelle der übermäßigen Nachfrage zu identifizieren, verwenden Sie Azure Monitor-Metriken und Ressourcenprotokolle.
Weitere Informationen finden Sie unter Mitigate hot partitions in Azure Blob Storage.