Indexer [deprecated]
Der Indexierungsprozess wird verwendet, um Daten in OpenSearch zu aktualisieren und sicherzustellen, dass die neuesten Informationen in Pimcore und somit auch im Frontend verfügbar sind. Dabei werden Daten regelmässig verarbeitet und aktualisiert. Es gibt ein paar Regeln und Zeitpläne, die beachtet werden müssen.
Regelmässige Updates - Funktionsweise:
Zur vollen Stunde wird ein neuer Indexierungsprozess initiiert. Die Entscheidung, ob und welche Indizes aktualisiert werden, hängt von folgenden drei Faktoren ab:
Timeout: Wenn ein Index aktualisiert wird, wird dieser gesperrt („gelocked“). Das Lock bleibt auf den Umgebungen QA und P für zwei Stunden aktiv, auf D/Demo dauert es länger. Nach Abschluss der Indexbearbeitung wird das Lock entfernt, was verhindert, dass der Prozess mehrmals gestartet wird. Der Status des Locks kann im "Report Indexer Status" in der Spalte „Timeout“ eingesehen werden, die den Ablauf des Locks anzeigt und somit den Startzeitpunkt des Prozesses erkennen lässt. Die Dauer des Locks ist im Code festgelegt und kann von Valantic angepasst werden. Im Falle eines katastrophalen Fehlers wird das Lock nicht entfernt; es sollte dann Valantic informiert werden. Ein entsprechender Report sieht wie folgt aus:
Name: Product
Messages: 0
Errors: 0
Timeout: ausgefüllt
Cooldown: entweder ausgefüllt oder nicht (vermutlich nicht)
Dies kann auch geschehen, wenn es keine Objekte für einen Index gibt, z.B. bei Intranet-Indizes. Das Lock läuft in jedem Fall nach der angegebenen Zeit ab.
Cooldown: Nachdem ein Index fertiggestellt wurde, wird das Timeout Lock entfernt und ein Cooldown Lock erstellt, welches auf P+QA eine Stunde und auf D/Demo zwei Stunden dauert. Ein Cooldown Lock hat denselben Effekt wie das Timeout Lock; während des Cooldowns wird kein neuer Durchlauf für diesen spezifischen Index gestartet, jedoch wird der Lock nicht programmatisch entfernt, sondern es wird immer das Ablaufen des Timeouts abgewartet.
Nicht verarbeitete Nachrichten: Wenn Nachrichten in der Queue sind, die noch nicht verarbeitet wurden, wird der Prozess nicht gestartet, und beim nächsten Durchlauf wird ein erneuter Versuch unternommen.
Parallelisierung:
Die Indizes werden durch mehrere Symfony-Messenger-Consumer aktualisiert, die aus einer gemeinsamen Queue Nachrichten abarbeiten. Obwohl vier Consumer gleichzeitig eingesetzt werden können, bedeutet das nicht, dass sie simultan an vier verschiedenen Indizes arbeiten. Stattdessen holen sich die Consumer die nächstverfügbare Nachricht aus der Queue und bearbeiten somit bis zu vier Dokumente gleichzeitig, die aber zum selben Index gehören können.
Diese Konfiguration ermöglicht eine effiziente Verarbeitung von Dokumenten in der Weise, dass mehrere Dokumente parallel bearbeitet werden, während die Indexaktualisierung selbst sequenziell erfolgt. Dadurch wird gewährleistet, dass die Ressourcen optimal genutzt werden, indem die Consumer gleichzeitig Aktionen ausführen können, ohne auf die Fertigstellung von Aufgaben eines anderen Consumers zu warten.
Dauer des Indexierungsprozesses:
Bedeutung der Gesamtdauer des Indexierungsprozesses im Kontext der Queue-Verarbeitung:
Bei dieser Implementierung wird für den vollständigen Aufbau der Indizes eine Queue verwendet, wobei jede Stunde für jedes Dokument eine Nachricht generiert und in die Queue eingefügt wird. Die verfügbaren Consumer verarbeiten diese Nachrichten aus der Queue. Sobald alle Dokumente eines Indexes abgearbeitet wurden, erfolgt ein 'Blue/Green'-Switch, um den aktualisierten Index live zu schalten.
Die Gesamtdauer des Indexierungsprozesses ist zwar weiterhin von Bedeutung, jedoch ist die Priorität auf die kontinuierliche Verarbeitung der einzelnen Nachrichten und die Vollständigkeit jedes Indexes vor dem Umschalten gelegt. Die Dauer des gesamten Prozesses hängt folglich weniger vom Zeitpunkt des Beginns und der Beendigung ab, sondern vielmehr von der kontinuierlichen und effizienten Abarbeitung der Nachrichten in der Queue. Dies führt zu einer gleichmäßigeren Lastverteilung im System und einer stetigen Aktualisierung der Indizes, was die Sichtbarkeit der Gesamtdauer relativiert.
Die Konzentration auf die Verarbeitungsgeschwindigkeit und -qualität jeder einzelnen Nachricht innerhalb der Queue stellt sicher, dass Indizes effizient und zuverlässig aktualisiert werden, ohne dass ein einzelner, zeitlich umfangreicher Indexierungsprozess notwendig ist.
Fehlerbehandlung:
Falls während des Aufbaus des Index ein Fehler in einem Dokument auftritt, wird der gesamte Prozess für diesen Index gesperrt. Der Fehler wird im Report angezeigt und geloggt, und es werden keine weiteren Dokumente generiert oder ein Wechsel durchgeführt. Nach einer Stunde wird ein erneuter Versuch gestartet. Derzeit werden noch keine Benachrichtigungen ausgelöst. Motorex hat momentan keine Möglichkeit, die Ursache des Fehlers zu analysieren, was sich jedoch in Zukunft ändern könnte. Valantic kann den Fehler in der Datenbank (Tabelle: messenger_messages; queue_name: elastica_bridge_failed) analysieren.
Report "Indexer Status"
Name: Index Name
Messages Remaining: Nachrichten welche noch verarbeitet werden müssen um den aktuellen Prozess abzuschliessen
Errors: Fehler die aufgetreten sind. Dieser Count wird nur von valantic zurückgesetzt.
Timeout: Wenn der Prozess aktiv ist, wird hier angezeigt wie lange es dauert, bis theoretisch ein neuer Prozess gestartet werden kann, ohne dass der aktuelle abgeschlossen ist. (Es müssen dann trotzdem alle Nachrichten abgearbeitet worden sein)
Cooldown: Frühester Zeitpunkt wenn der nächste Prozess startet
Weiterführende Informationen:
Symfony Messenger Developer Documentation: https://symfony.com/doc/current/messenger.html
Symfony Messenger Component: https://symfony.com/doc/current/components/messenger.html
Last updated