Die Rollover-API: praktische Strategien für wachsende Indizes

1. Warum ein einzelner, ewig wachsender Index problematisch ist

Ein Index, der über Jahre ohne Unterbrechung wächst, sammelt gleich mehrere strukturelle Probleme an. Die Shard-Anzahl wird beim Anlegen eines Index festgelegt und lässt sich später nicht mehr ohne Weiteres ändern, weshalb ein zu klein dimensionierter Index bei starkem Wachstum irgendwann an eine harte Obergrenze pro Shard stößt. Zusätzlich werden Wartungsaufgaben wie Snapshots, Reindexierungen oder Mapping-Änderungen mit wachsender Indexgröße zunehmend aufwendiger und riskanter, da ein Fehler dabei potenziell den gesamten historischen Datenbestand betrifft.

Rollover löst dieses Problem, indem es die Datenmenge in mehrere, überschaubare, zeitlich oder größenbasiert abgegrenzte physische Indizes aufteilt. Jeder einzelne dieser Indizes bleibt klein genug, um Wartungsaufgaben schnell und risikoarm durchzuführen, während die Gesamtmenge der Daten über eine Alias-Struktur weiterhin als ein logisch zusammenhängender Datenbestand abfragbar bleibt.

2. Rollover-Grundprinzip: Schreibalias plus Bedingungsprüfung

Der Rollover-Mechanismus setzt auf einem beschreibbaren Alias auf, der zunächst auf genau einen physischen Index zeigt, der als write index markiert ist. Ein Rollover-Aufruf prüft die konfigurierten Bedingungen gegen den aktuell aktiven Index und legt, sofern mindestens eine Bedingung erfüllt ist, einen neuen physischen Index mit einem hochgezählten Namen an. Anschließend hängt Elasticsearch den Schreibalias automatisch auf den neuen Index um, während der alte Index weiterhin über denselben Alias lesbar bleibt, nur eben nicht mehr als Ziel für neue Schreibvorgänge.

Wichtig dabei ist, dass Rollover als atomare Operation ausgeführt wird: Entweder wird der neue Index erfolgreich angelegt und der Alias vollständig umgehängt, oder der gesamte Vorgang schlägt fehl und der ursprüngliche Zustand bleibt unverändert bestehen. Diese Atomarität verhindert einen inkonsistenten Zwischenzustand, in dem etwa zwei Indizes gleichzeitig als Schreibziel markiert wären.

3. Bedingungen im Detail: max_size, max_docs, max_age und max_primary_shard_size

Die Rollover-API unterstützt mehrere, frei kombinierbare Bedingungen. max_size begrenzt die Gesamtgröße des Index über alle Primärshards hinweg, max_primary_shard_size begrenzt dagegen gezielt die Größe des größten einzelnen Primärshards, was bei ungleichmäßiger Shard-Verteilung präziser ist. max_docs begrenzt die Dokumentanzahl, unabhängig von der tatsächlichen Größe, was bei Dokumenten mit stark unterschiedlicher Größe manchmal aussagekräftiger ist als eine reine Größenbedingung. max_age schließlich begrenzt die Zeit seit der Erstellung des Index, unabhängig von Größe oder Dokumentanzahl.

In der Praxis kombinieren die meisten Richtlinien mindestens zwei dieser Bedingungen, meist eine Größenbedingung mit einer Altersbedingung, um sowohl bei ungewöhnlich hohem als auch bei ungewöhnlich niedrigem Datenaufkommen einen sinnvollen Rollover-Zeitpunkt zu erzwingen. Ohne eine solche Kombination würde entweder ein Index bei geringem Datenaufkommen über Monate winzig bleiben oder bei einem plötzlichen Lastanstieg deutlich größer werden, als für effizientes Handling vorgesehen war.

POST bewertungen-write/_rollover
{
  "conditions": {
    "max_primary_shard_size": "25gb",
    "max_docs": 50000000,
    "max_age": "30d"
  }
}

