SearchSystem / SearchLayer

Was ist die SearchLayer?

In der B2B werden für verschiedene Zwecke (Volltextsuche, Archivsuche, Systemweiche, CCM) Suchindexe verwendet. Bisher wurde dies durch mehrere tausend direkte Zugriffe auf Apache Lucene core Version 2.4.1 (Lucene2) realisiert. Dadurch waren Aktualisierungen des Suchsystems sehr schwierig:

  • Das Upgrade der Lucene Version war nicht möglich.
  • Der Übergang auf eine andere Suchtechnologie (z.B. BDM oder ElasticSearch) war nicht möglich.

Aus diesem Grund wurde eine abstrakte Zwischenschicht, die SearchLayer API, für den Zugriff auf die Indexe definiert. Diese enthält nur etwa 30 allgemein definierte Befehle wie “search”, “update” etc. Die B2B wurde danach so umgestellt, dass sie nur noch auf diese allgemeinen Befehle zugreift. Zur Ausführung werden die Befehle dann durch die SearchLayer an eine konkrete Implementierung (derzeit Lucene2.4.1, BDM, SOLR) weitergeleitet.

Durch diese Trennschicht zwischen B2B und der konkreten Such-Technologie können demnächst mit vergleichsweise wenig Aufwand Implementierungen modernerer Suchtechnologien wie Lucene 8, ElasticSearch etc. erstellt werden.

concept

Extension SEARCH_LAYER_CONFIGURATION

Seit Einführung der SearchLayer-API können die Systemeinstellungen der Suchtechnologie in einer neuen Extension SEARCH_LAYER_CONFIGURATION zusammengefasst werden.

Die Extension SEARCH_LAYER_CONFIGURATION muss derzeit verwendet werden, wenn Sie die Suchtechnologien LUCENE2MULTIREADER, BDM oder SOLR verwenden.

Ist die Extension nicht vorhanden, wird automatisch die Suchtechnologie Lucene2 verwendet, und es werden alle alten Einstellungen für die Indexe aus den vorhandenen GlobalProperties ausgelesen.

Aufbau der Extension

Die Extension SEARCH_LAYER_CONFIGURATION besteht aus zwei Kopfzeilen, in denen die zu verwendende Suchtechnologie (SEARCH_SYSTEM_VENDOR) sowie die vorhandenen Indexe (SEARCH_TYPES) definiert werden. Danach kommen vendor-spezifische Einstellungen. Zum Beispiel Pfade zu den einzelnen Indizies im Falle von Lucene als Vendor. Beispiele, wie die Extension aussehen kann, stehen weiter unten bei den Suchtechnologien

Suchtechnologien (SEARCH_SYSTEM_VENDOR)

SEARCH_SYSTEM_VENDOR Beschreibung
LUCENE2 Implementierung der bisherigen Suchtechnologie Apache Lucene 2.4.1
LUCENE2MULTIREADER Lucene 2.4.1 Implementierung, die einen Index zum Schreiben und mehrere zum Lesen verwendet
BDM Implementierung, die mit einem ElasticSearch-basierten BDM-Server arbeitet
SOLR SOLR-Implementierung
MULTI Implementierung zur Verwendung von zwei Indextechnologien beim Umstieg von einer Index-Technologie auf eine andere (z.B. von Lucene auf SOLR)

Index-Typen (SEARCH_TYPES)

Derzeit können folgende SEARCH_TYPES konfiguriert werden.

SEARCH_TYPES Index
FULLTEXT Volltextindex, muss konfiguriert werden
ARCHIVE Archivindex
CCM CCM-Index
SYSTEMSPLIT_METERINGPOINT Systemweiche, Meldepunktindex
SYSTEMSPLIT_METERINGPOINTTEMP Systemweiche, Meldepunktindex 2 (Rebuild)
SYSTEMSPLIT_RESPONSE Systemweiche, Antwortindex

Index-Definitionen

LUCENE2

Property Wert Bedeutung
<Search_Type>_PATH z.B. E:/testindex/ccm Pfad des Index-Verzeichnisses. Als Pfad-Trenner muss “/” benutzt werden, auch bei Windows-Systemen

Beispiel Extension SEARCH_LAYER_CONFIGURATION

SEARCH_SYSTEM_VENDOR=LUCENE2
SEARCH_TYPES=FULLTEXT,ARCHIVE,CCM,SYSTEMSPLIT_METERINGPOINT,SYSTEMSPLIT_METERINGPOINTTEMP,SYSTEMSPLIT_RESPONSE

