Omnifind, Anzahl der Indexspalten

[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

[dschroeder]

Hallo Rainer,
herzlichen Dank für deine Mühe!

Ich habe das ganze mal mit deiner Datei und deinen programmatisch erzeugten Daten probiert. (Allerdings ging keep in mem by mir nicht).
Ich komme etwa auf die gleichen Zeiten wie du. Ich muss jetzt mal sehen, wo die Unterschiede zwischen deinem und meinem Index sind. Meine Datei war z.B. nicht jounalisiert. Das scheint ein Problem zu sein.
Deine Tipps haben mir bereits sehr viel weitergeholfen. Anscheinend ist es kein grundsätzliches Problem unserer Omnifind-Installation.

Ich teste weiter.
Dieter

[andreaspr@aon.at]

Allerdings ging keep in mem by mir nicht

... ist eine Neuerung bei 7.2.

[Rainer Ross]

Hallo Dieter,

gern geschehen.

- die Angabe beim create table mit "keep in memory yes" ist ab 7.2 verfügbar. Man kann es auch beim CHGPF/CHGLF angeben

Siehe Seite 52 im PDF zu DB/2 7.2:
https://www-304.ibm.com/partnerworld/wps/servlet/download/DownloadServlet?id=suPLVXUxU$diPCA$cnt&attachmentName=ibm-db2-for-i-7-2-overview.pdf&token=MTQxMzgwNTg0Mzk3Mg==&locale=en_ALL_ZZ

- meine Datei ist ebenfalls nicht journalisiert, da es sich nur nur um einen Test handelt.

Viel Spaß beim Testen

Rainer

[Fuerchau]

Ich frage mich, wofür KEEPINMEM (ab V7R1) denn nun wieder gut sein soll.
Damit wird das normale Paging der AS/400 doch vollkommen unterlaufen.
Per SETOBJACC konnte ich hier auch schon entsprechend steuernd eingreifen, was aber insgesamt überhaupt nichts gebraucht hat.
Für den Moment wo ein Zugriff erfolgt werden dann jede Menge andere Seiten aus dem Pool verdrängt um eben für dieses Objekt Platz zu schaffen.
Während SETOBJACC für alle Zugriffsarten gilt, wird (laut Doku) KEEPINMEM nur von der SQE verwendet. Native-IO scheidet da also aus.
Mittels MEMORY_POOL_PREFERENCE kann ich zwar einen eigenen Pool angeben, garantiert ist dieser nicht und die SQE kann sich (laut Doku) auch anders entscheiden.
Wie lange werden die Seiten dann im Speicher vorgehalten?
Werden sie durch normales Paging wieder verdrängt?

Ich habe gelernt, dass die Seiten, die am häufigsten verwendet werden am seltensten verdrängt werden.
Wird also auf bestimmte Dateien (oder auch Programme) sehr häufig zugegriffen sind diese sowieso eher speicherresident.