pg_local_cache
Deutsch

Ein Zeilen-Cache
in PostgreSQL.

Lesen Sie Zeilen per Primärschlüssel über authentifiziertes RESP MGET. PostgreSQL-Schreibvorgänge invalidieren betroffene Cache-Einträge automatisch.

Lokal ausprobieren Mit SQL vergleichen

Authentifizierte RESP-API · PostgreSQL 14–18 · Open Source

3.1.0 nutzt Byte-Kapazität für Millionen kleiner Schlüssel, wenn das Speicherbudget reicht. Neu sind partitionierte Sperren, allokationsfreie Einzel-Key-Treffer, günstigere Schreibverfolgung und aufgeschobene Fehltreffer bei Relationssperren. Upgrade-Leitfaden.

3.1.0 · finaler Build c431bcc

210kAnfragen/s · RESP MGET

Pro gepinntem physischen Serverkern
Hot Keys · 256 Clients · Go/pgx

Valkey · io-threads=2N
91.5k Anfragen/s
Vorbereitetes SQL
23.2k Anfragen/s
Private 10-GbE-VMs · Xeon Gold 6354 · auf einen physischen Kern gepinnt.
Bei einem Kern erreichte Valkey mit io-threads=1 180k Anfragen/s und benötigte pro Anfrage am wenigsten Server-CPU.
Ergebnisse, Rohdaten und Bedingungen

Ein Aufruf. Zwei Lesepfade.

Ein geeigneter Treffer gibt die gespeicherte Zeile zurück. Ein Fehltreffer oder Bypass liest die Quelltabelle. Ihre gewöhnlichen SELECT-Abfragen behalten ihren bisherigen Pfad.

RESP2 │ Lesevorgänge per Primärschlüssel
-- Attach your table once.
SELECT local_cache.attach_table('public.items');

-- Read rows by primary key.
MGET CRUD:pglc_demo.public.items:{"id":42} CRUD:pglc_demo.public.items:{"id":7}

Node.js-BeispielGo-BeispielRESP-Beispiel

Der RESP-MGET-Lesepfad Die Anwendung sendet authentifiziertes RESP MGET. Ein geeigneter Cache-Treffer gibt die gespeicherte vollständige Zeile zurück. Bei einem Fehltreffer oder Bypass liest die Quelltabelle die konfigurierte Worker-Rolle; die Zeile wird über RESP zurückgegeben. PostgreSQL Anwendung RESP MGET Eignung + Snapshot Treffer Kein Treffer GespeichertZeile QuelleTabelle
Beide Pfade geben vollständige Zeilen über RESP zurück. Ein Lesen aus der Quelltabelle kann den Cache füllen.
Was ein Treffer im Zeilen-Cache vermeidet
RESP MGET

Authentifiziert und auf 1.024 Schlüssel pro Anfrage begrenzt. Fehlende Zeilen geben null zurück.

Gewöhnliche Schreibvorgänge

INSERT, UPDATE und DELETE invalidieren betroffene Einträge.

Feste Kapazität

Allokieren Sie den gemeinsamen Zeilen-Cache beim Start von PostgreSQL.

Prüfung von Fence-Generation und Payload

Nicht geeignete Lesevorgänge verwenden die Quelltabelle gemäß den Sichtbarkeitsregeln von PostgreSQL.

Führen Sie denselben Test aus.
Mit jedem Client.

Node.js und Go. Vorbereitetes SQL und RESP MGET.

Ein Runner verwendet dieselben Schlüssel, Batch-Größen, Verbindungszahlen, Dauer und Ergebnisprüfungen. Vergleichen Sie Durchsatz, Latenz sowie CPU und Speicher von PostgreSQL auf Ihrem Rechner.

Vergleich ausführen

Passt das zu Ihrer Arbeitslast?

Sie wählen einen Cache? Vergleichen Sie PostgreSQL-Seiten, Zeilen, materialisierte Sichten und Redis.

Messung lohnt sich

  • Wiederholte vollständige Primärschlüssel-Lesevorgänge.
  • Eine kleine heiße Menge vollständiger Zeilen.
  • READ COMMITTED auf einem beschreibbaren primären Server.
  • Eine Anwendung, die authentifiziertes RESP MGET verwenden kann.

Gewöhnliches SQL beibehalten

  • Joins, Bereiche, Aggregate oder beliebige Abfrageergebnisse.
  • RLS-, partitionierte oder vererbte Tabellen.
  • Eine Datenbank, in der Sie keine native Erweiterung installieren können.
  • Arbeitslasten ohne gemessenen Nutzen.

Lokale Demo starten.

Klonen Sie das Repository und starten Sie einen verworfenen PostgreSQL-Server mit Beispielzeilen. Docker baut die Erweiterung und hält die Demo von Ihren Datenbanken getrennt.

