Omnifind, Anzahl der Indexspalten

[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

[Rainer Ross]

Hallo Forum,

zum Thema Performance der Indexerstellung habe ich einige Tests durchgeführt, damit ich handfestes Zahlenmaterial liefern kann.

HW 720 7+ 2 Cores, SW 7.2 OmniFind 1.3

Für die Parallelisierung der Indexerstellung und der SQL-Aufrufe auf die Prozessorcores ist SMP sinnvoll: 5770SS1 Option 26. Es kann für die komplette Maschine im Systemwert QQRYDEGREE oder pro Job aktiviert werden. Bei mir ist im Systemwert QQRYDEGREE *MAX eingestellt.

SMP ist bei Systemen ab 2 Cores nützlich. Eine ausführliche Beschreibung findet sich hier:

http://www.ibm.com/developerworks/da...1milligan.html

Einige von uns wissen, dass es in-Memory auf IBM i oder AS/400 schon seit über 15 Jahren gibt und zwar über den Befehl SETOBJACC. Damit können komplette Dateien oder Programme in einen Speicherpool gelegt werden. Für die Performanceoptimierung der Datenbankzugriffe habe ich je nach Anwendung zwei Wege gefunden.

- inMemory für RPG-Programme mit native Zugriff über chain/setll/read -> SETOBJACC

- inMemory für RPG-Programme mit embedded SQL -> ab 7.1 keepinmem *yes + SMP ab 2 Cores

An dieser Stelle bin ich für weitere Ideen sehr aufgeschlossen.


Doch nun weiter mit OmniFind. Zunächst habe ich eine einfache Datei mit zwei Feldern erstellt.

 create table tsto.employp                             
       (empid   int,                                   
        skill   char(100),                          
        primary key(empid))                            
        keep in memory yes;                            
                                                       
 Label on Table  employp  is  'Datei Employee'; 

- Dann schreibe ich per beigefügtem Programm Daten hinein.

- Als nächstes erstelle ich mit dem Script den OmniFind Index. Das Script erzeugt unter anderem eine logische Datei mit Indexinformationen und drei Trigger für Einfügen, Ändern und Löschen.

 call sysproc.systs_create('tsto','employ01','tsto.employp(skill)', 
 'ccsid 1208 language en_US update frequency none update minimum 1  
  index configuration(ignoreemptydocs 1 , updateautocommit 0 )'); 

- Jetzt ist der Index noch ohne Daten. Mit folgendem Script wird der Index aufgebaut. Das könnte man bereits im vorhergehenden Script tun, aber hier habe ich mich entschieden, das Aktualisierungsintervall selbst zu bestimmen. Das Script kann auch einfach mit RUNSQLSTM im Dialog oder Batch aufgerufen werden. Es muss nur laufen, wenn im Textfeld, das für den Index herangezogen wird, Änderungen vorgenommen oder Sätze hinzugefügt oder gelöscht werden.

call sysproc.systs_update('tsto','employ01','using update minimum'); 

Beim Aufbau des Index komme ich zu folgenden Messergebnissen

100.000 Sätze 46 Sekunden
1.000.000 Sätze 8 Minuten

@Dieter - bei Problemen mit OmniFind hilft Dir das developerWork Forum gerne weiter. Ich hatte zwei Fragen gepostet, die mir innerhalb kurzer Zeit beantwortet wurden.

https://www.ibm.com/developerworks/c...&tags=omnifind

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