Omnifind, Anzahl der Indexspalten

[dschroeder]

Hallo,
hat jemand bereits Erfahrungen mit Omnifind auf der iSeries?

Wir probieren ein wenig damit herum. In einer Adressdatei haben wir mehrere Felder, auf denen ein Volltextindex sinnvoll ist: NAME1, NAME2, ORT, ...

Die erste Idee ist natürlich, auf jeder Spalte einen eigenen Textsuchindex anzulegen. Das Aktualisieren des Index dauert aber irre lange (ca. 70 Sekunden pro Spalte für 1000 Sätze).

Weiß jemand, ob man auch einen Index der Form "NAME1 concat NAME2 concat NAME3" anlegen kann? Falls ja, wäre das sinnvoll?

Dieter

[Fuerchau]

Ich glaube ab V6 gibt es auch berechnete Indizes. Diese wirken allerdings nur wenn eine Where-Bedingung dann auch genau diese Berechnung enthält.
Bei Volltext-Suche ist das aber kaum gewünscht oder möglich.
Ich denke nicht, dass nach "where NAME1 concat NAME2 concat NAME3 = Blabla" gesucht wird.

Je nach gewünschter Komplexität kann man da eher was mit Trigger und eigenem Index machen.
Man nehme eine Identity-Spalte (oder nur einen Zähler) für die Hauptdatei.
Per Trigger zerlegt man die Suchfelder in einzelne Begriffe (Ersetzung von Sonderzeichen o.ä.) und schreibt diese als Schlüssel mit der Identity-Spalte in eine neue Tabelle.
Nun kann man beliebige Suchen aus der neuen Datei unter Verwendung von Like oder Soundex() durchführen ohne komplexe Volltextsuchen einzusetzen.

Allerdings sollte die Aktualisierung für die Volltextsuche doch automatisch, also auch triggergesteuert, laufen?

[dschroeder]

Danke für die Antwort. Meine Frage bezieht sich nicht auf "normale" Indizes. Bei denen gibt es jetzt auch die berechneten Indizes. Die würden mir in der Tat nichts bringen. Deshalb probiere ich ja ein bisschen mit Omnifind herum. Damit kann man echte Volltextindizes erstellen. Meine Frage ist deshalb, ob jemand eine Syntax kennt, mit der man bei Omnifind zusammengesetzte Indizes erstellen kann.

Die Aktualisierung der Volltextsuche kann nur zeitgesteuert gestartet werden. Das minimale Intervall ist 5 Minuten. Eine schnellere Aktualisierung lässt IBM nicht zu (Es sei denn, man startet die Indexierung manuell).

Das Suchen mit Omnifind geht dafür ziemlich gut.

Die Idee mit der eigenen Suche ist natürlich auch OK. Aber ich gehe im Moment davon aus, dass Omnifind das alles für einen tun sollte. Dafür soll es ja schließlich gemacht worden sein.

Dieter

[Fuerchau]

Zu Omnifind kann ich natürlich nichts sagen.
Aber aktualisiert der nur die geänderten Daten und macht der immer eine Komplett-Indizierung?
Sonst könntest du ja auch per Trigger die Indexierung wieder anstoßen.
Dann läuft diese nur wenn sich tatsächlich was ändert.

[dschroeder]

Man muss einmalig natürlich den kompletten Index erstellen. Ab dann wird nur inkrementell aktualisiert. Omnifind setzt automatisch Trigger auf die Basisdatei, die die geänderten Datensätze zwischenparken. Alle 5 Minuten (oder welches Intervall man auch immer einstellt), werden die Sätze aus der Zwischendatei dann in den Index eingepflegt.

Mein Problem ist allerdings nicht das Aktualisierungsintervall oder das Anstoßen der Aktualisierung. Ich bin mir im Moment unsicher, ob man jede (Text-)Spalte unserer Adressdatei einzeln indizieren sollte oder ob man ein concat aller Textfelder indizieren sollte (dazu fehlt mir übrigens noch die Syntax).

Deshalb die Frage: Arbeitet überhaupt jemand mit Omnifind? Falls ja, wie habe ihr das gemacht? Und habt ihr Performanceprobleme?

Dieter

[camouflage]

Am Besten du frägst mal Rainer Ross (nur suchen).
Der hat mit OMNIFIND eine Hotelsuchmaschine (myhofi.com) auf der Power i realisiert.
Vielleicht kann er dir weiterhelfen.

Hier noch zwei Links dazu:
http://www.centerfieldtechnology.com...%20Webcast.PDF
http://www.quser.org/sites/default/f...1_omnifind.pdf

@rainer (gern geschehen) ;-)

[dschroeder]

Vielen Dank für die Tipps. Die beiden PDFs sind auch schon sehr interessant.
Mich wundert allerdings, dass es anscheinend kaum Leute gibt, die Omnifind bereits einsetzen. Ist das denn so exotisch? Es ist doch schließlich ein IBM-Produkt, das kostenlos auf der iSeries verfügbar ist.

Ich würde gerne mal praktische Erfahrungen von Anwendern hören (bzw. lesen).

Omnifind ist (aus meiner Sicht) keine hyperkomplexe Software. Mit ein paar SQL-Zeilen bekommt man das in wenigen Minuten grundsätzlich zum Laufen. (Allerdings muss man genügend Zeit für die Indexerstellung mitbringen ).

