.png)
In der sich ständig weiterentwickelnden technischen Landschaft von heute, in der Leistung oberste Priorität hat, spielen Datenbanken eine entscheidende Rolle bei der Gewährleistung reibungsloser Benutzererfahrungen und zuverlässiger Anwendungen.
Bei WeWard, wo jede Millisekunde zählt, um die Benutzererfahrung zu verbessern, haben wir uns auf eine ehrgeizige Reise begeben, um PostgreSQL in eine außergewöhnliche Leistungsmaschine zu verwandeln. Dieser Artikel befasst sich mit den Herausforderungen, den implementierten Lösungen und den Best Practices, mit denen wir PostgreSQL erheblich optimieren konnten.
In einer Welt, in der Benutzer sofortige Antwortzeiten erwarten, können langsame Datenbanken zu Frustration und verpassten Chancen führen. Bei WeWard besteht diese Herausforderung in Millionen von täglichen Transaktionen und komplexen Abfragen, die eine einwandfreie Leistung erfordern. Zu unseren Herausforderungen gehörten langsame Abfragen, übermäßige Last und eine Architektur, die eine erhöhte Skalierbarkeit erfordert.
Im Folgenden erfahren Sie, wie wir diese Hindernisse überwunden haben.
Die Grundlage jeder PostgreSQL-Optimierung beginnt mit der Abfrageanalyse. Wir haben Ineffizienzen durch die Untersuchung von Abfrageausführungsplänen identifiziert.
Verwendung von EXPLAIN und ANALYSEhaben wir einen Röntgenblick auf unsere Anfragen erhalten.
Beispiel für eine problematische Abfrage:
SELECT level_customer.*
FROM level_customer
JOIN level ON level.id = level_customer.level_id
WHERE level_customer.customer_id = XXXXXXX
AND level_customer.start_date <= '2024-05-07'::date
AND level.version = 2
ORDER BY level_customer.start_date DESC, level.value DESC
LIMIT 1;
Erkannte Probleme:
Lösung: Indexerstellung:
CREATE INDEX idx_level_customer_customer_date_value
ON level_customer (customer_id, start_date DESC, level_id DESC);
Planer-Anpassung:Wir haben PostgreSQL gezwungen, die Verschachtelte Schleife Join statt der Standardeinstellung Hash Join für diese spezielle Anfrage.
Materialisierte Ansichten:Bei komplexen Abfragen reduzieren materialisierte Ansichten den Berechnungs-Overhead bei jeder Ausführung und sorgen für eine bemerkenswert stabile Leistung.
Da täglich Millionen von Abfragen gestellt werden, haben wir eine auf Replikaten basierende Architektur gewählt, um die Last zu verteilen.
Vorteile:
Technische Überlegungen:
Tabellen mit Milliarden von Zeilen können Lese- und Schreibvorgänge erheblich verlangsamen. Durch Partitionierung wird eine Tabelle in kleinere Teilmengen aufgeteilt, was die Abfrageeffizienz verbessert.
Werkzeug: pg_partman
Vorteile:
Jede PostgreSQL-Verbindung verbraucht Systemressourcen. Um eine Überlastung des Servers zu verhindern:
max_connections wurde auf der Grundlage der verfügbaren Hardware und der Anwendungsanforderungen angepasst.Wichtige PostgreSQL-Speicherparameter:
shared_buffers: Steuert die Speicherzuweisung für die Zwischenspeicherung häufig abgerufener Daten.arbeit_mem: Definiert den Speicher für Sortier- und Hash-Tabellen während der Abfrageausführung.Kritische ("heiße") Daten verbleiben in PostgreSQL, während weniger häufig genutzte ("kalte") Daten an Amazon S3 oder Google Cloud Storage übertragen werden. Die Analyse der kalten Daten wird mit Google BigQuery durchgeführt.
Vorteile:
WeWard verwendet fortschrittliche Überwachungsinstrumente wie z. B.:
Vorteile:
Durch die Kombination von rigoroser Abfrageoptimierung, intelligentem Ressourcenmanagement und modernen Architekturen ist PostgreSQL ein wichtiger Verbündeter für WeWard geworden. Diese Lösungen sind für jede Organisation anwendbar, die das Potenzial der Datenbank maximieren möchte.
💬 Was sind Ihre Strategien zur Optimierung von PostgreSQL? Teilen Sie Ihre Erfahrungen und beteiligen Sie sich an der Diskussion!
👉 Entdecken Sie unsere mobile App: WeWard.
.svg)
.png)
.png)
.png)
.jpg)
.JPG)