4. Alias-Design für nahtlose Anwendungsintegration

Für eine saubere Integration in Anwendungscode empfiehlt sich ein zweigeteiltes Alias-Modell: ein Write-Alias, der stets nur auf den aktuell aktiven, beschreibbaren Index zeigt, und ein separater Read-Alias, der alle Indizes der gesamten Rollover-Sequenz umfasst und ausschließlich für Leseabfragen verwendet wird. Diese Trennung stellt sicher, dass Schreibvorgänge niemals versehentlich gegen mehrere Indizes gleichzeitig laufen, während Leseabfragen ohne jede Änderung im Anwendungscode transparent über die gesamte historische Datenmenge suchen können.

Für den Anwendungscode selbst ändert sich durch einen Rollover nichts: Er schreibt weiterhin gegen denselben Write-Alias-Namen und liest weiterhin gegen denselben Read-Alias-Namen, unabhängig davon, wie viele physische Indizes im Hintergrund tatsächlich existieren. Diese Entkopplung ist der eigentliche praktische Wert der Rollover-API, denn sie verlagert die gesamte Komplexität der Indexverwaltung vollständig aus der Anwendungsschicht in die Elasticsearch-Konfiguration.

5. Manuelles Rollover via API versus automatisiertes Rollover via ILM

Ein Rollover lässt sich jederzeit manuell über die REST-API auslösen, was sich für einmalige, geplante Ereignisse eignet, etwa einen bewusst herbeigeführten Rollover unmittelbar vor einem großen Marketing-Event mit erwartetem Traffic-Anstieg. Für den laufenden Regelbetrieb ist diese manuelle Steuerung aber wenig praktikabel, da niemand kontinuierlich die aktuellen Bedingungswerte im Blick behalten und den richtigen Zeitpunkt für den nächsten Aufruf abschätzen möchte.

In der Praxis übernimmt deshalb fast immer ILM diese Aufgabe: Die Rollover-Bedingungen werden als Aktion der Hot-Phase in einer ILM-Richtlinie hinterlegt, und Elasticsearch prüft die Bedingungen automatisch in regelmäßigen Intervallen im Hintergrund. Ein manueller Rollover-Aufruf bleibt dabei als Notfall- oder Sonderwerkzeug weiterhin verfügbar und funktioniert unabhängig davon problemlos parallel zur automatisierten ILM-Steuerung.

6. Praxisbeispiel: ein wachsender Produktbewertungs-Index mit Rollover

Ein Magento-Shop mit stark wachsendem Produktsortiment und aktiver Kundenbindung sammelt kontinuierlich neue Produktbewertungen an, deren Gesamtmenge über Jahre hinweg unbegrenzt anwächst. Ohne Rollover würde ein einzelner Bewertungs-Index irgendwann mehrere hundert Millionen Dokumente umfassen, was sowohl Reindexierungen bei Mapping-Änderungen als auch reguläre Snapshots zunehmend unpraktikabel macht. Mit einer Rollover-Strategie, ausgelöst nach fünfzig Millionen Dokumenten oder dreißig Tagen, bleibt jeder einzelne physische Index dagegen dauerhaft überschaubar.

Der Anwendungscode des Shops schreibt neue Bewertungen weiterhin ausschließlich gegen den Alias bewertungen-write, ohne jemals wissen zu müssen, welcher physische Index gerade aktiv ist. Die Produktseite fragt Bewertungen für ein bestimmtes Produkt weiterhin gegen den Alias bewertungen-read ab, wodurch die Suche transparent über sämtliche historischen Bewertungs-Indizes hinweg funktioniert, selbst wenn die Bewertungshistorie eines langlebigen Produkts über mehrere physische Indizes verteilt liegt.

