Optimierung der Volltextsuche

[ath]

Hallo,

die Volltextsuche nach beliebigen Strings funktioniert nicht weil sie in OTRS über einen Index erfolgt.
Das entscheidende Argument für die Index-Suche ist vermutlich die Geschwindigkeit.
Stimmt das?

Eine Volltextsuche ohne Index sollte unter folgenden Voraussetzungen möglich sein:

• Die Anhänge sind im Filesystem oder die DB ist passend optimiert.
• Die DB hat pro 100.000 Tickets mindestens 4 GB RAM zur Verfügung.
• Der Server hat mindestens 8 Kerne handelsüblicher CPUs.
• Bei der Datenbank ist die parallele Suche aktiviert.
• Die Daten der Tabelle article_data_mime (Spalte a_body) sind in Kleinbuchstaben in einer weiteren DB-Tabelle/-Spalte gespeichert.

Unter diesen Voraussetzungen dauert die Volltextsuche nach meiner Schätzung ca. 2 Sekunden pro 100.000 Tickets.
Getestet habe ich es mit 200.000 Tickets ohne spezielle Kleinbuchstaben-DB-Tabelle mit Postgres und kam auf ca. 6 Sekunden Suchzeit bei der Suche über alle Tickets.
Die Suche wird natürlich schneller wenn der Agent nur für einen Teil der Tickets leseberechtigt ist.
Wenn die Antwortzeit bis zu 10 Sekunden betragen darf wäre damit eine echte Volltextsuche bis zu 500.000 Tickets möglich.

Ist diese Abschätzung plausibel?

Ein zusätzlicher Bonus bei so einer indexlosen Suche:
Da in SQL bei der Suche Operatoren zulässig sind könnte man damit auch Tickets suchen welche den String1 aber nicht den String2 enthalten.
Beispiel:

Code: Select all

... LIKE '%notepad%' AND NOT ... LIKE '%notepad:      nein%'

Gruß
Albrecht

[root]

Hallo,

die Volltextsuche nach beliebigen Strings funktioniert nicht weil sie in OTRS über einen Index erfolgt.
Das entscheidende Argument für die Index-Suche ist vermutlich die Geschwindigkeit.
Stimmt das?

Ob das das entscheidende Argument war kann ich Dir nicht sagen, aber ich vermutet auch das das so ist.

Eine Volltextsuche ohne Index sollte unter folgenden Voraussetzungen möglich sein:

• Die Anhänge sind im Filesystem oder die DB ist passend optimiert.
• Die DB hat pro 100.000 Tickets mindestens 4 GB RAM zur Verfügung.
• Der Server hat mindestens 8 Kerne handelsüblicher CPUs.
• Bei der Datenbank ist die parallele Suche aktiviert.
• Die Daten der Tabelle article_data_mime (Spalte a_body) sind in Kleinbuchstaben in einer weiteren DB-Tabelle/-Spalte gespeichert.

Unter diesen Voraussetzungen dauert die Volltextsuche nach meiner Schätzung ca. 2 Sekunden pro 100.000 Tickets.
Getestet habe ich es mit 200.000 Tickets ohne spezielle Kleinbuchstaben-DB-Tabelle mit Postgres und kam auf ca. 6 Sekunden Suchzeit bei der Suche über alle Tickets.
Die Suche wird natürlich schneller wenn der Agent nur für einen Teil der Tickets leseberechtigt ist.
Wenn die Antwortzeit bis zu 10 Sekunden betragen darf wäre damit eine echte Volltextsuche bis zu 500.000 Tickets möglich.

Ist diese Abschätzung plausibel?

Das wir niemand verlässlich sagen können. Auch spielt eher die Anzahl der Artikel eine Rolle als die Ticketanzahl.

Ein zusätzlicher Bonus bei so einer indexlosen Suche:
Da in SQL bei der Suche Operatoren zulässig sind könnte man damit auch Tickets suchen welche den String1 aber nicht den String2 enthalten.
Beispiel:

Code: Select all

... LIKE '%notepad%' AND NOT ... LIKE '%notepad:      nein%'

Das sollte schon funktionieren wenn man ExtendedSearchCondition aktiviert.

- Roy

[ath]

Hallo Roy,

Auch spielt eher die Anzahl der Artikel eine Rolle als die Ticketanzahl.

wir haben im Durchschnitt 4 bis 5 Artikel pro Ticket.
Ok, ich hätte die Abschätzung mit 4 oder 5 multiplizieren und statt Ticket Artikel schreiben müssen.

Code: Select all

... LIKE '%notepad%' AND NOT ... LIKE '%notepad:      nein%'

