Hallo KM

Var 1.
Versuche einmal nur die Textdaten in einer eigene Datei auszulagern. (1b)

In unserem Fall haben wir einen 180 MB Artikelstamm (mit Duplikaten für Schwesterfirmen....) wovon der reine Textteile wenige MB ausmacht.

Das hat schon viel gebracht. 1xTag aufbauen + ev. Updatestrategie (Trigger, Datum...)wenn 1xTag aktualisieren nicht reicht

(1b) wenn die Daten auf mehrere Tabellen verteilt sind, bringt das auch wieder einen Zeitvorteil, da beim Suchen nur 1 Datei (ohne Join) durchsucht wird.

Der Vollständigkeit halber, noch Überlegungen von mir:
Var 2.
Selber eine Volltextsuche alias MySQL nachbauen. Also eine Wörterbuch aufbauen (wort-id, wort) und die Datei (Firma, Artikel, wort-id x n).
Nur sinnvoll bei ausgeschriebenen Artikeltexten.

Var 3.
Ich bastle gerade eine Volltextsuche für externe Kataloge/Lieferantendaten usw. Dabei lese ich die Artikeltextdaten in die Javadatenbank H2 (als RAM-Variante) und kommunzieren dann mit dem Javaprogramm (Prototyp mit DataQueues, teste noch Sockets).
Hab da auch unsere Artikel-DB mal getestet: 100.000 Artikel in < 0.2 Sekunden...

BTW: Vergleich mit MySQL&Co. sind nur bedingt aussagekräftig.
a) MySQL&Co sind zwar bei einer Abfrage schneller, aber bei mehreren Abfragen gleichzeitig, fällt die Performance doch meistens hinter die AS/400.
b) 100.000 Sätze sind nicht gleich 100.000 Sätze. Da muss man schon die Satzlänge bzw. das Gesamtvolumen mitanschauen.


Robert P.