Volltextsuche

[KM]

Hallo,

gibt es irgendeine Möglichkeit bzw. Tools mit denen man eine Volltextsuche über eine iSeries-DB2 Datei performant durchführen kann ?

Der SQL-Befehl Select * from Datei where Feld like '%xyz%' dauert einfach viel zu lange.

Gruß,
KM

[BenderD]

Hallo,

da steckt halt ein full Table Scan dahinter, der seine Zeit braucht, da ist der schnöde SQL mit like nicht einmal schlecht, zumindest mit parallel Database Feature und entsprechender Hardware.
Wenn man den Full Table Scan vermeiden will, bleibt nur ein spezieller Suchindex, der allerdings nur realistisch möglich ist, wenn es da noch Restriktionen gibt.

mfg

Dieter Bender

Hallo,

gibt es irgendeine Möglichkeit bzw. Tools mit denen man eine Volltextsuche über eine iSeries-DB2 Datei performant durchführen kann ?

Der SQL-Befehl Select * from Datei where Feld like '%xyz%' dauert einfach viel zu lange.

Gruß,
KM

[Fuerchau]

Da gibt es noch den DB2 UDB TextExtender.
Mit dem soll man Inexe über Textspalten erstellen und komfortabel durchsuchen können.

[KM]

Der SQL mit like dauert leider zu lang (zumindest auf der iSeries). Für eine Datei mit 100.000 Sätzen braucht unsere iSeries dafür ca. 8 Sekunden. Da das Ganze in einer Web-Applikation benötigt wird, kommt das dann natürlich nicht in Frage. Auf einem anderen Server dauert das Gleiche mit denselben Daten in einer MySQL-Datenbank nicht mal 1 Sekunde.

Der DB2 Text Extender ist leider kostenpflichtig. Somit kommt das auch nicht in Frage. Wir bräuchten schon entweder Bordmittel oder zumindest Freeware-Tools.

Hat jemand evtl. Erfahrung mit Lucene oder ähnlichem ?

Gruß,
KM

[kuempi von stein]

...Für eine Datei mit 100.000 Sätzen braucht unsere iSeries dafür ca. 8 Sekunden. ...

Das erscheint mir merkwürden...

Habe hier gerade mal auf der Kiste nen Select abgesetzt (where xxname like ...) und das ging ruckzuck bei 1,5 MILL records....
Muss ja nen Grund haben...?

k.

[JonnyRico]

Hallo,

mich würde es auch ein wenig wundern wenn MySQL die DB2 auf der AS/400 um einen Faktor > 8 schlagen würde. Da muss eigentlich was anderes im Busch sein.

Sascha

[BenderD]

Hallo,

it depends on...
3 GigaHertz mit 1 GigaByte gegen 500 MegaHertz mit 500 MegaByte und 276 Terminals...

mfg

Dieter Bender

Hallo,

mich würde es auch ein wenig wundern wenn MySQL die DB2 auf der AS/400 um einen Faktor > 8 schlagen würde. Da muss eigentlich was anderes im Busch sein.

Sascha

[RobertPic]

Hallo KM

Var 1.
Versuche einmal nur die Textdaten in einer eigene Datei auszulagern. (1b)

In unserem Fall haben wir einen 180 MB Artikelstamm (mit Duplikaten für Schwesterfirmen....) wovon der reine Textteile wenige MB ausmacht.

Das hat schon viel gebracht. 1xTag aufbauen + ev. Updatestrategie (Trigger, Datum...)wenn 1xTag aktualisieren nicht reicht

(1b) wenn die Daten auf mehrere Tabellen verteilt sind, bringt das auch wieder einen Zeitvorteil, da beim Suchen nur 1 Datei (ohne Join) durchsucht wird.

Der Vollständigkeit halber, noch Überlegungen von mir:
Var 2.
Selber eine Volltextsuche alias MySQL nachbauen. Also eine Wörterbuch aufbauen (wort-id, wort) und die Datei (Firma, Artikel, wort-id x n).
Nur sinnvoll bei ausgeschriebenen Artikeltexten.

Var 3.
Ich bastle gerade eine Volltextsuche für externe Kataloge/Lieferantendaten usw. Dabei lese ich die Artikeltextdaten in die Javadatenbank H2 (als RAM-Variante) und kommunzieren dann mit dem Javaprogramm (Prototyp mit DataQueues, teste noch Sockets).
Hab da auch unsere Artikel-DB mal getestet: 100.000 Artikel in < 0.2 Sekunden...

BTW: Vergleich mit MySQL&Co. sind nur bedingt aussagekräftig.
a) MySQL&Co sind zwar bei einer Abfrage schneller, aber bei mehreren Abfragen gleichzeitig, fällt die Performance doch meistens hinter die AS/400.
b) 100.000 Sätze sind nicht gleich 100.000 Sätze. Da muss man schon die Satzlänge bzw. das Gesamtvolumen mitanschauen.


Robert P.

[KM]

Hallo Robert,

Deine Variante 3 hört sich ja interessant an. Ich war inzwischen aber auch erfolgreich.

Die Antwortzeiten per SQL sind bei uns deshalb so lange, weil es sich um eine Datei handelt dessen Textfeld 4000 Stellen (variabel) umfasst und in UTF-8 codiert ist. Deshalb dauert der SQL mit like bei 100.000 ca. 8 Sekunden. Bei einer anderen Datei mit einem kleinen Textfeld liegt die Antwortzeit auch unter 1 Sekunde.

Ich habe mir jetzt das Jakarta-Projekt LUCENE mal etwas genauer angeschaut und ein wenig getestet. Und ich muß sagen ich bin echt davon begeistert. Ich habe per Programm einen Index erstellt, in dem die Ergebnisse der Textdatenanalyse stehen. Und dann habe ich noch ein Programm erstellt, das die Suche durchführt. Beides sind kleine Java-Programme. Die Anwortzeiten der Suche liegen jetzt deutlich unter 1 Sekunde. Außerdem hat man viele Möglichkeiten der Suche. Man kann z.B. mit Wildcards arbeiten oder Begriffe mit AND bzw. OR verknüpfen. Und nicht zuletzt ist es sogar möglich das Ganze noch mit einer phonetischen Suche zu verknüpfen. Man kann auch Stop-Begriffe definieren, die man bei der Suche ignorieren kann und noch vieles mehr ...

Robert, schau Dir das doch mal an. Ich denke für Deine Applikation wäre das auch sehr interessant.

Gruß,
KM

PS: Muß jetzt erstmal schauen, was dieses Tool noch alles kann :-)