Das sollte schon funktionieren wenn man ExtendedSearchCondition aktiviert.

Solange für die Suche nur die Index-Tabelle zur Verfügung steht kann das in dem Beispiel aus zwei Gründen nicht funktionieren:

• Die Zahl der Blanks zwischen "notepad:" und "nein" wird nicht wirksam weil diese Information im Index fehlt.
• Das Wort "nein" ist im Index normalerweise nicht vorhanden weil es ein Stop-Word ist.

Gruß
Albrecht

[root]

Hallo Albrecht,

• Die Zahl der Blanks zwischen "notepad:" und "nein" wird nicht wirksam weil diese Information im Index fehlt.

da hast Du natürlich Recht, wobei ich jetzt mal im Raum stehen lasse ob es zuverlässig ist das jemand bei der Suche eine bestimmte Zahl von Leerzeihen eingeben muss. Für mich liest sich das eher so, als ob das war hinter Notepad steht, auch per PostMaster-Filter in ein Dynamische Feld geparsed werden kann. Da könnte man dann ggf. auch auf die Volltextsuche verzichten.

• Das Wort "nein" ist im Index normalerweise nicht vorhanden weil es ein Stop-Word ist.

Auf das ist korrekt, aber diese Konfiguration anzupassen ist kein wirklicher Aufwand.

Wenn ich wirklich eine schnelle Volltextsuche brauche, dann muss ich andere Geschütze auffahren. Angefangen mit einer MirrorDB Konfiguration order ggf. einem anderen Backend das Elasticsearch, Solr, Lucene, Sphinx etc. zu nutzt.

- Roy

[ath]

Hallo Roy,

... das jemand bei der Suche eine bestimmte Zahl von Leerzeihen eingeben muss. Für mich liest sich das eher so, als ob das war hinter Notepad steht, auch per PostMaster-Filter in ein Dynamische Feld geparsed werden kann.

Das Beispiel mit

Code: Select all

... LIKE '%notepad%' AND NOT ... LIKE '%notepad:      nein%'

kommt bei uns tatsächlich so vor, natürlich nicht oft.
Das wird von einem Programm erzeugt wodurch die Zahl der Leerzeichen feststeht.
Ein Postmaster-Filter geht da nicht weil die Suche nicht im Voraus bekannt ist. Zur Sicherheit müssten wir dann alle Stop-Words deaktivieren.
Zudem wurde in dem Fall das Ticket über einen Webservice erstellt.

Wir haben zu einem Teil auch Auszüge aus Log-Dateien in den Tickets.
Das sind praktisch beliebige Strings, die aber immer genau gleich aufgebaut sind.
Da funktioniert die Index-Suche nicht zuverlässig.
Ein normaler Agent versteht das erst recht nicht sondern schimpft dann auf die unzuverlässige Suche in OTRS.

• Das Wort "nein" ist im Index normalerweise nicht vorhanden weil es ein Stop-Word ist.

Auf das ist korrekt, aber diese Konfiguration anzupassen ist kein wirklicher Aufwand.

Ja, aber die irgendwann doch benötigten Noch-Stop-Words sind im Voraus nicht bekannt.

Wenn ich wirklich eine schnelle Volltextsuche brauche, dann muss ich andere Geschütze auffahren. Angefangen mit einer MirrorDB Konfiguration order ggf. einem anderen Backend das Elasticsearch, Solr, Lucene, Sphinx etc. zu nutzt.

Die Idee ist relativ einfach:
Wir implementieren mit OTRS eine echte Volltextsuche in der bestehenden DB.
Postgres kann die Suchzeit durch Parallelisierung auf etwa ein Viertel verkürzen.
Bis ca. 500.000 Tickets ist die Suchzeit dann kurz genug weil unsere Agenten vermutlich bis zu ca. 20 Sekunden akzeptieren würden.
Dabei hilft natürlich das automatische Cachen des Suchergebnisses in OTRS.
Das würde uns die nächsten Jahre reichen.
Und alles mit den vorhandenen Mitteln (außer die Code-Änderungen in OTRS bzw. Znuny LTS).

Zudem hätten wir keine künstlichen Beschränkungen (Ticket::SearchIndex::Attribute) deren Werte sehr subjektiv sind und wo man es niemandem recht machen kann.

Bei mehr als 500.000 Tickets müssen wir dann schauen.
Optionen wären:

• Prüfen ob Postgres (oder eine andere DB) besser parallelisiert werden kann
• Eine zusätzliche DB-Tabelle zur Vermeidung der Wandlung in Kleinbuchstaben
• Überflüssige Tickets löschen
• Evtl. MirrorDB

Danke für die Hinweise.

Viele Grüße
Albrecht