Verwaltung hoher Objektzahlen in Amazon RDS for PostgreSQL Aurora PostgreSQL - Amazon Relational Database Service
RelationenTemporäre TabellenNicht protokollierte TabellenPartitionenTemporäre DateienSequenzenGroße ObjekteUngefähre Schwellenwerte

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.

Verwaltung hoher Objektzahlen in Amazon RDS for PostgreSQL Aurora PostgreSQL

PostgreSQL-Einschränkungen sind zwar theoretisch, aber extrem hohe Objektzahlen in einer Datenbank haben spürbare Auswirkungen auf die Leistung verschiedener Operationen. Diese Dokumentation behandelt mehrere gängige Objekttypen, die bei einer hohen Gesamtzahl zu mehreren möglichen Auswirkungen führen können.

Die folgende Tabelle enthält eine Zusammenfassung der Objekttypen und ihrer möglichen Auswirkungen:

Objekttypen und mögliche Auswirkungen
Art des Objekts Autovakuum Logische Replikation Upgrade einer Hauptversion pg_dump//pg_restore Allgemeine Leistung Neustart der Instanz
Beziehungen x x x x
Temporäre Tabellen x x
Nicht protokollierte Tabellen x x
Partitionen x
Temporäre Dateien x
Sequenzen x
Große Objekte x x

Relationen

Es gibt kein bestimmtes festes Limit für die Anzahl der Tabellen in einer PostgreSQL-Datenbank. Die theoretische Grenze ist extrem hoch, aber es gibt noch andere praktische Grenzen, die beim Datenbankentwurf berücksichtigt werden müssen.

Auswirkung: Autovacuum gerät ins Hintertreffen

Autovacuum kann Schwierigkeiten haben, mit dem Wachstum der Transaktions-IDs Schritt zu halten, oder es kann sein, dass die Tabelle aufgrund des Mangels an Mitarbeitern im Verhältnis zum Arbeitsaufwand überfüllt wird.

Empfohlene Maßnahme: Es gibt mehrere Faktoren, um Autovacuum so einzustellen, dass es mit einer bestimmten Anzahl von Tabellen und einer bestimmten Arbeitslast Schritt hält. Vorschläge zur Festlegung geeigneter Autovacuum-Einstellungen finden Sie unter Bewährte Methoden für die Arbeit mit PostgreSQL-Autovacuum .

Auswirkung: Upgrade der Hauptversion//pg_dump und Wiederherstellung

Amazon RDS verwendet während der Ausführung von pg_upgrade die Option „--link“, um zu vermeiden, dass Kopien von Datendateien erstellt werden müssen. Die Schema-Metadaten müssen dennoch in der neuen Version der Datenbank wiederhergestellt werden. Selbst bei parallelem pg_restore erhöht dies die Ausfallzeit, wenn es eine beträchtliche Anzahl von Beziehungen gibt.

Auswirkung: Allgemeiner Leistungsabfall

Allgemeine Leistungseinbußen aufgrund der Kataloggröße. Jede Tabelle und die zugehörigen Spalten werden zu pg_depend Tabellen hinzugefügtpg_attribute, pg_class die häufig bei normalen Datenbankoperationen verwendet werden. Es wird kein bestimmtes Warteereignis sichtbar sein, aber die Effizienz des gemeinsamen Puffers wird beeinträchtigt.

Empfohlene Maßnahme: Überprüfen Sie regelmäßig, ob Table Bloat für diese speziellen Tabellen verfügbar ist, und führen Sie gelegentlich eine VACUUM FULL Überprüfung dieser spezifischen Tabellen durch. Beachten Sie, dass VACUUM FULL für Katalogtabellen eine ACCESS EXCLUSIVE Sperre erforderlich ist, was bedeutet, dass keine anderen Abfragen auf sie zugreifen können, bis der Vorgang abgeschlossen ist.

Auswirkung: Erschöpfung des Dateideskriptors