PUT _index_template/bewertungen-template
{
  "index_patterns": ["bewertungen-*"],
  "template": {
    "settings": {
      "index.lifecycle.name": "bewertungen-ilm-policy",
      "index.lifecycle.rollover_alias": "bewertungen-write"
    },
    "aliases": {
      "bewertungen-read": {}
    }
  }
}

7. Naming-Konventionen für rollover-fähige Indizes

Elasticsearch verlangt für rollover-fähige Indizes ein Namensmuster, das auf eine fortlaufende, sechsstellige Nummer endet, etwa bewertungen-000001, damit jeder nachfolgende Rollover die Nummer automatisch um eins erhöhen kann. Wird stattdessen ein datumsbasiertes Namensschema gewünscht, etwa für tägliche Log-Indizes, unterstützt die Rollover-API zusätzlich Datumsmath-Ausdrücke im Indexnamen, sodass ein Rollover automatisch einen Namen mit dem aktuellen Datum erzeugt, ohne dass eine externe Logik dafür nötig wäre.

Eine konsistente Namenskonvention über alle rollover-fähigen Indexfamilien eines Clusters hinweg erleichtert nicht nur das Monitoring erheblich, sondern verhindert auch Verwechslungen bei manuellen Wartungsaufgaben, etwa wenn ein Administrator versehentlich einen archivierten statt des aktuell aktiven Index bearbeitet. Gerade bei vielen parallel laufenden Rollover-Sequenzen in einem größeren Cluster zahlt sich eine klare, einheitliche Benennung langfristig deutlich aus.

8. Rollover und Mapping-Änderungen: der ideale Zeitpunkt für Anpassungen

Ein oft übersehener Vorteil der Rollover-Strategie ist die Möglichkeit, Mapping-Änderungen risikoarm einzuführen. Da jeder Rollover einen komplett neuen, leeren physischen Index anlegt, lässt sich das zugrunde liegende Index-Template vor dem nächsten Rollover anpassen, wodurch die Änderung erst im nächsten physischen Index wirksam wird, ohne dass eine aufwendige Reindexierung bestehender Daten nötig wäre. Bestehende Indizes bleiben dabei mit ihrem ursprünglichen Mapping unverändert bestehen.

Dieser Ansatz eignet sich hervorragend für additive Änderungen wie neue Felder, stößt aber an Grenzen, sobald bestehende Felder inkompatibel geändert werden müssten, etwa ein Feldtyp-Wechsel von Text zu Keyword. Für solche Fälle bleibt weiterhin eine klassische Reindexierung der betroffenen, bereits bestehenden Indizes notwendig, wobei Rollover diese Aufgabe zumindest für alle künftig neu entstehenden Indizes von vornherein vermeidet.

9. Monitoring und Troubleshooting bei Rollover-Problemen

Ein Rollover kann fehlschlagen, wenn der Zielindexname bereits existiert, etwa nach einem manuellen Testlauf, der versehentlich denselben Namen erzeugt hat, oder wenn der konfigurierte Alias nicht eindeutig genau einen write index referenziert. Die Rollover-API liefert in solchen Fällen eine klare Fehlermeldung, die aber nur ausgewertet wird, wenn der Aufruf tatsächlich überwacht wird, weshalb ein automatisiertes, per ILM gesteuertes Rollover stets mit einem Blick auf die ILM Explain API kombiniert werden sollte.

Ein weiteres, praxisrelevantes Problem entsteht, wenn die Rollover-Bedingungen zu großzügig gewählt wurden und dadurch selten oder nie greifen, wodurch ein einzelner Index trotz vorhandener Rollover-Konfiguration unbemerkt weiter wächst. Ein regelmäßiger Blick auf die tatsächliche Größe und das Alter des aktuell aktiven Index im Vergleich zu den konfigurierten Schwellenwerten deckt solche Fehlkonfigurationen zuverlässig auf, bevor sie zu einem echten Performance-Problem werden.

10. Zusammenfassung

11. FAQ: Rollover-API in Elasticsearch: Das Wichtigste auf einen Blick