Die Percolator Query: umgekehrte Suche in Elasticsearch implementieren

1. Grundprinzip: Suchanfragen als Dokumente, Dokumente als Anfragen

Bei einer klassischen Suche liegt eine feste Menge an Dokumenten im Index, und eine Suchanfrage wird gegen diese Menge ausgewertet, um die relevantesten Treffer zu finden. Der Percolator dreht dieses Verhältnis um: Statt Dokumente gegen eine Anfrage zu prüfen, werden Suchanfragen selbst als Dokumente in einem Index gespeichert, und ein neu eintreffendes Dokument wird gegen alle gespeicherten Anfragen geprüft. Das Ergebnis ist keine sortierte Trefferliste von Produkten, sondern eine Liste von gespeicherten Anfragen, die auf das eine neue Dokument zutreffen würden.

Diese Umkehrung ist immer dann sinnvoll, wenn die Anzahl der Suchkriterien deutlich größer ist als die Anzahl der neu eintreffenden Dokumente pro Zeiteinheit, etwa bei Preisalarmen, Sättigungsbenachrichtigungen für Lagerbestände oder Content-Moderation-Regeln, die auf jeden neuen Beitrag angewendet werden müssen. Eine naive Implementierung würde bei jedem neuen Dokument alle gespeicherten Kriterien einzeln in der Anwendung durchgehen, was bei vielen tausend Kriterien schnell zu einem Flaschenhals wird.

2. Der percolator-Feldtyp und wie gespeicherte Queries indexiert werden

Um Percolate Queries zu nutzen, benötigt der Index ein Feld vom Typ percolator, in dem die eigentliche Query-DSL-Definition als Wert gespeichert wird. Elasticsearch analysiert diese gespeicherte Query beim Indexieren und extrahiert daraus effizient durchsuchbare Merkmale, sodass beim späteren Percolieren nicht jede gespeicherte Query naiv einzeln ausgewertet werden muss, sondern zunächst eine Vorauswahl möglicher Kandidaten über einen internen Index stattfindet.

Neben dem percolator-Feld selbst müssen alle Felder, auf die sich die gespeicherten Queries beziehen könnten, im selben Index oder in einem Index mit kompatiblem Mapping vorhanden sein, damit Elasticsearch die Query-Struktur korrekt gegen ankommende Dokumente auswerten kann. In der Praxis legt man dafür häufig einen dedizierten Index mit zwei logischen Dokumenttypen an: gespeicherte Kundenkriterien einerseits und ein Beispiel-Mapping der Produktfelder andererseits.

PUT /preisalarme
{
  "mappings": {
    "properties": {
      "query": { "type": "percolator" },
      "kategorie": { "type": "keyword" },
      "preis": { "type": "float" },
      "marke": { "type": "keyword" }
    }
  }
}

PUT /preisalarme/_doc/kunde_4711
{
  "query": {
    "bool": {
      "filter": [
        { "term": { "kategorie": "werkzeuge" } },
        { "range": { "preis": { "lte": 49.90 } } }
      ]
    }
  }
}

3. Eine Percolate Query gegen ein neues Dokument ausführen

Trifft ein neues Produkt ein, wird es nicht in den Index für gespeicherte Anfragen geschrieben, sondern als Bestandteil einer percolate-Query an Elasticsearch übergeben. Die Antwort enthält die IDs aller gespeicherten Anfragen, deren Kriterien das übergebene Dokument erfüllen. Diese IDs kann die Anwendung anschließend nutzen, um zum Beispiel die hinterlegte Kunden-ID zu ermitteln und eine Benachrichtigung auszulösen.

Wichtig ist, dass die Percolate Query kein neues Dokument dauerhaft speichert, sondern es nur temporär für die Dauer der Anfrage gegen die gespeicherten Queries hält. Das eigentliche Speichern des neuen Produkts im regulären Produktindex bleibt ein separater, unabhängiger Vorgang.

GET /preisalarme/_search
{
  "query": {
    "percolate": {
      "field": "query",
      "document": {
        "kategorie": "werkzeuge",
        "preis": 39.90,
        "marke": "ProTools"
      }
    }
  }
}
// Antwort liefert kunde_4711 als Treffer, da Kategorie und Preis passen

4. Anwendungsfall: Preisalarme und Sättigungsbenachrichtigungen umsetzen

Für Preisalarme legt jeder Kunde beim Anlegen seiner Benachrichtigung ein Dokument im Percolator-Index an, das seine individuellen Kriterien als Query-DSL abbildet, etwa gewünschte Kategorie, maximaler Preis und optional bevorzugte Marken. Beim Import neuer Produkte oder bei Preisänderungen bestehender Produkte wird jedes betroffene Produktdokument einmal gegen den Percolator-Index geprüft. Jeder Treffer entspricht einem Kunden, der über das neue oder geänderte Angebot informiert werden soll.

Das gleiche Muster funktioniert für Sättigungsbenachrichtigungen bei Lagerbeständen: Ein Vertriebsmitarbeiter hinterlegt eine Regel wie Lagerbestand einer bestimmten Kategorie unterschreitet einen Schwellenwert, und jede eingehende Bestandsänderung wird als Dokument gegen diese gespeicherten Regeln percoliert. So entsteht ein flexibles Alerting-System, ohne dass für jede Regel eigener Anwendungscode geschrieben werden muss, da die gesamte Bedingungslogik in Query-DSL formuliert und zentral verwaltet wird.

5. Mehrere Dokumente gleichzeitig percolieren