Fehler: „Keine Dateideskriptoren mehr vorhanden: Zu viele offene Dateien im System; freigeben und erneut versuchen“. Der PostgreSQL-Parameter max_files_per_process bestimmt, wie viele Dateien jeder Prozess öffnen kann. Wenn es eine große Anzahl von Verbindungen gibt, die eine große Anzahl von Tabellen verbinden, ist es möglich, dieses Limit zu erreichen.

Empfohlene Maßnahme:

  • Wenn Sie den Wert des Parameters verringern, max_files_per_process kann dieser Fehler möglicherweise behoben werden. Jeder Prozess und Unterprozess (z. B. parallel Abfrage) kann diese Anzahl von Dateien öffnen, und wenn die Abfragen mehrere Tabellen verbinden, kann dieses Limit ausgeschöpft sein.

  • Reduzieren Sie die Gesamtzahl der Verbindungen und verwenden Sie einen Verbindungspooler wie Amazon RDS Proxy, oder andere Lösungen wie PgBouncer. Weitere Informationen finden Sie PgBouncer auf der Website.

Auswirkung: Inode-Erschöpfung

Fehler: „Auf dem Gerät ist kein Speicherplatz mehr vorhanden“. Wenn dies beobachtet wird, wenn viel freier Speicherplatz vorhanden ist, liegt dies daran, dass die Inodes knapp werden. Amazon RDS Enhanced Monitoring bietet Einblick in die verwendeten Inodes und die maximale Anzahl, die für Ihren Host verfügbar ist.

Ungefährer Schwellenwert: Millionen

Temporäre Tabellen

Die Verwendung temporärer Tabellen ist nützlich für Testdaten oder Zwischenergebnisse und ist ein gängiges Muster, das in vielen Datenbank-Engines zu finden ist. Die Auswirkungen der starken Nutzung von PostgreSQL müssen verstanden werden, um einige der Fallstricke zu vermeiden. Bei jedem Erstellen und Löschen temporärer Tabellen werden den Systemkatalogtabellen Zeilen hinzugefügt, was zu allgemeinen Leistungsproblemen führt, wenn sie aufgebläht werden.

Auswirkung: Autovacuum gerät ins Hintertreffen

Temporäre Tabellen werden nicht automatisch gelöscht, sondern speichern Transaktionen IDs , solange sie existieren. Wenn sie nicht entfernt werden, kann es zu einem Wraparound kommen.

Empfohlene Maßnahme: Temporäre Tabellen bleiben für die Dauer der Sitzung bestehen, in der sie erstellt wurden, oder können manuell gelöscht werden. Eine bewährte Methode zur Vermeidung lang andauernder Transaktionen mit temporären Tabellen verhindert, dass diese Tabellen zum Anstieg der maximal genutzten Transaktions-IDs beitragen.

Auswirkung: Allgemeiner Leistungsabfall

Allgemeine Leistungseinbußen aufgrund der Kataloggröße. Wenn Sitzungen kontinuierlich temporäre Tabellen erstellen und löschen, werden pg_depend Tabellen hinzugefügtpg_attribute, pg_class die häufig bei normalen Datenbankoperationen verwendet werden. Es wird kein bestimmtes Warteereignis sichtbar sein, aber die Effizienz des gemeinsamen Puffers wird beeinträchtigt.

Empfohlene Maßnahme:

  • Überprüfen Sie regelmäßig, ob Table Bloat für diese speziellen Tabellen verfügbar ist, und führen Sie gelegentlich eine VACUUM FULL Prüfung für diese spezifischen Tabellen durch. Beachten Sie, dass VACUUM FULL für Katalogtabellen eine ACCESS EXCLUSIVE Sperre erforderlich ist, was bedeutet, dass keine anderen Abfragen auf sie zugreifen können, bis der Vorgang abgeschlossen ist.

  • Wenn temporäre Tabellen stark genutzt werden, wird vor einem Upgrade einer Hauptversion dringend empfohlen, eine VACUUM FULL dieser speziellen Katalogtabellen zu verwenden, um Ausfallzeiten zu reduzieren.

