Beispiel: Jemand sucht nach allen Einträge mit dem Ausdruck 仕事
wohl die einfachste Variante aber doch sehr prozessor- und speicherlastig.
Damit meine ich bereits die Zerlegung eines Eintrages in alle (oder alle sinnvollen) Bestandteile:
機械効率
械効率
効率
率
機械効
機械
械効
機
械
効
機
...
oder so ähnlich (z.B. mit Mecab-basiertem Tokenizing), jedenfalls wird es dann einen sehr umfangreichen Index geben. Die Frage ist dann nur noch, wie man auf dieser Menge am schnellsten Suchen kann. Entweder mit einer normalen DB oder mit einer SearchEngine wie Lucene.
LIKE ohne führendes Wildcard aber mit der Suche auf allen automatisch berechneten Tokens also z.B. LIKE '仕事%'
das wäre wie bisher, oder? auf alle Fälle sollte noch die Suche am Ende möglich sein also LIKE '%仕事'
nein, den Teilstring-Index gibt es ja noch nicht, der Wilcard am Ende ist ja wegen dem Teilstring-Index nicht mehr nötig
eine interessante Alternative, ist nur die Frage, wie das mit japanisch klarkommt.
Für deutsch könnte man auch problemlos die Volltextsuche von mysql benutzen, die nicht mit japanisch klarkommt.
Das Tokenizing würden wir ja dann nicht über Lucene machen, sondern selbst die Teilstrings raussuchen, nach unseren eigenen Logik. Der CJK-Tokenizer bei Lucene greift (wie fast alle Tokenizer) nur richtig gut bei großen Texten. Die Zerlegung einzelner Wörter in Bestandteile macht der nicht (afaik).
De Facto würde man in diesem Fall Lucene aber nur als DB verwenden, und wäre nicht wirklich schneller wie eine richtige DB, vorallem wenn sie im RAM ist.
Per cgrep auf einer index-datei suchen und die UIDs zurückliefern.
Beispielhaft auf dem Enwicklungsserver implementiert
patcht die Volltextsuche von MySQL
benutzt MeCab als Tokenizer
Senna installation
Java-Implementation von MeCab
Volltextsuche basierend auf Lucene
Java-Implementation von MeCab, Aktualisierung von sen