Gebündelte PostgreSQL-Abfragen per Primärschlüssel
Dieser Leitfaden zeigt, wie RESP-MGET-Batches einen Datenbankaufruf pro Schlüssel vermeiden und die Ergebnispositionen beibehalten.
N+1-Lesezugriffe vermeiden
Wenn eine Anwendung pro ID eine Zeile abruft, folgen auf die erste Abfrage N Lesezugriffe auf die Quelle. Fassen Sie die bekannten Primärschlüssel in einem MGET zusammen, um eine begrenzte Batch-Anfrage zu senden. Das eignet sich für wiederholte Abrufe vollständiger Zeilen; beliebige SQL-Abfragen werden dadurch nicht gecacht, und Joins oder Projektionen werden nicht ersetzt.
Ergebnisvertrag
MGET key [key ...] liefert ein Array-Element je Eingabeschlüssel und erhält dabei die Reihenfolge. Duplikate bleiben erhalten. Für fehlende Zeilen liefert die Antwort nil. Ein Schlüssel hat das Format CRUD:<db>.<schema>.<table>:<json pk>; Kodierung und ausführbare Beispiele stehen unter RESP-Clients.
Wann MGET passt
Ein Befehl akzeptiert bis zu 1.024 Schlüssel. Die codierte Antwort ist auf 66.560 Byte begrenzt. Bei großen Zeilen kann daher auch ein Batch mit wenigen Schlüsseln zu groß sein. Teilen Sie Anfragen nach Schlüsselzahl und erwarteter Nutzlast auf. Eine zu große Antwort führt zu einem Fehler statt zu einem unvollständigen Array.
Für Filter, Joins, Zeilensperren, Projektionen und Lesezugriffe innerhalb derselben Transaktion eignet sich gewöhnliches SQL besser. Den Vergleich von Quellabfrage und RESP beschreibt der Leitfaden zur Cache-Invalidierung sowie die technische Referenz.
Die SQL-Funktion local_cache.mget(regclass, anyarray) aus 2.x wurde in 3.0.0 entfernt; siehe den Upgrade-Leitfaden.
Aktualisiert .