Einleitung
An dieser Stelle sollen Maßnahmen vorgestellt werden, die der Performanceoptimierung der CCM-Indizierung dienen. In der Regel werden diese mit dem neuen Deployment von uns direkt aktiv geschaltet. Falls es aber zu Problemen kommt, gibt es eine Möglichkeit, sie über eine GlobalProperty oder eine ServiceProperty wieder abzuschalten.
Index-Commits und Reader-Refreshs
Die zeitlich teuersten Transaktionen bei der Indizierung sind Refreshs des Index-Readers. Wenn neue Daten mit Hilfe eines Index-Commits in den Index geschrieben werden, ist dies nicht sehr aufwendig, da diese als neues Segment neben die vorhandenen Index-Segmente geschrieben werden. Gleiches gilt für das Löschen sowie Updates.
Teuer wird es, wenn die Suchmaschine die neu geschriebenen Daten oder Änderungen auch finden soll. Dazu muss der Index-Reader refresht, also aufgefrischt werden. Dieser Vorgang dauert bei kleinen Indexen ein paar Sekunden, bei großen bis zu 90 s.
Werden direkt nacheinander mehrere Updates auf dasselbe Dokument im Index durchgeführt, dann muss sichergestellt werden, dass der Index-Reader die vorherigen Änderungen bereits registriert hat. Ansonsten können Daten verloren gehen.
Beispiel: In einem Dokument wird durch ein Update VS von RUN auf SUC gesetzt. Direkt danach durch ein 2. Update BS von CTW auf CTP. Ohne Reader-Refresh passiert folgendes:
- doc(version0; VS=RUN; BS=CTW) wird aus dem Reader gelesen
- doc(version0) wird als gelöscht markiert und als doc(version1, VS=SUC; BS=CTW) in den Index geschrieben.
- für das 2. Update wird wieder die alte doc(version0) aus dem Reader gelesen, da dieser die Änderung version1 nicht kennt.
- doc(version0) wird wieder als gelöscht markiert und doc(version2, VS=RUN, BS=CTP) in den Index geschrieben.
- nach dem nächsten Reader-Refresh kennt der Reader nur noch doc(version2), in dem Update 1 (VS=SUC) verloren gegangen ist.
Mit einem Reader-Refresh zwischen den Updates werden alle Änderungen registriert, und der Reader hat ein doc(version2, VS=SUC, BS=CTP)
Daraus folgt: Mehrere Updates auf dasselbe Dokument erzeugen Reader-Refreshs und kosten viel Zeit
Die meisten Optimierungen der Indizierung drehen sich darum, solche mehrfachen Updates zu vermeiden oder geschickter zu verarbeiten.
CCM-834 Update-Gruppierung
Beim Neustart von Nachrichten werden etwa 3-5 Updates pro Nachricht erzeugt. Verarbeitet man diese in der Reihenfolge der Erzeugung, so erzeugen 1000 neugestartete Nachrichten 4000 Reader-Refreshs von z.B. 30 s Dauer und legen damit die Indizierung für 1-2 Tage lahm.
Der Mechanismus der Update-Gruppierung bildet Gruppen von 1. Updates, 2. Updates etc. und kommt damit in diesem Fall mit 4 Updates aus.
Die Update-Gruppierung ist defaultmäßig aktiv, kann aber über die ServiceProperty am IndexServiceCcm USE_SORTING_FOR_MULTIPLE_UPDATES_PER_MSG=true/false gesteuert werden. Ab September 2021 exitstiert diese Global Property nicht mehr. Die Update-Gruppierung wird nun immer durchgeführt.
Aktiv seit Release 1.13.4_3.3 (fehlerhafte Version 1.13.4_2.2)
CCM-878 Optimierung Aperak-Updates
Wenn APERAKS indiziert werden, müssen im CCM die betroffenen Vorgänge (Row-Dokumente) und die Gesamtnachricht (Header-Dokument) der Originalnachricht (z.B. INVOIC) auf BS=APC upgedated werden. Dazu wurde früher zu jedem Vorgang auch der Header upgedatet. Die mehrfachen Header-Updates waren unnötig und blockierten die Verarbeitung im IndexServiceCCM.
Das Feature ist defaultmäßig aktiv und kann nicht abgeschaltet werden.
Aktiv seit Release 1.14.0_0.2
CCM-955 Filtern auf Duplikate im ClearingService2
Das Setzen eines ClearingStatus in einem CCM Arbeitsvorrat kann zum Stillstand der Indizierung führen, wenn eine vollständige Nachricht mit vielen Vorgängen markiert wird, bei der zu jedem Vorhgang dieselbe CONTRL angezeigt wird.
Es wurde eine Filterung auf Duplikate eingeführt, die dafür sorgt, dass nur ein Update auf die CONTRL Nachricht in der CCM_INDEX_SYNC Tabelle ankommt.
Das Feature ist defaultmäßig aktiv, kann aber über die GlobalProperty CCM_CLEARING_SERVICE_2_REMOVE_DUPLICATE_UPDATES=true/false gesteuert werden.
Aktiv voraussichtlich ab Release 1908.1.X
In Planung: Update-Merger
In Planung ist ein Ansatz, in jedem Fall mehrfache Updates auf dasselbe Dokument zu vermeiden. Dies kann erreicht werden, indem die durchzuführenden Updates nach Zieldokumenten sortiert und anschließend zu einem einzigen Update zusammengeführt werden.
Beispiel: Aus zwei Updates VS=SUC; B3P.Updated=20191025132500 und BS=CTP; B3P.Updated=20191025132510 wird ein gemainsames Update VS=SUC;BS=CTP;B3P.Updated=20191025132510
Das Zusammenführen (“Mergen”) der Updates wird in der Reihenfolge erfolgen, in der die Updates auch in den Index geschrieben worden wären. Damit ändert sich inhaltlich nichts. Damit wird aber jeder Lauf des IndexServiceCCM mit maximal 2 Reader-Refreshs auskommen.
Aktiv voraussichtlich Anfang 2020