Allgemeine bewährte Methoden:

  • Reduzieren Sie die Verwendung temporärer Tabellen, indem Sie allgemeine Tabellenausdrücke verwenden, um Zwischenergebnisse zu erzielen. Diese können manchmal die erforderlichen Abfragen verkomplizieren, verhindern jedoch die oben aufgeführten Auswirkungen.

  • Verwenden Sie temporäre Tabellen erneut, indem Sie den TRUNCATE Befehl verwenden, um den Inhalt zu löschen, anstatt drop/create Schritte auszuführen. Dadurch wird auch das Problem des durch temporäre Tabellen verursachten Wachstums der Transaktions-IDs behoben.

Ungefährer Schwellenwert: Zehntausende

Nicht protokollierte Tabellen

Nicht protokollierte Tabellen können Leistungssteigerungen bieten, da sie keine WAL-Informationen generieren. Sie müssen vorsichtig verwendet werden, da sie bei der Wiederherstellung nach einem Datenbankabsturz keine Beständigkeit bieten, da sie gekürzt werden. Dies ist eine teure Operation in PostgreSQL, da jede nicht protokollierte Tabelle seriell gekürzt wird. Dieser Vorgang ist zwar bei einer geringen Anzahl nicht protokollierter Tabellen schnell, kann aber bei Tausenden von Tabellen zu erheblichen Verzögerungen beim Start führen.

Auswirkung: Logische Replikation

Nicht protokollierte Tabellen sind im Allgemeinen nicht in der logischen Replikation enthalten, einschließlich Blue/Green-Bereitstellungen , da die logische Replikation zur Erfassung und Übertragung von Änderungen auf der WAL basiert.

Auswirkung: Verlängerte Ausfallzeit während der Wiederherstellung

Bei jedem Datenbankstatus, der eine Wiederherstellung nach einem Datenbankabsturz beinhaltet, wie z. B. Multi-AZ-Neustart mit Failover, Amazon point-in-time RDS-Wiederherstellung und Amazon RDS-Hauptversions-Upgrade, erfolgt der serialisierte Vorgang, bei dem die nicht protokollierten Tabellen gekürzt werden. Dies kann zu wesentlich höheren Ausfallzeiten als erwartet führen.

Empfohlene Maßnahme:

  • Beschränken Sie die Verwendung nicht protokollierter Tabellen auf Daten, deren Verlust bei der Wiederherstellung nach einem Datenbankabsturz akzeptabel ist.

  • Reduzieren Sie die Verwendung von Tabellen, die nicht protokolliert wurden, da das derzeitige Verhalten der seriellen Kürzung dazu führen kann, dass der Start einer Datenbank viel Zeit in Anspruch nimmt.

Allgemeine bewährte Methoden:

  • Nicht protokollierte Tabellen sind nicht absturzsicher. Das Initiieren einer point-in-time Wiederherstellung, die eine Wiederherstellung nach einem Absturz beinhaltet, nimmt in PostgreSQL viel Zeit in Anspruch, da es sich um einen seriellen Prozess handelt, bei dem jede Tabelle gekürzt wird.

Ungefährer Schwellenwert: Tausende

Partitionen

Durch Partitionierung kann die Abfrageleistung erhöht und eine logische Organisation der Daten ermöglicht werden. Im Idealfall ist die Partitionierung so organisiert, dass das Bereinigen von Partitionen bei der Planung und Ausführung von Abfragen verwendet werden kann. Die Verwendung zu vieler Partitionen kann sich negativ auf die Abfrageleistung und die Datenbankwartung auswirken. Die Wahl, wie eine Tabelle partitioniert werden soll, sollte sorgfältig getroffen werden, da die Leistung der Abfrageplanung und -ausführung durch einen schlechten Entwurf negativ beeinflusst werden kann. Einzelheiten zur Partitionierung finden Sie in der PostgreSQL-Dokumentation.

Auswirkung: Allgemeiner Leistungsabfall

Manchmal nimmt der Zeitaufwand für die Planung zu und die Erläuterung der Pläne für Ihre Abfragen wird komplizierter, sodass es schwierig wird, Optimierungsmöglichkeiten zu identifizieren. Bei PostgreSQL-Versionen vor 18 können viele Partitionen mit hoher Arbeitslast zu LWLock:LockManager Wartezeiten führen.

