Leitfaden zur PostgreSQL-Caching-Entscheidung
Dieser Leitfaden vergleicht PostgreSQL-Seiten-Caching, vorbereitetes SQL, Caching vollständiger Zeilen, materialisierte Sichten und Redis danach, welche Arbeit die jeweilige Option vermeidet.
Beginnen Sie mit der wiederholten Arbeit
| Bedarf | Option | Vermiedene Arbeit |
|---|---|---|
| Tabellen- und Indexseiten im Speicher halten | PostgreSQL shared_buffers und OS-Cache |
Lesezugriffe auf den Speicher; SQL wird weiterhin ausgeführt |
| Ein Statement in einer Sitzung wiederholen | Vorbereitetes Statement | Wiederholtes Parsen und Analysieren |
| Vollständige Zeilen anhand des Primärschlüssels lesen | Authentifiziertes RESP-MGET mit pg_local_cache |
Geeignete Lesevorgänge vollständiger Zeilen aus der Quelle |
| Joins oder Aggregate wiederverwenden | Materialisierte Sicht | Erneute Berechnung des gespeicherten Abfrageergebnisses bis zur Aktualisierung |
| Objekte über Services hinweg teilen | Redis-Cache-aside | Von der Anwendung verwaltete Lesevorgänge aus der Quelle |
Seiten und vorbereitetes SQL
shared_buffers cached Datenbankseiten, keine fertigen SELECT-Ergebnisse. PostgreSQL prüft weiterhin die Sichtbarkeit, führt die Abfrage aus und erstellt jedes Ergebnis. Ein vorbereitetes Statement reduziert wiederholtes Parsen; es wird weiterhin mit dem aktuellen Datenbankzustand ausgeführt.
Der Vergleich Zeilen-Cache oder shared_buffers zeigt, welche Arbeit auf den beiden Lesewegen verbleibt.
Vollständige Zeilen anhand des Primärschlüssels
pg_local_cache speichert vollständige Zeilen im begrenzten Shared Memory von PostgreSQL. Ein authentifiziertes RESP-MGET kann eine geeignete gecachte Zeile zurückgeben; gewöhnliches SQL liest diesen Cache nie. Fehlt ein Eintrag oder ist der Lesevorgang nicht geeignet, wird die Quelltabelle verwendet. Der Endpunkt verwendet eine konfigurierte Datenbankrolle und teilt weder SQL-Transaktion noch Snapshot des Aufrufers. Siehe den Batch-Leitfaden, die technische Referenz und den Leitfaden zur Invalidierung.
Sichten und externe Caches
Eine PostgreSQL-materialisierte Sicht speichert ein Abfrageergebnis und wird bei Bedarf aktualisiert. Sie eignet sich für Berichte und Aggregate, bei denen der Aktualisierungszeitpunkt die Frische bestimmt.
Redis eignet sich für Anwendungsobjekte, die über mehrere Prozesse geteilt werden. Die Anwendung verwaltet Schlüssel, Serialisierung, TTLs und Invalidierung. Siehe PostgreSQL und Redis mit Cache-aside. Mit dem Schnellstart können Sie den Zeilen-Cache ausprobieren.
Aktualisiert .