Die Point-in-Time-API für konsistente Paginierung in Elasticsearch

1. Das Problem: tiefe Paginierung mit from und size

Die einfache Paginierung über from und size verlangt von Elasticsearch bei jeder Anfrage, alle Treffer bis zur angeforderten Position vollständig zu sortieren und zu materialisieren, selbst wenn nur eine kleine Teilmenge davon tatsächlich zurückgegeben wird. Bei Seite eins bedeutet das kaum Mehraufwand, bei Seite zweihundert mit fünfzig Treffern pro Seite müssen bereits zehntausend Dokumente sortiert werden, bevor die eigentlich gewünschten fünfzig geliefert werden. Ab einer bestimmten Tiefe verweigert Elasticsearch solche Anfragen standardmäßig sogar komplett, gesteuert über die Einstellung index.max_result_window.

Ein zweites, subtileres Problem betrifft die Konsistenz: Wird zwischen dem Abruf von Seite eins und Seite zwei ein neues Dokument eingefügt, das in die Sortierung vor die aktuelle Position fällt, verschieben sich alle nachfolgenden Treffer um eine Position. Das Ergebnis sind doppelt gelieferte oder komplett übersprungene Dokumente, ein Problem, das bei einem stabilen Exportlauf über einen sich aktiv ändernden Index praktisch unvermeidlich auftritt.

2. Einen Point-in-Time-Snapshot erzeugen

Ein Point in Time wird über einen eigenen Endpunkt geöffnet und liefert eine pit_id zurück, die in nachfolgenden Suchanfragen anstelle des Indexnamens verwendet wird. Intern hält Elasticsearch dafür die relevanten Segmente der beteiligten Shards fest, sodass spätere Suchanfragen gegen exakt den Datenstand zum Zeitpunkt der Erzeugung des Snapshots ausgewertet werden, unabhängig davon, welche Schreiboperationen währenddessen auf dem Live-Index stattfinden.

Der Parameter keep_alive legt fest, wie lange Elasticsearch die für den Snapshot benötigten Segmente vorhält, bevor sie automatisch freigegeben werden. Jede Suchanfrage, die den Point in Time verwendet, verlängert dieses Zeitfenster automatisch um den angegebenen Wert, sodass ein aktiver Exportlauf nicht durch ein festes Zeitlimit abbricht, solange er regelmäßig weitere Anfragen stellt.

POST /produkte/_pit?keep_alive=2m

// Antwort:
{
  "id": "46ToAwMDaWR5BXV1aWQyKwZub2RlXzMAAAAAAAAAACoBYQ..."
}

3. search_after mit Point in Time kombinieren

Für die eigentliche Paginierung wird der Point in Time in das pit-Objekt der Suchanfrage eingebettet, während search_after den Sortierwert des letzten Dokuments der vorherigen Seite übergibt. Elasticsearch überspringt dadurch das teure vollständige Sortieren bis zur gewünschten Position und springt effizient direkt zum nächsten passenden Bereich, was auch bei sehr tiefer Paginierung eine annähernd konstante Antwortzeit ermöglicht.

Damit search_after eindeutige Ergebnisse liefert, muss die Sortierung um ein eindeutiges Tie-Breaker-Feld ergänzt werden, üblicherweise _shard_doc oder die Dokument-ID, da sonst bei identischen Sortierwerten mehrerer Dokumente die Reihenfolge nicht deterministisch wäre und Dokumente doppelt erscheinen oder fehlen könnten.

GET /_search
{
  "size": 100,
  "query": { "term": { "kategorie": "werkzeuge" } },
  "pit": { "id": "46ToAwMDaWR5BXV1aWQyKwZub2RlXzMA...", "keep_alive": "2m" },
  "sort": [
    { "preis": "asc" },
    { "_shard_doc": "asc" }
  ],
  "search_after": [39.90, 184023]
}

4. Unterschied zum klassischen Scroll-Mechanismus

Der ältere Scroll-Mechanismus erzeugt ebenfalls einen konsistenten Snapshot, hält dafür aber pro aktivem Scroll-Kontext zusätzlichen internen Zustand auf jedem beteiligten Shard vor, der sich mit der Anzahl gleichzeitig offener Scrolls summiert und spürbaren Speicherdruck erzeugen kann. Scroll wurde ursprünglich für lange laufende, aber im Wesentlichen sequenzielle Exportvorgänge entworfen und ist explizit nicht für interaktive Paginierung mit wechselnden Sortierkriterien gedacht.

Point in Time in Kombination mit search_after ist deutlich ressourcenschonender, da der Snapshot-Zustand leichter ist und sich zudem flexibel mit unterschiedlichen Suchanfragen gegen denselben Snapshot kombinieren lässt, etwa um verschiedene Filter oder Sortierungen auf demselben konsistenten Datenstand anzuwenden. Elastic empfiehlt Point in Time deshalb inzwischen als bevorzugten Ersatz für Scroll bei den allermeisten Anwendungsfällen, die einen stabilen Snapshot benötigen.

5. Keep-Alive-Verhalten und Ressourcenverbrauch im Detail

