>>392
すみません
あとでゆっくり読んで見ます。
プログラミングはサッパリなので、読むのに苦労します。

>>393
えええ
それは随分酷い設計ですな・・・。


あと、書いてて気づいたんですが
日本語検索に弱いってのは、ようするにトークン文字に　【】　とか2バイトの記号が含まれてないので
そもそも、【mp3】を形態素解析(もどき)で分割出来ないという話なんですよね？

う〜ん。
本当に酷い設計ですな。
n-gramかSuffix Arrayを使った方が良いような・・・

メモリリソースを食べまくりだろうから、可変長n-gramを使って
登録時にうまい具合にハッシュ化するべきか、もしくは検索時に処理するべきか・・・
前者だとメモリの問題が(あと起動直後のログインラッシュ時のCPU負荷)、後者だとCPU負荷の問題があるねぇ。


やっぱ、後者でビタビアルゴリズムを使ってCPU負荷を減らしつつ、n-gramによる共起頻度探索をやってキャッシュを整備
ってのが、ベストか？
#受信したデータから順次クライアントで表示する方式だから、頻度の高い上位の結果を即座に返せば、後はゆっくり返しても体感上はスッキリ出来るはず

いや、試してないから、どうなるかサッパリだけどｗ