Suche in großen Datenbeständen

[Daniel]

Nochmal zur Fulltext-Suche.
Wir hatten das mal in der XUG-Zürich behandelt, und es geht mit den Low Level Funktionen relativ zügig.
Und zwar ist es direkt damit (zB. FRead() ) schneller als in dem Beispiel von Alaska.

Aber wie es ganz genau geht, kann ich nicht mehr sagen, da müsste man ausprobieren.
Vermutlich jeweils die ganzen Sätze als String durchsuchen.
Ich nehme aber "Pi mal Handgelenk " mal an, dass es sich erst lohnt, wenn Du mehr als 2 Felder durchsuchen musst ...

[Werner_Bayern]

Wenn du CDX nehmen kannst

Leider nein, zwecks Kompatibilität mit alter DOS-Version und vieler anderer alter Programme, die auf die Daten zugreifen.

[AUGE_OHR]

... also auch "STROM" in "ABB Stotz Fehlerstromschutzschalter".
...
Ein $ - Scope wäre super.

verrückte Idee ... SOUNDEX ?

ich suche ja nach Ziffern die Teil eine Tel / Handy / Fax / Kto etc sein könnten.
unter PostgreSQL hab ich letztens in was über "Fulltextsearch" mit SOUNDEX gelesen ... mit "Index" ...

es geht da um Levenshtein / Metaphone / Double Metaphone sowie hstore
bei den ersten 3 handelt es sich wohl um Algorithmen während hstore noch "Operators and Functions" hat.
und dann gibt es noch GIST / GIN

Indexes
hstore has GiST and GIN index support

wenn man also einen Index

Code: Alles auswählen

INDEX ON SOUNDEX(Text1+Text2) ...

machen würde ...

[Werner_Bayern]

Soundex() - Diese Funktion wird von Xbase++ nicht unterstützt

Aus der Hilfe.

[AUGE_OHR]

Soundex() - Diese Funktion wird von Xbase++ nicht unterstützt

Aus der Hilfe.

YUP ... deshalb hab ich ja auch die 3 Algorithmen (Levenshtein / Metaphone / Double Metaphone) zitiert.
im Grunde könnte man "alten" Cl*pper "C" Code nehmen ... ot4xb ... und das ganze "Deutsch" anpassen ...
es geht ja hier nur um die Idee einer Function, im IndexKey(), aus "Buchstaben" etwas anderes zu machen um es dann per SCOPE einzugrenzen.

wenn man wirklich "Fulltext Search" haben will müsste man, wie bei PostgreSQL v9.x wohl möglich, einen "Index" für "jedes Wort" erstellen.

[Werner_Bayern]

Servus Jimmy,

danke. Der Aufwand ist mir zu groß, diesen Monat, spätestens im Dezember soll ja eh endlich die "public CTP 3" kommen. Dann wird umgestellt auf SQL.

[brandelh]

Ich habe unsere neue Prof Sub zähneknirschend bestellt

[Werner_Bayern]

Ich habe unsere neue Prof Sub zähneknirschend bestellt

Ich bereits 2x (Standard), ohne irgendein Update zu bekommen.
Das SR1 war beim Xbase++ Neukauf Ende 2009 bereits dabei, seither gab es nichts, nur 1 (!) Fehlerbereinigung.
Aber das Thema wurde ja schon mehr als ... besprochen.

[AUGE_OHR]

danke. Der Aufwand ist mir zu groß,

c:\ALASKA\XPPW32\Source\samples\basics\CAPI\soundex.obj

diesen Monat, spätestens im Dezember soll ja eh endlich die "public CTP 3" kommen.

"wer" sagt das ???

Dann wird umgestellt auf SQL.

JA ... das werden dann (hoffentlich) einige tun.

[Werner_Bayern]

"wer" sagt das ???

Alaska in einer Mail an mich.

[AUGE_OHR]

Alaska in einer Mail an mich.

... als Weihnachts-Geschenk über das man sich ärgern darf ...

[Tom]