Jeder offene Point in Time bindet Segmente auf den beteiligten Shards, die Elasticsearch normalerweise im Rahmen von Merges freigeben und löschen würde. Solange der Snapshot aktiv ist, bleiben diese Segmente erhalten, was bei sehr lange offenen Point-in-Time-Kontexten und gleichzeitig hoher Schreiblast zu wachsendem Speicherplatzbedarf auf Platte führen kann, da gelöschte oder überschriebene Dokumente im alten Segment weiterhin physisch vorhanden bleiben müssen.

Ein sinnvoller keep_alive-Wert orientiert sich an der erwarteten Dauer zwischen zwei aufeinanderfolgenden Anfragen zuzüglich einer Sicherheitsmarge, nicht an der Gesamtdauer des gesamten Exportvorgangs. Da jede Anfrage das Zeitfenster automatisch verlängert, reicht in der Regel ein deutlich kürzerer Wert als die erwartete Gesamtlaufzeit, wichtig ist nur, dass zwischen zwei Anfragen nicht mehr Zeit vergeht als der konfigurierte Wert.

6. Praxisbeispiel: eine robuste Exportfunktion mit vielen Ergebnissen

Eine typische Exportfunktion öffnet zu Beginn einen Point in Time, führt anschließend in einer Schleife wiederholt Suchanfragen mit steigendem search_after-Wert aus und schreibt jede Ergebnisseite direkt in eine Ausgabedatei oder einen Stream, statt alle Ergebnisse im Anwendungsspeicher zu sammeln. Sobald eine Antwort weniger Treffer als die angeforderte Seitengröße enthält, ist das Ende der Ergebnismenge erreicht und die Schleife kann beendet werden.

Nach Abschluss des Exports sollte der Point in Time explizit über einen DELETE-Aufruf geschlossen werden, statt sich ausschließlich auf den automatischen Ablauf des keep_alive-Zeitfensters zu verlassen. Das gibt die gebundenen Segmente sofort frei, statt bis zum Timeout zu warten, und ist besonders bei Exportfunktionen wichtig, die häufig und mit vielen gleichzeitigen Läufen ausgeführt werden.

// Nach erfolgreichem Export: Point in Time schließen
DELETE /_pit
{
  "id": "46ToAwMDaWR5BXV1aWQyKwZub2RlXzMA..."
}

7. Fehlerbehandlung: abgelaufene oder ungültige Point-in-Time-IDs

Läuft das keep_alive-Zeitfenster ab, etwa weil ein Exportprozess unerwartet lange pausiert oder abgestürzt ist, schlägt jede weitere Suchanfrage mit dieser Point-in-Time-ID fehl. Eine robuste Implementierung sollte diesen Fehlerfall erkennen und dann entscheiden, ob der Export mit einem frischen Point in Time komplett neu gestartet wird oder ob ein Neustart ab der zuletzt erfolgreich verarbeiteten Position sinnvoll ist, was jedoch die Konsistenzgarantie des ursprünglichen Snapshots aufgibt.

Bei verteilten Exportprozessen, die mehrere Point-in-Time-Kontexte parallel offen halten, lohnt sich zusätzlich ein Monitoring über die Cluster-Statistiken, welche die Anzahl aktuell offener Point-in-Time-Kontexte ausweisen, um vergessene oder nicht korrekt geschlossene Snapshots frühzeitig zu erkennen, bevor sie unnötig Ressourcen binden.

8. Wann sich from/size, Scroll oder Point in Time jeweils eignen

Für flache, interaktive Paginierung mit wenigen Seiten, wie sie eine typische Trefferliste in einer Weboberfläche benötigt, bleibt die einfache from/size-Paginierung die pragmatischste Wahl, da sie ohne zusätzlichen Zustand auskommt und für die ersten Seiten performant genug ist. Sobald jedoch tiefe Paginierung, vollständige Datenexporte oder Batch-Verarbeitung über den gesamten Index gefragt sind, ist Point in Time mit search_after die technisch überlegene und von Elastic empfohlene Lösung.

Der klassische Scroll-Mechanismus bleibt zwar weiterhin funktionsfähig, gilt aber inzwischen als Legacy-Ansatz, dessen Einsatz nur noch in bestehenden Systemen sinnvoll ist, die bereits darauf aufbauen. Für neue Implementierungen führt an Point in Time in Kombination mit search_after kaum ein Weg vorbei, sobald konsistente Deep-Pagination erforderlich ist.

9. Best Practices für den produktiven Einsatz

Ein knapp bemessener, aber ausreichender keep_alive-Wert, das explizite Schließen jedes Point in Time nach Abschluss der Verarbeitung und eine korrekte, eindeutige Sortierung mit Tie-Breaker-Feld bilden zusammen die Grundlage für einen zuverlässigen Einsatz. Wichtig ist außerdem, dass Anwendungscode auf abgelaufene Point-in-Time-IDs vorbereitet ist und nicht blind davon ausgeht, dass ein einmal geöffneter Snapshot beliebig lange verfügbar bleibt.

Regelmäßiges Monitoring der offenen Point-in-Time-Kontexte über die Cluster-Statistiken hilft, vergessene Snapshots frühzeitig zu erkennen, bevor sie unnötig Speicherplatz auf den beteiligten Shards binden. Mit diesen Maßnahmen liefert Point in Time eine robuste, ressourcenschonende Grundlage für jede Anwendung, die große Ergebnismengen konsistent und vollständig verarbeiten muss.

10. Zusammenfassung

11. FAQ: Point-in-Time-API: Das Wichtigste auf einen Blick