Empfohlene Maßnahme: Legen Sie eine Mindestanzahl von Partitionen fest, die es Ihnen ermöglicht, sowohl die Organisation Ihrer Daten abzuschließen als auch gleichzeitig eine performante Abfrageausführung zu gewährleisten.

Auswirkung: Komplexität der Wartung

Eine sehr hohe Anzahl von Partitionen führt zu Wartungsschwierigkeiten wie der Erstellung und Entfernung vor der Erstellung und Entfernung. Autovacuum behandelt Partitionen wie normale Relationen und muss regelmäßige Säuberungen durchführen, weshalb genügend Mitarbeiter erforderlich sind, um die Aufgabe zu erledigen.

Empfohlene Maßnahme:

  • Stellen Sie sicher, dass Sie Partitionen vorab erstellen, damit die Arbeitslast nicht blockiert wird, wenn eine neue Partition benötigt wird (z. B. monatliche Partitionen) und alte Partitionen gelöscht werden.

  • Stellen Sie sicher, dass Sie über genügend Autovacuum-Mitarbeiter verfügen, um die normale Säuberung und Wartung aller Partitionen durchzuführen.

Ungefährer Schwellenwert: Hunderte

Temporäre Dateien

Im Gegensatz zu den oben genannten temporären Tabellen werden temporäre Dateien von PostgreSQL erstellt, wenn eine komplexe Abfrage mehrere Sortier- oder Hashoperationen gleichzeitig ausführt, wobei jede Operation Instanzspeicher verwendet, um Ergebnisse bis zu dem work_mem im Parameter angegebenen Wert zu speichern. Wenn der Instance-Speicher nicht ausreicht, werden temporäre Dateien erstellt, um die Ergebnisse zu speichern. Weitere Informationen zu temporären Dateien finden Sie unter . Wenn Ihr Workload eine große Anzahl dieser Dateien generiert, kann dies verschiedene Auswirkungen haben.

Auswirkung: Erschöpfung des Dateideskriptors

Fehler: „Keine Dateideskriptoren mehr vorhanden: Zu viele offene Dateien im System; freigeben und erneut versuchen“. Der PostgreSQL-Parameter max_files_per_process bestimmt, wie viele Dateien jeder Prozess öffnen kann. Wenn es eine große Anzahl von Verbindungen gibt, die eine große Anzahl von Tabellen verbinden, ist es möglich, dieses Limit zu erreichen.

Empfohlene Maßnahme:

  • Wenn Sie den Wert des Parameters verringern, max_files_per_process kann dieser Fehler möglicherweise behoben werden. Jeder Prozess und Unterprozess (z. B. parallel Abfrage) kann diese Anzahl von Dateien öffnen, und wenn die Abfragen mehrere Tabellen verbinden, kann dieses Limit ausgeschöpft sein.

  • Reduzieren Sie die Gesamtzahl der Verbindungen und verwenden Sie einen Verbindungspooler wie Amazon RDS Proxy oder andere Lösungen wie PgBouncer. Weitere Informationen finden Sie PgBouncer auf der Website.

Auswirkung: Inode-Erschöpfung

Fehler: „Auf dem Gerät ist kein Speicherplatz mehr vorhanden“. Wenn dies beobachtet wird, wenn viel freier Speicherplatz vorhanden ist, liegt dies daran, dass die Inodes knapp werden. Amazon RDS Enhanced Monitoring bietet Einblick in die verwendeten Inodes und die maximale Anzahl, die für Ihren Host verfügbar ist.

Allgemeine bewährte Methoden:

  • Überwachen Sie die Nutzung Ihrer temporären Dateien mit Performance Insights .

  • Optimieren Sie Abfragen, die umfangreiche temporäre Dateien generieren, um festzustellen, ob es möglich ist, die Gesamtzahl der temporären Dateien zu reduzieren.

Ungefährer Schwellenwert: Tausende

Sequenzen

