Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Kontingente und Limits in Amazon QLDB
Wichtig
Hinweis zum Ende des Supports: Bestandskunden können Amazon QLDB bis zum Ende des Supports am 31.07.2025 nutzen. Weitere Informationen finden Sie unter Migrieren eines Amazon QLDB-Ledgers zu Amazon
In diesem Abschnitt werden die aktuellen Kontingente, auch Limits genannt, in Amazon QLDB beschrieben.
Themen
Standardkontingente
QLDB hat die folgenden Standardkontingente, wie sie auch bei Amazon QLDB-Endpunkten und Kontingenten in der aufgeführt sind. Allgemeine AWS-Referenz Diese Kontingente gelten pro Region. AWS-Konto Um eine Erhöhung des Kontingents für Ihr Konto in einer Region zu beantragen, verwenden Sie die Konsole Service Quotas.
Melden Sie sich bei der an AWS Management Console und öffnen Sie die Service Quotas Quotas-Konsole unter https://console.aws.amazon.com/servicequotas/
| Ressource | Standardkontingent |
|---|---|
| Die maximale Anzahl aktiver Ledger, die Sie in diesem Konto in der aktuellen Region erstellen können | 5 |
| Die maximale Anzahl aktiver Journalexporte nach Amazon S3 pro Ledger | 2 |
| Die maximale Anzahl von aktiven Journal-Streams zu Kinesis Data Streams pro Ledger | 5 |
Feste Kontingente
Zusätzlich zu den Standardkontingenten hat QLDB die folgenden festen Kontingente pro Ledger. Diese Kontingente können nicht mithilfe von Service Quotas erhöht werden:
| Ressource | Festes Kontingent |
|---|---|
| Anzahl gleichzeitig aktiver Sitzungen | 3000 |
| Anzahl der aktiven Tabellen | 20 |
IndexedStorage— Gesamtmenge des Festplattenspeichers, der von den Tabellen, Indizes und dem indizierten Verlauf des Ledgers belegt wurde, in Intervallen von 15 Minuten gemeldet. Weitere Informationen zu CloudWatch Amazon-Metriken finden Sie unter Monitoring with Amazon CloudWatch. |
Maximal 16 TiB |
Gesamtanzahl der Tabellen (aktiv und inaktiv) AnmerkungIn QLDB werden gelöschte Tabellen als inaktiv betrachtet und auf dieses Gesamtkontingent angerechnet. |
40 |
| Anzahl der Indizes pro Tabelle | 5 |
| Anzahl der Dokumente in einer Transaktion | 40 |
| Anzahl der Änderungen, die in einer Transaktion geschwärzt werden müssen | 1 |
Größe des Dokuments (im Format kodiert) IonBinary |
128 KB |
Größe des Anweisungsparameters (IonBinaryFormat) |
128 KB |
Größe des Anweisungsparameters (IonTextFormat) |
1 MB |
| Länge der Anweisungszeichenfolge | 100 000 Zeichen |
| Größe der Transaktion | 4 MB |
| Timeout für die Transaktion | 30 Sekunden |
| Ablaufzeitraum für abgeschlossene Journalexportaufträge | 7 Tage |
| Ablaufzeitraum für Beendigungs-Journal-Streams | 7 Tage |
Kontingent für das Hauptbuch
Um eine Erhöhung des Kontingents für Ihr Konto in einer Region zu beantragen, können Sie die Konsole Service Quotas verwenden.
Öffnen Sie die Service Quotas-Konsole unter https://console.aws.amazon.com/servicequotas/
Einige QLDB-Anwendungsfälle erfordern je nach Geschäftswachstum eine wachsende Anzahl von Ledgern AWS-Konto pro Region. Beispielsweise müssen Sie möglicherweise spezielle Ledger erstellen, um Kunden oder Daten zu isolieren. In diesem Fall sollten Sie erwägen, eine Architektur mit mehreren Konten zu nutzen, um mit QLDB-Kontingenten zu arbeiten. Weitere Informationen finden Sie unter Account Silo Isolation im AWS Whitepaper SaaS Tenant Isolation
Dokumentengröße
Die maximale Größe für ein Dokument, das in diesem IonBinary Format codiert ist, beträgt 128 KB. Wir können keine genaue Grenze für die Größe eines Dokuments im IonText Format angeben, da die Konvertierung von Text zu Binärdatei je nach Struktur der einzelnen Dokumente erheblich variiert. QLDB unterstützt Dokumente mit offenem Inhalt, sodass jede eindeutige Dokumentstruktur die Größenberechnung verändert.
Transaktionsgröße
Die maximale Größe für eine Transaktion in QLDB beträgt 4 MB. Die Größe einer Transaktion ergibt sich aus der Summe der folgenden Faktoren.
- Deltas
-
Das Dokumentänderungen, die von allen Anweisungen innerhalb der Transaktion generiert werden. Bei einer Transaktion, die sich auf mehrere Dokumente auswirkt, ist die gesamte Delta-Größe die Summe der einzelnen Delta-Werte jedes betroffenen Dokuments.
- Metadaten
-
Die vom System generierten Transaktionsmetadaten, die jedem betroffenen Dokument zugeordnet sind.
- Indizes
-
Wenn ein Index für eine Tabelle definiert ist, die von der Transaktion betroffen ist, generiert der Indexeintrag auch einen Delta.
- Verlauf
-
Da alle Dokumentrevisionen in QLDB gespeichert werden, werden auch alle Transaktionen an die Historie angehängt.
Einfügungen — Für jedes in eine Tabelle eingefügte Dokument wird auch eine Kopie in die Verlaufstabelle eingefügt. Beispiel: Ein neu eingefügtes 100-KB Dokument generiert mindestens 200 KB von Deltas in einer Transaktion. (Dies ist eine grobe Schätzung, die keine Metadaten oder Indizes beinhaltet.)
Aktualisierungen — Jede Aktualisierung eines Dokuments, auch für ein einzelnes Feld, erzeugt eine neue Version des gesamten Dokuments im Verlauf, plus oder minus dem Delta der Aktualisierung. Das bedeutet, dass ein kleines Update in einem großen Dokument weiterhin ein großes Transaktions-Delta generiert. Beispiel: Durch das Hinzufügen von 2 KB an Daten in ein vorhandenes 100-KB-Dokument wird eine neue 102-KB-Revision im Verlauf erstellt. Dies beläuft sich auf mindestens 104 KB der gesamten Deltas in einer Transaktion. (Auch hier beinhaltet diese Schätzung keine Metadaten oder Indizes.)
Löschungen — Ähnlich wie bei Aktualisierungen wird bei jeder Löschtransaktion eine neue Dokumentrevision in der Historie erstellt. Die neu erstellte
DELETE-Revision ist jedoch kleiner als das ursprüngliche Dokument, da sie keine Benutzerdaten hat und nur Metadaten enthält.
Benennungseinschränkungen:
In der folgenden Tabelle werden Benennungseinschränkungen in Amazon QLDB beschrieben.
| Ledger-Name |
|
| Name des Journaldatenstreams | |
| Tabellenname |
|
