Important Notice: this service will be discontinued by the end of 2024 because for multiple years now, Plume is no longer under active/continuous development. Sadly each time there was hope, active development came to a stop again. Please consider using our Writefreely instance instead.

Index Alias - Warum man in OpenSearch mehrere Namen für Indexe benötigt

Ein Index kann mehr als einen Namen haben. Das kann man für viele Dinge einsetzen und es ist essenziell für die Arbeit mit OpenSearch.

Einleitung

Zunächst erscheint es seltsam, dass man mehrere Namen für einen Index benötigt. In der Softwareentwicklung mag man es lieber exakt, da gehören eindeutige Namen dazu.

Wenn man aber unterschiedliche Systeme hat, die miteinander kommunizieren und diese Systeme entkoppelt sind, werden Alias-Namen zu einem fundamentalen Werkzeug. Mit OpenSearch haben wir zum Beispiel ein System und unser Python-Script ist als Client ein anderes System. Jetzt kann es vorkommen, dass wir in OpenSearch Operationen durchführen, die sich in Umstrukturierungen der Indexe auswirken. Vielleicht wollen wir das Mapping verändern. Oder wir wollen Dokumente aus dem Index herausnehmen und archivieren. Eventuell wollen wir einen Index aufteilen und die Daten auf zwei verschiedenen Cluster verteilen. Es kann auch sein, dass wir eine große Anzahl an Dokumenten neu hinzufügen wollen oder bestehende aktualisieren müssen.

All diese Aktionen können für Clients “verwirrend” sein, weil die durchgeführten Änderungen zu nicht mehr nachvollziehbaren Suchergebnissen führen. Zudem sind einige Index-Manipulationen gar nicht möglich. Mappings kann man hinzufügen, aber bestehende nicht mehr ändern. Das geht nur, in dem man einen neuen Index anlegt und die Dokumente überträgt. Aber neuer Index bedeutet auch ein neuer Name. Da müssten wir dann alle Clients ändern, damit die den neuen Index-Namen wissen?

Man sieht, es gibt einiges an Gründen, einen Index unter einem mehreren Namen zu erreichen. Üblicherweise hat man einen stabilen “public API” Namen, der für die Clients eine verlässliche Adresse ist. Hinter diesem Alias verstecken wir den Index mit einem internen technischen Namen. Haben wir uns entschieden, dass dieser bisherige Index nicht mehr unseren Ansprüchen genügt, legen wir einen neuen an, ggf. mit besserem Mapping, transferieren die Dokumente von dem aktuellen Index in den neuen und übertragen dann den Alias-Namen abschließend auf den neuen Index. Für alle Clients sieht es so aus, als würden mit einem Schlag sich alle Inhalte des Index geändert haben.

Index Alias Beispiele

Beispiel:

  • Wir haben den Index playground-toots mit einem einigermaßen guten Mapping.
  • Zu diesem Index vergeben wir einen guten Alias-Namen, der einfach zu nutzen ist: toots
  • Die Clients (und unser Python Script) nutzen immer toots
  • Nun stellen wir fest, dass wir die Accounts gerne anders mappen wollen. Auch der HTML Tokenizer sollte besser laufen. Das können wir auf dem bestehenden playground-toots nicht machen. Mappings sind sehr statisch und eine Änderung ist nicht möglich.
  • Wir ändern das standard Index Template und legen einen verbesserten HTML Analyzer hinzu.
  • Wir legen einen neuen Index an: playouground-toots-v2
    • Hier definieren wir das neue Mapping und der Analyzer wird aus dem standard Template genommen
    • An dem bisherigen playground-toots hat sich nichts geändert, alle Clients lesen den bisherigen Stand über toots aus
  • Jetzt übertragen wir alle Dokumente aus dem alten Index playground-toots in den neuen playouground-toots-v2. Das wird ein paar Sekunden, bis Minuten dauern. Je nachdem, wie viele Dokumente wir haben.
    • Immer noch bemerkt niemand was von unserer Aktion
  • Jetzt kommt der entscheidende Moment. Wir löschen den Alias toots von playground-toots und fügen playouground-toots-v2 den Alias toots hinzu. OpenSearch kann das sogar in einem Schritt machen.
    • Die Clients, die nun weitere Abfragen machen, arbeiten unmittelbar auf dem neuen technischen Index, aber weiterhin über den Namen toots

Die grafische Darstellung:

versioning

Beispiel:

  • Wir haben einen schnell wachsenden Index (aus Logdaten zum Beispiel) und müssen die Indexe nach Monaten aufteilen
  • Jeden Monat wird ein neuer Index angelegt (mit _YYYY_MM als Suffix) und der Alias des aktuellen Index log wird auf den letzten neu angelegten Index gesetzt.
  • Da man aber alle Indexe gemeinsam lesen will, glegt man noch einen Alias an, der über mehrere Indexe geht. Zum Beispiel über die letzten 3 Monate.

Die grafische Darstellung:

spanning

Man sieht, es gibt einiges an Lösungen. Ein Index kann mehrere Aliase bekommen, oder ein Alias kann mehrere Indexe umfassen. Im letzteren Fall muss man aber festlegen, in welchen Index real geschrieben werden soll, wenn ein Dokument über den “überspannenden” Alias gespeichert wird.

Es ist sogar möglich, jeden Index über den Alias einem Filter zuzuordnen. Greift man direkt auf den echten Namen zu, kann man alle Dokumente erhalten. Greift man über den Alias zu, werden Dokumente ausgefiltert, wenn man es definiert hat.

Ausblick

Im nächsten Blog-Artikel werden wir das Beispiel der Versionierung in unser Migration.py Modul einbauen. Denn aktuell können wir nur Indexe erstellen und keine Mappings manipulieren. Da das technisch sowieso nicht geht (bzw., nur sehr eingeschränkt), müssen wir die obigen Schritte implementieren.