ARCHIVE_PATH=E:/index/arc

FULLTEXT_PATH=E:/index/fulltext

CCM_PATH=E:/index/ccm

SYSTEMSPLIT_METERINGPOINT_PATH=E:/index/sysspl1
SYSTEMSPLIT_METERINGPOINTTEMP_PATH=E:/index/sysspl2
SYSTEMSPLIT_RESPONSE_PATH=E:/index/resp

Lucene2Multireader

Property Wert Bedeutung
<Search_Type>_PATH z.B. E:/index/arc1; E:/index/arc2 Falls dieser Implementierung genutzt wird, können in der Pfadangabe mehrere Indexpfade Semikolon-separiert angegeben werden. Der erste Pfad wird als lesender und schreibender Index verwendet, alle anderen Pfade werden als lesende Indexe verwendet. Falls nur ein Pfad angegeben wird, verhält sich dieser Anbieter wie Lucene2. Als Pfad-Trenner muss “/” benutzt werden, auch bei Windows-Systemen

Die Angabe mehrerer Semikolon-separierter Pfade ist nur in Kombination mit der Extension SEARCH_LAYER_CONFIGURATION sowie mit dem SEARCH_SYSTEM_VENDOR=LUCENE2MULTIREADER möglich. In der alten GlobalProperty B3P_LUCENE_INDEX_FOLDER kann keine Semikolon-separierte Liste angegeben werden.

Beispiel Extension SEARCH_LAYER_CONFIGURATION

SEARCH_SYSTEM_VENDOR=LUCENE2MULTIREADER
SEARCH_TYPES=FULLTEXT,ARCHIVE,CCM,SYSTEMSPLIT_METERINGPOINT,SYSTEMSPLIT_METERINGPOINTTEMP,SYSTEMSPLIT_RESPONSE

FULLTEXT_PATH=E:/index/fulltext

ARCHIVE_PATH=E:/index/arc1;E:/index/arc2;E:/index/arc3

CCM_PATH=E:/index/ccm1

SYSTEMSPLIT_METERINGPOINT_PATH=E:/index/sysspl1
SYSTEMSPLIT_METERINGPOINTTEMP_PATH=E:/index/sysspl2
SYSTEMSPLIT_RESPONSE=E:/index/resp

Lucene2Multireader kann für den CCM-Index nicht generell empfohlen werden! Das Aktualisieren und Löschen von Dokumenten geschieht nur im ersten, schreibenden Index. Im CCM-Index werden aber auch ältere Nachrichten aktualisiert, manchmal auch solche, die vor Wochen erstellt wurden. Wird der schreibende Index als leerer Index angelegt, werden solche Updates nicht klappen.

BDM

Die Installation und Konfiguration des BDM Servers ist hier beschrieben: BDM Administration

Property Wert Bedeutung
BDM_SEEDS z.B. 192.168.1.158 Kommaseparierte IP-Adressen der BDM-Knoten aus topology.xml/node/ip
BDM_PORTS z.B. 2501 Kommaseparierte Ports der BDM-Knoten aus topology.xml/node/bdm-service-runtime-port
BDM_HOST localhost B2B Host. Immer localhost
BDM_<SEARCH_TYPE>
_SERVICE_CLASSNAME
com.nextlevel.bdm.
searchsystem.extension.api.
ArchiveSearchSystemService
Implementierung des Service, der die Verbindung zum BDM-Server realisiert. Siehe unten im Beispiel
BDM_FRAME_SIZE z.B. 300 Maximale Übertragungsdatengröße in MB bei einer Verbindung mit BDM (z.B Add oder Search) Bei Überschreitung kann der Batch gespaltet werden.
BDM_CHECK_FRAME_SIZE true/false Soll die Framegröße geprüft werden?
BDM_METHOD_CALL_TIMEOUT z.B. 120000 B2B wartet bei jeder Anforderung auf die Antwort von BDM. Nach dieser Zeit (Millisekunden) gibt die B2B eine Timeoutfehlermeldung aus, wenn sich BDM nicht meldet. Default=60000
BDM_MAX_RETRY_COUNT 3 wenn sich BDM nicht rechtzeitig meldet, wiederholt B2B die Anforderung. Nach maximaler Wiederholung gibt die B2B Timeoutfehlermeldung aus, wenn sich BDM nicht meldet.

