-
SQL: Performance LIKE
Hallo liebe News Solution Community!
Erstmal danke an das tolle Forum, dass uns schon oft weitergeholfen hat
Jetzt ist es mal soweit, dass die Suchfunktion nicht die gewünschten Ergebnisse gebracht hat
Folgendes Problem (DB2):
Ein File mit mehreren tausend Rows beinhaltet eine Column mit 32000 Zeichen (A).
Die Anforderung ist eine Volltext-Suche in dieser Spalte.
Aufgrund der Datensätze ist LIKE sehr langsam.
Bsp.:
select TKNNR, TKNDATB, TKNTIME, TKNUSER, TKNTXT
from test.file1
where LOWER(TKNTXT) like LOWER('%Wartung%')
order by TKNTXT;
Eine Optimierung durch Indizierung (zb. 'Wartung%') ist aus unserer Sicht aber schwer möglich, denn der Such-Wert kann überall in dem Text vorkommen.
Gibt es hier evtl. eine Möglichkeit die Performance zu steigern?
Anm.: Dieses kostenpflichtige Produkt haben wir gefunden, allerdings streben wir eher eine kostenlose alternative an.
DB2 Text Search, Part 1: Full text search
Vielen Dank für die Hilfe,
Lg martrip
-
Wenn ihr 6.1 oder höher habt kannst du einen INDEX mit WHERE-Bedingung verwenden
Code:
create index lib.index on tab (sp1)
where sp2 like '%was auch immer%'
lg Andreas
-
Perfekt. Genau das haben wir gesucht.
Zwar haben wir den Index ohne Bedingung erstellt, da wir das sonst immer dynamisch machen müssten in der Anwendung aber jetzt ist das LIKE sehr flott!
Vielen Dank!
lg Marco
-
Zitat von martrip
Zwar haben wir den Index ohne Bedingung erstellt, [...] aber jetzt ist das LIKE sehr flott!
Wieso ist das LIKE jetzt sehr flott?
-
Zitat von Pikachu
Wieso ist das LIKE jetzt sehr flott?
Das würde mich jetzt auch interessieren?
Wird denn der Index überhaupt verwendet?
Birgitta
-
Steht nicht im Index File der Verweis auf die physische Datei? Ich bin jetzt eigentlich davon ausgegangen, dass, sobald man so ein Index File anlegt, dieses hergenommen wird, wenn man ein Select macht über deren Basis Datei.
Ich denke, ihr merkt aber, dass ich auf diesem Gebiet nicht besonders Sattelfest bin, um jegliche Erklärungen bin ich also dankbar
-
Was aber schon stimmt, ist der deutliche Gewinn an Performance. Ein Select mit Like hat vorher fast 30 Sekunden gedauert und jetzt dauert es 3.
-
Der neue Index beinhaltet nur jene Sätze wo der entsprechende Wert in der Spalte vorhanden ist.
Alle anderen Sätze fallen weg.
Dadurch hat der Index nur eine geringere Anzahl von Sätzen.
Durch die WHERE-Bedingung "SP like '%...%'" im SELECT wird automatisch der neue Index benützt und der Teil "SP like '%...%'" fällt einfach weg.
Kurz gesagt, ersparrt sich die DB alle Sätze mit dem Schlüsselwort LIKE zu durchsuchen da im Index schon alle Sätze beinhaltet.
lg Andreas
-
Der Index wurde anscheinend aber ohne die Bedingung erstellt.
-
Danke für die Erklärung Andreas.
Ich poste mal genau, was ich bis jetzt gemacht habe.
Zuerst habe ich den Index wie folgt erstellt
Code:
create index stamdattst.idx_termknp on stamdattst.termknp(TKNTXT)
where TKNTXT like '%wartung%'
So sieht dann das Select Statement aus
Code:
select TKNNR, TKNDATB, TKNTIME, TKNUSER, TKNTXT
from stamdattst.TERMKNP
where TKNTXT like '%wartung%'
order by TKNTXT;
Alles zusammen dauert das ca. 10 Sekunden.
Die Suche wird dann über eine Anwendung gesteuert und kann beliebig oft mit unterschiedlichen Such-Text aufgerufen werden.
Das Create des Index bringt allerdings dann einen Fehler, weil IDX File schon vorhanden ist.
Dann war der nächste Ansatz, einfach einen Index über die ganze Datei laufen zu lassen ohne Bedingung. Damit man dies nur einmal machen muss.
Was, aufgrund deiner Erklärung, wenig Sinn macht
Gibt es eine Möglichkeit, das dieses IDX File immer überschrieben wird?
Lg Marco
-
Sorry, ich glaub ich hatte dein Problem nicht ganz durchschaut.
Ich schätze du willst immer nach einem anderen Suchbegriff die Sätze ausgewählt bekommen.
Du kannst nur CREATE INDEX und DROP INDEX verwenden.
Allerdings macht ein Index nur dann Sinn, wenn du öfters ein Select mit dem Suchbegriff absetzen möchtest!
Im Normalfall würde auch die DB Temporäre Indice anlegen (MTI). Jedoch ist mir noch nie aufgefallen, dass sie einen Index mit WHERE-Bedingung anlegen würde.
Wenn du das brauchst, müsstest du ihn dir selbst vorgelagert anlegen.
Da gibt es jedoch einiges was zu beachten wäre! (Doppelt erzeugte Indice, Speicherplatz usw.)
Ich würd mir mal den Zugriffsplan für die aktuelle Abfrage anschauen ob man die nicht optimieren könnte. (Ist ALWCPYDTA auf *YES)
lg Andreas
-
Guten Morgen Andreas.
Stimmt. Genau so brauchen wir das.
Ich kann nicht erklären wieso, doch das create des index über die ganze Datei ohne Where mit dem Textfeld hatte schon einen Performance Gewinn von fast 10 Sekunden gebracht, was uns momentan reicht.
Vielen Dank für die Hilfe
Lg Marco
Similar Threads
-
By mariupol1963 in forum IBM i Hauptforum
Antworten: 9
Letzter Beitrag: 11-08-06, 13:06
-
By RLurati in forum IBM i Hauptforum
Antworten: 6
Letzter Beitrag: 18-01-05, 11:38
-
By woki in forum NEWSboard Programmierung
Antworten: 4
Letzter Beitrag: 18-12-04, 12:28
-
By itec01 in forum IBM i Hauptforum
Antworten: 9
Letzter Beitrag: 16-09-04, 18:38
-
By malzusrex in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 12-07-02, 10:09
Tags for this Thread
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks