Mahlzeit Stephan,
alles was Dir Speed bringen würde hast Du uns verboten in unsere Antwort
mit aufzunehmen. Also: Nein.
Mit 150.000 Datensätzen wird der Index für index_word entsprechend groß.
Problem bei MySQL: Der FULLTEXT-Index ist langsam und selbst wenn Du auf
MATCH AGAINST umsteigen würdest, so kannst Du dann nur noch nach "...%"
suchen.
Wir entwickeln ke_search und können aus Erfahrung sagen, dass MySQL ab
einer bestimmten Datenmenge Dank seinem FULLTEXT-Index einen
Flaschenhals aufweist, den man dann gerne auf externe Indexer auslagert.
Wir verwenden z.B. Sphinx für unsere PREMUIM-Version von ke_search. Das
ist ne Sache von knapp 10-15 Minuten diesen Sphinx-Index auf Deinem
Server zu installieren.
Ich könnte mir vorstellen, dass man noch knapp 20% mehr Speed rausholen
könnte, wenn man indexed_search auf Basis von Prepared-Statements
umbauen würde. <ein Haufen Arbeit und not tested!!!>
Stefan
Am 18.07.2011 13:41, schrieb Stephan Vidar:
Hallo zusammen,
in einem Intranet haben wir die Indexed Search im Einsatz.
Mittels Crawler werden auch externe Dokumente (hauptsächlich PDF)
indiziert. Die Menge an Dateien (ca. 800) schlägt natürlich nun auch mit
entsprechend großen Index-Tabellen zu Buche (z.B. index_rel: 500.000
Einträge; index_word: 150.000 Einträge) was die Suche nun mit
Antwortzeiten von ca. 10 Sekunden und mehr gewaltig ausbremst.
Der Root-Server läuft unter Linux ist dediziert und eigentlich ganz
ordentlich ausgestattet. Die Suche nach Teilstrings via LIKE '%...%' ist
außerordentlich wichtig und kann nicht abgeschaltet werden. Auch sind
andere Lösungen wie Solr, mnoGoSearch oder kesearch innerhalb dieses
Projektes derzeit nicht gewünscht und greifbar. Sieht hier jemand
trotzdem Möglichkeiten, das Ganze zumindest ein wenig zu optimieren?
Gruß, Stephan
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