Beispiel Extension SEARCH_LAYER_CONFIGURATION

SEARCH_SYSTEM_VENDOR=BDM
SEARCH_TYPES=ARCHIVE,FULLTEXT,CCM

BDM_SEEDS=192.168.1.158
BDM_PORTS=2501
BDM_HOST=localhost
BDM_ARCHIVE_SERVICE_CLASSNAME=com.nextlevel.bdm.searchsystem.extension.api.ArchiveSearchSystemService  
BDM_FULLTEXT_SERVICE_CLASSNAME=com.nextlevel.bdm.searchsystem.extension.api.FulltextSearchSystemService
BDM_CCM_SERVICE_CLASSNAME=com.nextlevel.bdm.searchsystem.extension.api.CCMSearchSystemService
BDM_FRAME_SIZE=300
BDM_CHECK_FRAME_SIZE=true
BDM_METHOD_CALL_TIMEOUT=120000
BDM_MAX_RETRY_COUNT=3

SOLR

Die Installation und Konfiguration von SOLR ist hier beschrieben: SOLR Dokumentation

Konfiguration mit B2B-Version April 2022 und älter
Property Wert Bedeutung
<Search_Type>_SOLR_URL z.B. http://host.docker.internal:8981/solr/full/ URL zu der SOLR-Collection des Indexes

Beispiel Extension SEARCH_LAYER_CONFIGURATION

SEARCH_SYSTEM_VENDOR=SOLR
SEARCH_TYPES=FULLTEXT,SYSTEMSPLIT_METERINGPOINT,SYSTEMSPLIT_RESPONSE,CCM,ARCHIVE

FULLTEXT_SOLR_URL=http://host.docker.internal:8981/solr/full/
SYSTEMSPLIT_METERINGPOINT_SOLR_URL=http://host.docker.internal:8981/solr/meteringpoint/
SYSTEMSPLIT_RESPONSE_SOLR_URL=http://host.docker.internal:8981/solr/response/
CCM_SOLR_URL=http://host.docker.internal:8981/solr/ccm/
ARCHIVE_SOLR_URL=http://host.docker.internal:8981/solr/archive/
Konfiguration ab B2B-Verison Mai 2022

Ab dem Mai Release 2022 wird nicht mehr der HttpSolrClient genutzt, sondern der CloudSolrClient. Er wird für den Cloud-Mode empfohlen. Er verteilt die Anfragen, wie ein Loadbalancer, gleichmäßig an alle Knoten. Sollte ein Knoten ausfallen, werden die Anfragen an die noch funktionierenden Knoten verteilt. Wenn der ausgefallene Knoten wieder da ist, wird er bei der Lastverteilung wieder berücksichtigt. Für die Konfiguration müssen daher die URLs aller Solr-Instanzen angegeben werden.

Property Wert Bedeutung
SOLR_URLS z.B. http://host.docker.internal:8981/solr,http://host.docker.internal:8982/solr,http://host.docker.internal:8983/solr URLs zu allen Solr-Instanzen kommasepariert
<Search_Type>_SOLR_COLLECTION z.b. full Name der Solr-Collection des Indexes

Beispiel Extension SEARCH_LAYER_CONFIGURATION

SEARCH_SYSTEM_VENDOR=SOLR
SEARCH_TYPES=FULLTEXT,SYSTEMSPLIT_METERINGPOINT,SYSTEMSPLIT_RESPONSE,CCM,ARCHIVE

SOLR_URLS=http://host.docker.internal:8981/solr,http://host.docker.internal:8982/solr,http://host.docker.internal:8983/solr
FULLTEXT_SOLR_COLLECTION=full
SYSTEMSPLIT_METERINGPOINT_SOLR_COLLECTION=meteringpoint
SYSTEMSPLIT_RESPONSE_SOLR_COLLECTION=response
CCM_SOLR_COLLECTION=ccm
ARCHIVE_SOLR_COLLECTION=archive

Momentan ist es noch nicht möglich, den SEARCH_TYPE SYSTEMSPLIT_METERINGPOINTTEMP mit SOLR zu nutzen. Melden Sie sich gerne bei unserem Support, wenn Sie daran Interesse haben.

MULTI

Beim Umstieg von einer Index-Technologie auf eine andere (z.B. von Lucene auf SOLR) ist es hiermit möglich, beide Technologien gleichzeitig zu nutzen. Somit gibt es den neuen Index, welcher primärer Index genannt wird und den alten Index, welcher sekundärer Index genannt wird.