Arctica hin oder her - man sollte nicht meinen, dass eine willkürliche Instring-Suche mit einem SQL-Server automatisch rasendschnell wird. Die Anbieter, die beispielsweise im Web etwas Derartiges ermöglichen, tricksen auch. So wird das Amazon-Sortiment verschlagwortet, damit die Suche in den Millionen Artikeln halbwegs brauchbare Antwortzeiten liefert, und Google ergänzt derlei um parallel suchende Maschinen. Wenn man bei Amazon irgendeinen Artikel sucht und findet, der "rechteckig" ist (etwa eine Vase oder so), und man sucht anschließend mit einer ähnlichen Abfrage, aber ohne den Präfix "recht" (also nur "eckig"), findet man nicht die selben Artikel. Denn auch mit High-End-Servern und optimierten Statements scheitert eine solche Volltextsuche am gewaltigen Datenbestand. Dies nur als Hinweis. Man kann mit Leistung nicht alles erschlagen.

[AUGE_OHR]

verschlagwortet

was praktisch ein "Index" ist.
wenn ich das "richtig" verstehe nennt man das bei PostgreSQL einen GIN Index wie er z.b. für eine Dokumenten Verwaltung zur "Volltextsuche" benutzt wird.

[brandelh]

Im Prinzip könnte man einen Custom Index so anlegen (wenn ich es recht verstanden habe).
Suchbegriff mit $ im cFeld1+cFeld2+cFeld3 ... suchen.
Wenn vorhanden, diesen Satz mit dem Indexbegriff aufnehmen ...
Mit jedem Suchbegriff müsste man diesen kompletten Lauf machen, was natürlich erhebliche Zeit kostet,
aber einmal erledigt, wäre die Suche nach einem Schlüsselwort sehr schnell.
Beim Speichern sollte man natürlich genauso prüfen, ob eines der Schlüsselwörter vorhanden ist UND man müsste prüfen ob eines rausgeflogen ist.
Nicht ganz einfach, aber wenn man es braucht und die Anzahl der Schlüsselwörter begrenzt bleibt ...

[AUGE_OHR]

Im Prinzip könnte man einen Custom Index so anlegen (wenn ich es recht verstanden habe).
Suchbegriff mit $ im cFeld1+cFeld2+cFeld3 ... suchen.
Wenn vorhanden, diesen Satz mit dem Indexbegriff aufnehmen ...

ist in deinem Beispiel cFeld = 1 Wort ?

nimm doch einfach ein Text Memo ( Dokument ) als Beispiel ... "alle" Wörter werden einzeln "indiziert"
nach welchem Algorithmus der Index später "ausgewertet" wird ist z.b. des "Geheimnis" von Google ...

Beim Speichern sollte man natürlich genauso prüfen, ob eines der Schlüsselwörter vorhanden ist UND man müsste prüfen ob eines rausgeflogen ist...

Stichwort : SQL "Trigger"

[brandelh]

cFeld1+cFeld2+cFeld3 ...

ich meinte Feldnamen, die durchsucht werden sollen. Also so: field->Feld1+field->Feld2+field->Feld3

Beim Speichern sollte man natürlich genauso prüfen, ob eines der Schlüsselwörter vorhanden ist UND man müsste prüfen ob eines rausgeflogen ist...

Stichwort : SQL "Trigger"

die "Trigger" gibt es ja unter DBF nicht.
Ein SQL Server, der eine richtige Fulltextsuche unterstützt, wäre natürlich die bessere Alternative.

[georg]

Hallo,


die Überlegung, mehrere Felder in den Index zu nehmen, hat was für sich, aber auch was gegen sich: nämlich die Begrenzung des Index-Ausdrucks sowie des Wertes, der als Ergebnis des Ausdrucks kommt.

Wenn in einem Memo-Feld gesucht werden soll, gibt es erst recht Schwierigkeiten.

Dazu kommt, dass ein solcher Index auch verwaltet werden will ...

Je nach Hardware, Leitung, Datensatzgrösse etc. kann man ja theoretisch mehrere Threads laufen lassen, die parallel den Datenbestand durchgehen, und die Satznummern der übereinstimmenden Datensätze in einem Array ablegen, aus dem dann ein Browse incrementell angezeigt wird.

[Tom]

