PostgreSQL-Zeilen-Cache im Vergleich zu shared_buffers
PostgreSQLs shared_buffers
enthält Datenbankseiten. pg_local_cache speichert separat serialisierte
vollständige Zeilen-Payloads unter ihren vollständigen Primärschlüsseln. Eine
bereits im Speicher befindliche Seite kann einen Speicherzugriff vermeiden,
aber eine Abfrage muss weiterhin aus den Datenbank-Tupeln ein Ergebnis erzeugen.
Ein Treffer im Zeilen-Cache kann die gespeicherte Payload nach Eignungs- und
Snapshot-Prüfungen zurückgeben.
Auch das Betriebssystem kann Dateiinhalte cachen. Verwenden Sie eine aufgewärmte Datenbank als Baseline.
Cached PostgreSQL SELECT-Ergebnisse?
shared_buffers cached die von einer Abfrage verwendeten Seiten statt ihres
endgültigen Ergebnissatzes. Ein vorbereitetes Statement verwendet
Parse-Arbeit wieder und kann einen Plan wiederverwenden, aber PostgreSQL führt
es weiterhin aus. pg_local_cache fügt über explizite mget-Aufrufe das Caching
vollständiger Zeilen hinzu; beliebige SELECT-Ergebnisse werden nicht gecached
und bestehende Abfragen nicht umgeschrieben. Das Node.js-Beispiel
zeigt beide Lese-APIs nebeneinander.
Arbeit vergleichen, nicht nur das Speichermedium
| Lesen | Verbleibende Arbeit |
|---|---|
| Vorbereitetes Primärschlüssel-SQL über aufgewärmte Seiten | Protokollverarbeitung, Planausführung, Prüfung der Zeilensichtbarkeit und Ergebnisumwandlung |
| Geeigneter SQL-mget-Cache-Treffer | Protokollverarbeitung, Ausführung der SQL-Funktion, Schlüsselumwandlung, Cache-Synchronisierung, Snapshot-Prüfungen und Rückgabe der gespeicherten Payload |
| SQL-mget-Fehltreffer oder Bypass | Prüfungen der Funktion plus Quelltabellenabfrage; ein erfolgreicher geeigneter Fill kann den Cache füllen |
Ein Treffer im Zeilen-Cache vermeidet die wiederholte Ausführung der Quelltabelle und die Serialisierung der vollständigen Zeile. Cache-Prüfungen und Synchronisierung verbrauchen ebenfalls CPU, und ein Treffer verwendet weiterhin eine PostgreSQL-Verbindung und ein Backend. Diese SQL-API beseitigt weder Verbindungsgrenzen noch Warteschlangen im Verbindungspool.
Einzubeziehende Kosten
Eine gecachte Zeile benötigt zusätzlichen Shared Memory, selbst wenn ihre Quellseite bereits im Speicher liegt. Die Erweiterung verwaltet außerdem Zuordnungs- und Invalidation-Zustand. Updates an angehängten Tabellen führen die Trigger der Erweiterung aus. Wenn die Arbeitsmenge die Kapazität überschreitet, kann eine scheinbare Leseoptimierung überwiegend aus Fehltreffern und Verdrängungsaufwand bestehen.
Die Standarddemo vergleicht bewusst eine heiße Menge von 128 Zeilen mit 1.024 Cache-Slots und anschließend einen ersten Durchlauf über 4.096 Zeilen. Der Benchmark-Leitfaden erklärt beide Fälle und misst Schreibvorgänge an angehängten Tabellen separat.
Wann die Anwendung unverändert bleiben sollte
Behalten Sie die bestehende Abfrage bei, wenn ihre End-to-End-Latenz bereits akzeptabel ist, wenn die Anwendung nur eine kleine Projektion einer großen Zeile benötigt oder wenn Joins, Bereiche und Aggregation dominieren. Vergleichen Sie zuerst eine gewöhnliche Batch-Abfrage mit den aktuellen Aufrufen pro Schlüssel in der Anwendung. Ein Gewinn durch Batching ist kein Beleg für einen Gewinn durch Caching.
pg_local_cache 2.0 erfordert explizite mget-Aufrufe, die Installation der
Erweiterung und ein Preload beim Start. RLS-, partitionierte und vererbte
Tabellen werden abgelehnt.
Zeilen-Cache oder externer Cache?
Für Daten, die in PostgreSQL maßgeblich bleiben, hält dieses Design die Invalidation im Datenbank-Schreibpfad und vermeidet ein eigenes Cache-aside-Protokoll der Anwendung. Es bietet keine allgemeine Redis-Semantik. Der optionale RESP2-Endpunkt hat einen begrenzten Befehlssatz und ein eigenes Sicherheitsmodell.
Ein PostgreSQL-Zeilen-Cache kann anwendungsseitigen Zustand mit TTL, Pub/Sub oder verteilter Koordination nicht ersetzen. Siehe den technischen Vertrag und die Transaktionsbeispiele.
Aktualisiert .