So wird bei einzelnen Operationen verfahren:

  • neue Dokumente werden nur im primären Index gespeichert
  • beim Lesen werden beide Indexe abgefragt und die Ergebnisse zusammengeführt
  • gelöscht wird in beiden Indizes
  • Updates werden in dem Index gemacht, in dem sich das upzudatende Dokument befindet

Momentan ist es nur möglich einen sekundären Index anzugeben. Dies kann aber auch erweitert werden. Wenden Sie sich dafür gerne an unseren Support oder die Beratung.

Es ist möglich, dieselbe Technologie für den primären und den sekundären Index anzugeben und so zum Beispiel zwei Lucene-Indexe zusammen zu betreiben.

Property Wert Bedeutung
MULTI_PRIMARY_SYSTEM z.B. A, NEU Name des neuen/primären Index (frei wählbar)
MULTI_SECONDARY_SYSTEMS z.B. B, ALT Name des alten/sekundären Index (frei wählbar)
MULTI_<MULTI_PRIMARY_SYSTEM>_SEARCH_SYSTEM_VENDOR (z.B. MULTI_A_SEARCH_SYSTEM_VENDOR) z.B. SOLR Search System Vendor des neuen/primären Index
MULTI_<MULTI_SECONDARY_SYSTEM>_SEARCH_SYSTEM_VENDOR (z.B. MULTI_B_SEARCH_SYSTEM_VENDOR) z.B. LUCENE2 Search System Vendor des alten/sekundären Index
MULTI_<MULTI_PRIMARY_SYSTEM>_<Vendor specific property> (z.B. MULTI_A_ARCHIVE_SOLR_URL) z.B. http://localhost:8983/solr/archive/ URL- oder Pfadangaben zum Search Type
MULTI_<MULTI_SECONDARY_SYSTEM>_<Vendor specific property> (z.B. MULTI_B_ARCHIVE_PATH) z.B. E:/index/arc URL- oder Pfadangaben zum Search Type

Beispiel Extension SEARCH_LAYER_CONFIGURATION

SEARCH_SYSTEM_VENDOR=MULTI
SEARCH_TYPES=FULLTEXT,SYSTEMSPLIT_METERINGPOINT,SYSTEMSPLIT_RESPONSE,CCM,ARCHIVE

MULTI_PRIMARY_SYSTEM=NEU
MULTI_SECONDARY_SYSTEMS=ALT
MULTI_NEU_SEARCH_SYSTEM_VENDOR=SOLR
MULTI_ALT_SEARCH_SYSTEM_VENDOR=LUCENE2

MULTI_NEU_SOLR_URLS=http://host.docker.internal:8981/solr,http://host.docker.internal:8982/solr,http://host.docker.internal:8983/solr
MULTI_NEU_FULLTEXT_SOLR_COLLECTION=full
MULTI_NEU_SYSTEMSPLIT_METERINGPOINT_SOLR_COLLECTION=meteringpoint
MULTI_NEU_SYSTEMSPLIT_RESPONSE_SOLR_COLLECTION=response
MULTI_NEU_CCM_SOLR_COLLECTION=ccm
MULTI_NEU_ARCHIVE_SOLR_COLLECTION=archive

MULTI_ALT_FULLTEXT_PATH=E:/index/full
MULTI_ALT_SYSTEMSPLIT_METERINGPOINT_PATH=E:/index/meteringpoint
MULTI_ALT_SYSTEMSPLIT_RESPONSE_PATH=E:/index/response
MULTI_ALT_CCM_PATH=E:/index/ccm
MULTI_ALT_ARCHIVE_PATH=E:/index/arc

Momentan ist es noch nicht möglich, den SEARCH_TYPE SYSTEMSPLIT_METERINGPOINTTEMP mit SOLR zu nutzen. Melden Sie sich gerne bei unserem Support, wenn Sie daran Interesse haben.

Fehlerbehandlung

Zur Fehleranalyse erhalten alle Einträge in Lucene-Indizes das Feld written. Darin wird das Datum kurz vor dem Schreiben in den Index gespeichert. Dies kann helfen, festzustellen, ob ein Wert zu einem gewissen Zeitpunkt bereits im Index vorhanden war oder nicht. Insbesondere bei Indizes, welche eine INDEX_SYNC-Tabelle (Datenbanktabelle) nutzen, ist dieser Zeitpunkt relevant.

View Me   Edit Me