Sequenzen sind das zugrunde liegende Objekt, das für die automatische Inkrementierung von Spalten in PostgreSQL verwendet wird. Sie bieten Einzigartigkeit und einen Schlüssel für die Daten. Diese können für einzelne Tabellen verwendet werden, ohne dass dies im normalen Betrieb Auswirkungen hat, mit einer Ausnahme der logischen Replikation.

In PostgreSQL repliziert die logische Replikation derzeit den aktuellen Wert einer Sequenz auf keinen Abonnenten. Weitere Informationen finden Sie auf der Seite Einschränkungen in der PostgreSQL-Dokumentation.

Auswirkung: Verlängerte Switchover-Zeit

Wenn Sie Amazon RDS Blue/Green Deployments für jede Art von Konfigurationsänderung oder Upgrade verwenden möchten, ist es wichtig, die Auswirkungen einer hohen Anzahl von Sequenzen auf den Switchover zu verstehen. In einer der letzten Phasen eines Switchovers wird der aktuelle Wert der Sequenzen synchronisiert, und wenn es mehrere Tausend gibt, verlängert sich dadurch die Gesamtswitchover-Zeit.

Empfohlene Maßnahme: Wenn Ihre Datenbank-Arbeitslast die Verwendung einer gemeinsamen UUID anstelle eines sequence-per-table Ansatzes zulassen würde, würde dies den Synchronisationsschritt während eines Switchovers reduzieren.

Ungefährer Schwellenwert: Tausende

Große Objekte

Große Objekte werden in einer einzigen Systemtabelle namens pg_largeobject gespeichert. Jedes große Objekt hat auch einen Eintrag in der Systemtabelle pg_largeobject_metadata. Diese Objekte werden ganz anders erstellt, geändert und bereinigt als Standardbeziehungen. Große Objekte werden nicht mit Autovakuumverfahren behandelt und müssen in regelmäßigen Abständen mit einem separaten Verfahren, dem sogenannten Vacuumlo, gereinigt werden. Beispiele zur Verwaltung großer Objekte finden Sie unter Verwaltung großer Objekte mit dem Modul lo.

Auswirkung: Logische Replikation

Große Objekte werden derzeit während der logischen Replikation nicht in PostgreSQL repliziert. Weitere Informationen finden Sie auf der Seite Einschränkungen in der PostgreSQL-Dokumentation. In einer https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html bedeutet dies, dass große Objekte in der blauen Umgebung nicht in die grüne Umgebung repliziert werden.

Auswirkung: Upgrade der Hauptversion

Bei einem Upgrade kann der Arbeitsspeicher knapp werden und es kann fehlschlagen, wenn Millionen großer Objekte vorhanden sind und die Instanz diese während eines Upgrades nicht verarbeiten kann. Der Upgrade-Prozess für die PostgreSQL-Hauptversion besteht aus zwei großen Phasen: dem Dumping des Schemas über pg_dump und dem Wiederherstellen über pg_restore. Wenn Ihre Datenbank Millionen großer Objekte enthält, müssen Sie sicherstellen, dass Ihre Instanz über ausreichend Speicher verfügt, um pg_dump und pg_restore während eines Upgrades zu verarbeiten, und sie auf einen größeren Instanztyp skalieren.

Allgemeine bewährte Methoden:

  • Verwenden Sie regelmäßig das Programm vacuumlo, um eventuell verwaiste große Objekte zu entfernen.

  • Erwägen Sie, den BYTEA-Datentyp zum Speichern Ihrer großen Objekte in der Datenbank zu verwenden.

Ungefährer Schwellenwert: Millionen

Ungefähre Schwellenwerte

Die in diesem Thema genannten ungefähren Schwellenwerte werden nur verwendet, um abzuschätzen, wie weit eine bestimmte Ressource skaliert werden kann. Sie stellen den allgemeinen Bereich dar, in dem die beschriebenen Auswirkungen wahrscheinlicher werden. Das tatsächliche Verhalten hängt jedoch von Ihrer spezifischen Arbeitslast, Instanzgröße und Konfiguration ab. Auch wenn es möglich sein kann, diese Schätzungen zu übertreffen, müssen Sorgfalt und Wartung eingehalten werden, um die aufgeführten Auswirkungen zu vermeiden.