Ich dachte, es gäbe mehr Leute, die das bereits im Einsatz haben und etwas dazu sagen können.

Dieter

[Fuerchau]

So komplexe Suchen, dass eine Textsuchmaschine benötigt wird, gibt es bei ERP's eher selten.
Bei Omnifind geht es ja eher um Textrecherche also Indizierung von komplexeren Dokumenten als ein paar Stammdaten.
Es macht auch keinen Sinn ein Concat-Feld zu indizieren, da man hier für die Worttrennung wieder ein Leerzeichen einfügen sollte. Schließlich könnte das vorherige Feld ja bis zum letzten Zeichen voll sein.
Und ob Ominfind nun 1 Spalte aus einer Datei oder N Spalten indiziert sollte von der Zeit fast unerheblich sein.

Ich würde dann noch einen eigenen Trigger anhängen, der bei jeder Änderung eines betroffenen Feldes die Indizierung startet, dann ist man eben aktueller und es dürfte dann nur der eine Satz indiziert werden.

[Rainer Ross]

Hallo Dieter,

das finde ich toll, dass mit OmniFind experimentiert wird. Unter folgendem Link habe ich einen Artikel auf Xing für einen ersten Eindruck veröffentlicht:

https://www.xing.com/communities/pos...enn-1008076485

Zu Deiner Frage mit folgendem Index: "NAME1 concat NAME2 concat NAME3" kann ich leider nichts sagen. Das habe ich selbst noch nicht probiert.

OmniFind hat ein paar Vorteile, was die Volltextsuche und die Suchgeschwindigkeit angeht.

- OmniFind wird in Embedded SQL in RPG/COBOL unterstützt

- Es ist für folgende Feldtypen sinnvoll: Char/Varchar/CLOB/XML

- Man kann auch IFS-Verzeichnisse und Spools als Datenquelle angeben.

- Groß- und Kleinschreibung und Umlaute spielen bei der Formulierung der Suche keine Rolle
select * from datei where contains(name, 'Müller') = 1 findet Müller und Mueller

- Es können normale SQL und OmniFind-Statements gemischt werden
select * from datei where plz = '86900' and contains(name, 'Müller OR Maier OR Schmidt') = 1

- Es sind und/oder/nicht Verknüpfungen möglich
select * from datei where contains(name, 'Müller - Karl') = 1 oder contains(name,'Müller NOT Karl')
Findet alle Müller außer Karl Müller

- Wildcards sind möglich
select * from datei where contains(name, 'Schmi*') = 1 oder contains(name,'*text*) = 1

- Die Definition von Synonymen ist möglich. Das habe ich noch nicht getestet, da man diese als XML-Datei anlegen muss.

Die Suchgeschindigkeit ist gut und kann bei geschicktem Einsatz der Indizes (hier hilft der Index-Advisor des Operation-Navigators) einen Performancesprung bis Faktor 5 bringen.

Wie Du selbst schon festgestellt hast, dauert der erstmalige Aufbau des Indexes sehr lange. Beim nächstenmal geht es schon schneller, dann werden nur noch die geänderten Sätze aktualisiert.

Ich habe mit OmniFind unter 7.1 mit Version 1.2 begonnen. Jetzt arbeite ich mit 7.2 und OmniFind-Version 1.3, hier hat sich von der Performance und den Möglichkeiten noch einiges getan.

Auf jeden Fall ist es interessant, die PF's und LF's mit *keepinmem - ab 7.1 - in den Speicher zu laden, um noch mehr Performance herauszuholen.

Bei Fragen kannst Du dich gerne an mich wenden.

Herzliche Grüße
www.myhofi.com
Hotels finden - leicht gemacht

[dschroeder]

Vielen Dank für die Antworten!
Wir arbeiten auf 7.1. Das mit dem "sehl lange dauern" finde ich etwas bedenklich. Wir haben eine Adressdatei mit ca. 4 Mio Datensätzen. Da würde eine Volltextindizierung auf einer Spalte bereits mehrere Tage dauern! (wenn unsere Hochrechnung stimmt). Das kann doch nicht sein, oder? Möglicherweise haben wir noch ein Problem in der Konfiguration der Speicherpools oder so. Vielleicht hat der Textserver nicht genug Speicher?

Das Schlüsselwort *KEEPINMEM kannte ich noch nicht. Mal sehen, was damit geht!

Erstmal vielen Dank!
Dieter

[Rainer Ross]

Hallo Dieter,

für die Dauer gebe ich Dir ein Zahlenbeispiel:

Datenfeld 32K, ca. 150.000 Sätze, maximale Dauer der Indexerstellung 5 Minuten

HW 720 7+ 2Cores

Herzliche Grüße
www.myhofi.com
Hotels finden - leicht gemacht

[dschroeder]

Hallo Rainer,
dann muss bei uns irgendetwas falsch sein. 1000 Sätze mit einer Feldlänge von 30 Bytes dauern 70 Sekunden. (Ich meine natürlich die Erstellung des Textsearch-Index, nicht einen "normalen" DB2-Index.)

Wenn ich richtig informtiert bin, haben wir als Hardware eine Power 740 (ich glaube, mit 8 oder 12 Prozessoren) und 1 TB Hauptspeicher. Das müsste für die paar Datensätze eigentlich genügen.

Dieter