Statt für jedes neue Produkt einzeln eine Percolate Query abzusetzen, unterstützt Elasticsearch das Percolieren mehrerer Dokumente in einer einzigen Anfrage über das Array documents. Das reduziert den Netzwerk-Overhead deutlich, wenn zum Beispiel ein Import-Batch mit mehreren hundert neuen Produkten auf einmal gegen alle gespeicherten Preisalarme geprüft werden soll, statt für jedes einzelne Produkt eine eigene Anfrage über das Netzwerk zu schicken.

Die Antwort ordnet jeden Treffer über ein internes Feld dem jeweiligen ursprünglichen Dokument zu, sodass die Anwendung nach einer einzigen Batch-Anfrage genau weiß, welches Produkt welche gespeicherten Kriterien erfüllt hat. Für regelmäßige Batch-Importe, wie sie bei Produktfeeds üblich sind, ist dieser Ansatz einer Schleife mit einzelnen Anfragen praktisch immer vorzuziehen.

6. Performance-Grenzen bei sehr vielen gespeicherten Queries

Der Percolator skaliert gut mit der Anzahl neu eintreffender Dokumente, da die interne Vorauswahl über extrahierte Query-Merkmale die Zahl der tatsächlich vollständig ausgewerteten Kandidaten-Queries deutlich reduziert. Bei einer sehr großen Zahl gespeicherter Queries, etwa mehreren Millionen individueller Kundenkriterien, wächst dennoch der Aufwand für diese Vorauswahl selbst, und die Latenz einer einzelnen Percolate-Anfrage steigt spürbar an.

Besonders kritisch werden sehr generische gespeicherte Queries, die kaum extrahierbare Merkmale liefern, etwa eine Query ohne konkrete Term-Filter, sondern nur mit Bereichsbedingungen auf einem stark schwankenden Feld. Solche Queries lassen sich intern kaum vorfiltern und müssen häufiger vollständig ausgewertet werden. In der Praxis empfiehlt es sich deshalb, den Percolator-Index nach Kategorien oder Regionen zu partitionieren und nur den jeweils relevanten Teilindex zu percolieren, statt bei jedem neuen Dokument grundsätzlich alle gespeicherten Queries zu prüfen.

7. Wartung: Aktualisieren und Bereinigen gespeicherter Suchanfragen

Gespeicherte Percolate Queries verhalten sich wie normale Dokumente und lassen sich entsprechend über die Update-API ändern oder löschen, etwa wenn ein Kunde seinen Preisalarm anpasst oder deaktiviert. Da jede gespeicherte Query im internen Vorauswahl-Index Platz beansprucht, lohnt sich eine regelmäßige Bereinigung abgelaufener oder inaktiver Kriterien, insbesondere bei zeitlich befristeten Aktionen wie einem saisonalen Preisalarm.

Für Alarme mit fester Gültigkeitsdauer bietet sich eine Kombination mit Index-Lifecycle-Management oder einem einfachen TTL-Feld an, das per geplantem Job abgelaufene Dokumente aus dem Percolator-Index entfernt. Ohne diese Pflege wächst der Index dauerhaft, was sich unmittelbar auf die Latenz jeder einzelnen Percolate-Anfrage auswirkt.

8. Abgrenzung zu Alternativen: Watcher und externe Regel-Engines

Der Percolator eignet sich für den konkreten Abgleich eines einzelnen neuen Dokuments gegen viele gespeicherte Kriterien, ist aber kein vollständiges Alerting-Framework mit Zeitplanung, Benachrichtigungskanälen oder Eskalationslogik. Für periodische Prüfungen über einen ganzen Datenbestand hinweg, etwa eine tägliche Zusammenfassung aller Preisänderungen, ist eher Watcher oder eine externe Scheduler-Lösung geeignet, die den Percolator lediglich als einen Baustein innerhalb einer größeren Pipeline nutzt.

Gegenüber einer komplett eigenen Regel-Engine in der Anwendung bietet der Percolator den Vorteil, dass die komplette Match-Logik in der bewährten Elasticsearch-Query-DSL formuliert wird und von derselben Infrastruktur profitiert, die ohnehin für die reguläre Produktsuche betrieben wird. Für sehr komplexe, mehrstufige Regelwerke mit Zustandsverwaltung zwischen mehreren Ereignissen stößt der Percolator dagegen an konzeptionelle Grenzen, da er grundsätzlich zustandslos jeweils ein einzelnes Dokument gegen gespeicherte Queries prüft.

9. Einführung in der Praxis: eine kurze Checkliste

Vor dem produktiven Einsatz lohnt sich ein Testlauf mit realistischer Anzahl gespeicherter Queries und realistischem Dokumentvolumen, um die tatsächliche Latenz unter Last zu messen, statt sich auf Annahmen zu verlassen. Ebenso wichtig ist ein klares Monitoring der Percolator-Indexgröße, damit ein unkontrolliertes Wachstum gespeicherter, aber längst irrelevanter Queries frühzeitig auffällt.

Wer den Percolator gezielt für einen klar abgegrenzten Anwendungsfall wie Preisalarme einsetzt, regelmäßig abgelaufene Queries bereinigt und bei Bedarf nach Kategorie oder Region partitioniert, erhält ein robustes und gut wartbares Alerting-System, das ohne zusätzliche externe Komponenten auskommt und direkt auf der bereits vorhandenen Elasticsearch-Infrastruktur aufsetzt.

10. Zusammenfassung

11. FAQ: Percolator Query: Das Wichtigste auf einen Blick