Git und Docker Compose erforderlich
git clone https://github.com/profundium/pg_local_cache.git
cd pg_local_cache
docker compose -f examples/compose.yaml -f examples/compose.resp.yaml up --build --wait

Beispielzeilen lesen und Cache-Treffer prüfen. Repository bereits geklont? Führen Sie den letzten Befehl aus dessen Stammverzeichnis aus. Für einen vorhandenen Server verwenden Sie den Installationsleitfaden.

Die Installation auf einem vorhandenen Server erfordert einen Neustart von PostgreSQL.

Dokumentation

pg_local_cache lokal ausprobierenFühren Sie pg_local_cache 3.1.0 in einem temporären PostgreSQL aus, lesen Sie Beispielzeilen über RESP, prüfen Sie Cache-Treffer, testen Sie Aktualisierungen und entfernen Sie die Demo, ohne eine bestehende Datenbank zu ändern. pg_local_cache auf PostgreSQL 14–18 installierenInstallieren Sie ein geprüftes Debian- oder RPM-Paket, verwenden Sie PGXN oder PGXS, konfigurieren Sie Preload, starten Sie PostgreSQL neu und initialisieren, aktualisieren oder entfernen Sie pg_local_cache. RESP-ClientsRedis-kompatible Clients über RESP2 mit pg_local_cache verbinden: MGET, Token-Authentifizierung und natives TLS. PostgreSQL-Cache-Benchmarks, 3.1.0pg_local_cache 3.1.0-Ergebnisse auf zwei Maschinen: gepinnte und vollständige Leseläufe, Schreibkosten, Lesen während Schreibvorgängen und Methodik. Technische Referenz für pg_local_cacheReferenz zu RESP-Lesevorgängen, unterstützten Tabellen, Transaktionssperren, TLS, Shared Memory, Metriken und PostgreSQL-Einstellungen. pg_local_cache auf 3.1.0 aktualisierenpg_local_cache von 3.0.0 oder 2.x aktualisieren, Kapazitäts- und Worker-Einstellungen für 3.1 prüfen und die Erweiterung nach dem Neustart verifizieren. Leitfaden zur PostgreSQL-Caching-EntscheidungVergleichen Sie PostgreSQL-Seiten-Caching, vorbereitetes SQL, vollständiges Zeilen-Caching, materialisierte Sichten und Redis danach, welche Arbeit der jeweilige Leseweg vermeidet. Batch-Abfragen von PostgreSQL per PrimärschlüsselErfahren Sie, wie Sie N+1-Lesezugriffe per Primärschlüssel vermeiden und vollständige Zeilen mit authentifiziertem RESP MGET gebündelt lesen. Cache-aside mit PostgreSQL und RedisVergleichen Sie anwendungsverwaltetes Redis-Cache-aside mit RESP-Lesevorgängen von pg_local_cache, einschließlich veralteter Cache-Befüllungen und Schreibinvalidierung. PostgreSQL-Zeilen-Cache im Vergleich zu shared_buffersVergleichen Sie PostgreSQL-Seiten-Caching mit dem Caching vollständiger Zeilen durch pg_local_cache: vermiedene Quellarbeit, Cache-Kosten und Arbeitslasten, die gewöhnliches SQL verwenden sollten. Transaktionsbewusste Cache-Invalidierung in PostgreSQLSo sichern PostgreSQL-Trigger RESP-Zeilen-Lesevorgänge über Commit, Rollback und gleichzeitige Cache-Befüllungen hinweg ab.

Praxisnotizen zum PostgreSQL-Caching

Alle Artikel →

Vor dem Ausprobieren

Ersetzt das shared_buffers?

Nein. PostgreSQL cached Datenbankseiten. Diese Erweiterung cached separat serialisierte vollständige Zeilen per Primärschlüssel. Siehe den Vergleich der Lesepfade.

Cached es gewöhnliche SELECT-Abfragen?

Nein. Nur authentifiziertes RESP MGET verwendet den gemeinsamen Zeilen-Cache. Bestehende Abfragen behalten den normalen PostgreSQL-Ausführungspfad.

Ersetzt es Redis?

Nein. Der RESP2-Endpunkt ist begrenzt. Es gibt weder einen allgemeinen Redis-Befehlssatz noch TTL, Pub/Sub oder verteilte Koordination. Vergleichen Sie die PostgreSQL- und Redis-Cache-aside-Pfade.

Wie prüfe ich Updates und Rollback?

Der Invalidation-Leitfaden erklärt Schreibvorgänge. Der Upgrade-Leitfaden behandelt den Wechsel von 3.0.0 zu 3.1.0 und die frühere Migration von 2.x.