Man verschlagwortet und indexiert ja nicht, indem man zu jeder einzelnen Tabelle, die mögliche Schlagworte enthält, entsprechende Indexe und Felder aufbaut, sondern man führt solch einen Schlagwortindex sinnvollerweise getrennt. Der Trick besteht - wie so oft - darin, die Performanceschwierigkeiten auf Elemente zu verteilen, bei denen Performance irrelevant ist. Erfasst man beispielsweise einen Artikel mit einer umfangreichen Beschreibung, mag es zwei oder drei Sekunden kosten, den Schlagwortindex zu aktualisieren und anzupassen, aber der Benutzer kann und wird das hinnehmen. Im Ergebnis kann man dann aber eine sehr viel schnellere Schlagwortsuche zur Verfügung stellen, die über eine getrennte Schlagwortsammlung die dazugehörigen Artikel referenziert. Das ist natürlich, was die Programmlogik anbetrifft, deutlich aufwendiger als ein simples "SET FILTER TO cSuchBegriff $ artikelbeschreibung", aber der Benefit dieses Aufwands kann sehr groß sein.

Das ist ohnehin ein Prinzip, das man verinnerlichen sollte, das aber für viele von uns, die noch in Platz- und Zeitspareneopchen das Programmieren gelernt haben, schwer in die Köpfe zu bekommen ist. Ich habe beispielsweise eine Funktionalität, die in einer Tabellendarstellung gewaltige Datenmengen aus zig Tabellen aufbereitet. Das geschah bis vor kurzem zur Laufzeit; es sind also immer dieselben Daten aufbereitet worden, die sich allerdings auch laufend ändern konnten. Inzwischen habe ich diese Datenaufbereitung in jene Prozesse gezogen, die Daten ändern können, wodurch diese kaum spürbar verlangsamt wurden, aber die Darstellung der gesamten Datenmenge sehr, sehr rasant geworden ist. Hierfür waren zusätzliche Tabellen und Eingriffe an sehr vielen Stellen nötig. Das Ergebnis ist verblüffend, ohne dass die gesamte Systematik für die Benutzer spürbar irgendwo in die Knie geht. In DOS-Zeiten hätte ich nicht so gearbeitet, weil es im Hinblick auf den verfügbaren Massenspeicher riskant gewesen wäre. Das Problem aber gibt es nicht mehr.

[brandelh]

die Überlegung, mehrere Felder in den Index zu nehmen, hat was für sich, aber auch was gegen sich: nämlich die Begrenzung des Index-Ausdrucks sowie des Wertes, der als Ergebnis des Ausdrucks kommt.

Ich sprach oben von CUSTOM INDEX

INDEX ...
CUSTOM
Durch die Option CUSTOM wird ein Custom-Index erzeugt. Ein Custom-Index ist nach der Erzeugung leer und die enthaltenen Schlüsselwerte werden nicht automatisch durch die DatabaseEngine verwaltet. Die Schlüsselwerte eines Custom-Index müssen stattdessen vom Entwickler hinzugefügt bzw. entfernt werden. Dafür werden die Funktionen OrdKeyAdd() und OrdKeyRemove() verwendet.

Man indiziert also nicht den Inhalt eines oder mehrerer Felder, sondern legt den KEY-Ausdruck fest, der im Index zu einem Datensatz gespeichert wird.
Die Erklärung von OrdKeyAdd() ist allerdings nicht ganz eindeutig (wie man den KEY festlegt), genutzt habe ich das noch nie, aber dafür müsste es da sein.

[georg]

Hallo, Hubert -


soweit ich die Dokumentation verstehe, wird der komplette Schlüsselbegriff in den Index eingefügt, wenn OrdKeyAdd() ausgeführt wird.

Der Unterschied ist nur, dass man einen Datensatz aus der zugrundeliegenden Select()-Area zwischen 0 und n-mal in den Index aufnehmen kann, und dieser nicht standardmässig 1 mal aufgenommen wird (UNIQUE und CANDIDATE bleiben da mal aussen vor). Laut Dokumentation geschieht die Aufnahme des Index (und damit des Index-Begriffs) aber durch die DBE und lässt sich vom Programmierer nicht beeinflussen.

OrdKeyAdd() ermittelt den Wert für den Index-Key und schreibt diesen Wert mit dem Verweis auf den Datensatz in den Index. Mehr kann's nicht sein, da OrdKeyAdd() nur einen Verweis auf den Tag als Parameter akzeptiert.

