imx.Search: der neue ad-hoc Index-Update-Service

Datum: 3. Dezember 2014
Autor*in: Marc Kurzmann


Bisher war es bei imx.Search so, dass Änderungen in den Contents aus den Produkten nur nach einer kompletten Neu-Indizierung im Index verfügbar waren – üblicherweise über Nacht. Was für einen reinen Volltext-Suchmaschineneinsatz von imx.Search vielleicht noch akzeptabel ist, wenn Suchbegriffe mit einem Tag Verspätung gefunden werden, so ist es bei der Verwendung als Filter-Suchmaschine, so wie es mittlerweile bei allen unseren neueren und größeren Portalen geschieht, eher lästig, dass die Daten nicht gleich auffindbar sind, weil insbesondere auch keine saubere Portal-Prüfung direkt nach Eingabe möglich wird.

imx.Search unterstützt ab Version 3.6.0 (17.11.2014) den neuen ad-hoc Index-Update-Service. Die Funktionsweise ist wie folgt:

  • Änderungen aus den Produkten wird imxSearch über einen Service-Aufruf mitgeteilt: http://[imxsearch]/[lang]/imxsearch?method=scheduledUpdate&connectorId=…&objectId=…&lang=…
    Der Parameter lang ist optional; falls er weggelassen wird, wird auf die unterstützten Sprachen des [lang]-cores zurückgegriffen. Der connectorId ist imx.Search-Instanz individuell, typsicherweise z.B. imxtools2, imxcms etc.
  • imx.Search fügt diese Änderungsinformation in seine Update-Queue ein.
  • Alle 3 Minuten wird ein Schedule-Job in imx.Search gestartet, der die nächsten 100 Änderungs-Einträge aus der Queue entnimmt, die geänderten Objekte aus den entsprechenden Content-Quellen (Produkten) erneut abfragt und in den Index zurückschreibt. Ein Änderungs-Eintrag muss mindestens 30 Sekunden alt sein, damit er für den Schedule-Job berücksichtigt wird.
  • Die Queue erfasst max. 5000 Einträge. Alle Änderungsmitteilungen, während einer vollen Queue werden ignoriert. Das soll verhindern, dass bei riesigen Massenupdates der ad-hoc Index-Update für viele Stunden blockiert ist. Bei riesigen Imports ist es sinnvoll, den Ad-hoc-Update-Service zu blockieren und danach die Blockade wieder aufzuheben. Dazu gibt es den Service
    http://[imxsearch]/[lang]/imxsearch?method=scheduler&run=[true/false]
    Idealerweise finden solche Massenimports vor einem frischen Komplett-Index-Lauf statt.

Warum der Scheduler?

Der Scheduler sorgt dafür, dass sich durch Massenänderungen nicht plötzlich das ganze System aufschaukelt und dann unter der Last zusammenbricht. Bei Massen-Änderungen wie es sie z.B. bei Imports gibt, füllt sich zwar schnell die Queue, diese wird dann aber peau-a-peau in sog. „Chunks“ (100er-Einheiten) abgearbeitet, was die Spitzenlast deutlich reduziert. Dadurch, dass bei Massen-Änderungen die Queue schnell über die Chunk-Größe steigen kann, kann es passieren, dass in solchen Fällen ein Update im Index erst zu einem späteren Zeitpunkt und nicht schon beim nächsten Schedule-Job-Lauf durchgeführt wird.

Zur Aktivierung des neuen Ad-hoc-Index-Update-Services sind zwei Dinge zu tun
1. Update auf die neue imx.Search-Version >= 3.6.0
2. Aktivierung über die Konfiguration in den Produkten (imx.Tools, imx.EventManager, imx.CMS)

Hier läuft der neue Ad-hoc-Index-Update-Service bereits:

  • NÖW
  • byTM (Anbindung imx.Tools)
  • weitere Projekte werden nach und nach folgen [wenn es hier Wünsche zur Priorisierung gibt, dann teilt es mir bitte mit].

Dieser Artikel wurde verschlagwortet unter:


Kommentare

Selber kommentieren:






Weitere Beiträge zum Thema Technologie


PhotoSwipe: Responsive JavaScript Image Gallery

Autor*in: Benjamin Hofmann


Technologie // User Experience & Design


Ich bin gestern auf eine ziemlich geniale Lightbox-Lösung gestoßen: PhotoSwipe. Diese baut auf Vanilla JS auf und ist auf hohe Performance und die mobile Verwendung ausgelegt, bei der ja doch ziemlich viele Lightboxen scheitern oder von uns sogar deaktiviert werden. Und trotz all dieser Features sind das Skript und die dazugehörigen Styles sehr klein was …


Beitrag lesen
22
SEP
16

Google Analytics in Verbindung mit Google Tag Manager

Autor*in: Stefan Oswald


Projekte // Technologie


Wenn Google Analytics über den Google Tag Manager eingebunden wird, ist zu beachten, dass trotzdem noch die jeweilige GA-Account-ID mit angegeben werden muss. Das kann man entweder im Header des Codes machen, oder direkt bei jedem Tracking-Aufruf. Bei GAv2 sieht das z.B. so aus: _gaq.push([‚_setAccount‘, ‚UA-123456789-0‘]); _gaq.push([‚_trackEvent‘, ‚category‘, ‚action‘, ‚label‘]); Der GTM bindet logischer Weise …


Beitrag lesen
09
MAI
14

Von Zend_Date und den ersten Tagen im Jahr

Autor*in: Benjamin Hofmann


Technologie


Ebene bin ich auf eine interessante Sache bei der Verwendung von Zend_Date und dessen Datumskonstanten (Link) gestoßen. Verwendet man die Konstante Zend_Date::YEAR_8601, die sich nach ISO 8601 richtet, wird das Jahr nicht nach der Woche berechnet, in der sich der gegebene Tag befindet. Nun ist es ja bekanntermaßen so, dass sich die letzte Woche eines …


Beitrag lesen
19
DEZ
11

Einrichten des GoogleTagManagers

Autor*in:


Technologie


Zum Hintergrund: seit kurzem verwenden wir den GoogleTagManager(GTM) bei den Hörnerdörfern. Ziel ist es die diversen Analytics Accounts die hier verwendet werden (Bolsterlang, Fischen etc.) unter einen Hut zu bringen. Hierzu kann man im Tagmanager Profil Regeln und Tags erstellen, anhand derer das Tracking dann ausgeführt wird (dazu später mehr). Ermöglicht  wird das Ganze über …


Beitrag lesen
26
AUG
14