Dadurch gelten natürlich weiter die Beschränkungen, welche die DBE für Ausdruck und Wert des Index festlegt.

(Siehe auch OrdKeyAdd).

[brandelh]

Beim Erstellen sollte man natürlich keine Feldnamen angeben, sondern eine Funktion oder einen Codeblock, der den gewünschten Schlüsselbegriff angibt.
Aber wie geschrieben habe ich das noch nie benutzt. Ich meine aber es gibt ein Beispiel in den Samples ... wie auch immer, war nur so ein Gedanke.

[azzo]

Hallo,

Was ist schnell oder langsam für Volltextsuche.

Ich habe folgenden Test gemacht:
Kundendatenbank (125 Felder)
205.250 Datensätze

Volltextsuche in allen Feldern nach "microsoft"
13.11.2012 22:27:20: START microsoft 80840.62
13.11.2012 22:27:22: fertig microsoft 80842.99
Treffer: 4 Datensätze

mfg
Otto

Code: Alles auswählen

 static aKunden := {}
function SearchFile( suchbeg )
   local nLocation, cData
   local nOffset := 0
   local cDBF    := ( "kunden.dbf" )
   local nPos    := 0
	*----------------------------------------------------------

   suchbeg := ALLTRIM(Upper(suchbeg))
   cData   := Upper(MemoRead( cDBF ))

   if Len(cData ) < 1
      MetroMsgInfo( "Infobox","Not Data to Search","File Error")
      Return Nil
   endif

   nOffset := 0
   do while .t.
	   nPos := INT( AT( suchbeg, cData, nOffset ))
		nLocation := INT( ( nPos - Header() ) / RecSize() ) + 1
		nOffset   := Header() + nLocation * RecSize() //+ RecSize()
      if nPos > 0 .and. nPos <  Header()
      else
	      if nLocation < 1
	         Exit
	      else
	         select kunden
	         goto nLocation
	         if DELETED() = .F.
                        aAdd( aKunden, getrec() )
                 endif
	      endif
     endif

   enddo

Return Nil
//----------------------------------------------------------------------------//

[brandelh]

Das ist schnell

Solange die DBF in einen String passt geht das mit memoread(). Wenn die Datei größer wird muss man diese blockweise einlesen.
Zu Clipperzeiten hatte ich einmal so eine Funktion gesehen (ich habe sie nicht mehr) die den DELETED() Status im Feld direkt ausgewertet hat und noch auf Suchfelder beschränkte.
Das war sehr komplex und bei Strukturänderungen fehlerträchtig.

Dein Ansatz mit

Code: Alles auswählen

 select kunden
 goto nLocation
 if DELETED() = .F.

ist genial und leicht zu erweitern um z.B. die Suche auf weniger Felder zu beschränken (einfach in dem Satz nochmal eine $ Suche auf die gewünschten Felder machen).
=D>

[Werner_Bayern]

Servus Otto,

Dein Code hat mich sehr interessiert, deshalb hab ich ihn sofort getestet. Was ich aber nicht verstehe, die dbf ist bei mir local shared geöffnet, das memoread ist dann aber erfolglos, auch mittels low-level-file Funktionen bekomme ich den Filefehler 32:

Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird.

Obwohl memoread und ich mittels low-level die Dbf im readonly-Modus zu öffnen versuchen.

Mit Wordpad und Co. funktioniert das Öffnen...

[nightcrawler]

Hallo,

Was ist schnell oder langsam für Volltextsuche.

Ich habe folgenden Test gemacht:
Kundendatenbank (125 Felder)
205.250 Datensätze

Volltextsuche in allen Feldern nach "microsoft"
13.11.2012 22:27:20: START microsoft 80840.62
13.11.2012 22:27:22: fertig microsoft 80842.99
Treffer: 4 Datensätze

schnell ist immer relativ. Ausgehend von den Rahmenbedingungen würde ich wagen zu behaupten, dass dies mit ADS im Bereich von 10ms (gegen Deine 2 Sek) erledigt ist. Volltext-Index vorausgesetzt.
Und Du kannst dann noch logische Suchen mit verknüpfen (zB "microsoft near windows and not office") und per SCORE bewerten, um die besten Treffer nach oben zu schieben. Aber das wollt Ihr ja nicht;)