組み込み型全文検索エンジンSenna (274ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
214(9): 2009/05/29(金)15:10 ID:QSnA4b1n(1) AAS
sanna+mecab+mysqlでためしてますが、検索結果がおかしい…
windowsだと200件ヒットするのにwinだと10件しかヒットしないんですけど何が原因ですか？
"win" in boolean mode
や
ft_min_word_len=1
など設定して再ビルドしましたがうまくいきません。
216: 2009/05/29(金)21:08 ID:??? AAS
>>214-215
漏れじゃないお！
SPLIT_ALPHA的なフラグを指定するといいです。
winのようなprefixだったら、
"*E-7 win"とかでもひっかかるかな。
ft_min_word_lenとかはSennaには全く影響がないので注意。
218(2): 214 2009/05/31(日)16:10 ID:??? AAS
お礼遅れて申し訳ないです。
*E−７で解決できました。
多くの回答いただき感謝します。
ps
wikipediaデータで実験してますが流石に全文検索は5分くらいかかりますねorz．．
220(1): 214 2009/06/02(火)13:56 ID:??? AAS
遅いですか?（ということはもっと早くなる！？)
メモリは2GでWikipediaデータは5Gぐらいです
まだチューニングをあまりしていないのでちょっといじって見ます
222: 214 [age] 2009/06/04(木)13:49 ID:??? AAS
>>221
ありがとうございます。
遅いのはやはりサーバスペックの問題ですね…発注してきます
度々で申し訳ないのですが、全文検索で「完全一致→非わかち書き→部分一致」の順で取り出したいのですがうまくいきません。
select title from searchindex where match(title) against('*E1,5 Google' in boolean mode) limit 10\G
*E1,5*D+などのプラグマもためしてみましたがだめでした。
show senna statusは以下のような感じです。
Table: searchindex
Key_name: si_title
Column_name: si_title
省17
223(1): 214 [age] 2009/06/04(木)14:37 ID:??? AAS
どううまくいかないのかを書き忘れましたorz…
完全一致が1番目にこないです。
---------------------
Top_10_Google_hits
Google_マップ
Google_Earth
Google←これが1番にきてほしい
…
--------------------
227(1): 214 [age] 2009/06/05(金)14:23 ID:??? AAS
みなさまありがとうございます。
>>224さん
いろいろ調べてみましたがそのやり方しかないのかもしれません…
公式ではEプラグマで実現できそうなのですが…
>>226さん
*E数値1[,数値2]プラグマもためしたのですが公式に記載されている挙動をしていないようです。
公式の説明ではE1,5で全文一致が１つ以下なら5つスコアを下げて部分一致をとる挙動になると思うのですが完全一致も部分一致も同じスコア値になっています。
+--------------------+-------+
| page_title | score |
+--------------------+-------+
省6
235(1): 2009/06/07(日)01:41 ID:??? AAS
>>233
インデックスは使われていると思うよ。
実際*E-7のプラグマも動いているし、Sennaまで処理が落ちているのは間違いない。
.SEN/.SEN.lは激しくランダムアクセスが走るので、
こいつらがオンメモリにないと単なるシーケンシャルスキャンより遅くなってもおかしくないな。
というわけで、>>214はMySQLのデータディレクトリにある.SEN、.SEN.lファイルの容量を計算する。
あと、http://dsas.blog.klab.org/archives/50860867.html にあるmymemcheckで、min_memory_neededを計算する。
(.SENの総容量 + .SEN.lの総容量 + mymemcheckのmin_memory_needed)が
実メモリサイズを超えていたら危険な香り。
239: 2009/06/10(水)01:58 ID:??? AAS
>>238
最高のパフォーマンス: インデックスも実データもメモリ上
まともなパフォーマンス: インデックスはメモリ上、実データはメモリ外
パフォーマンスでない: インデックスがメモリ外で、スラッシング起こしている
だろ。
B-treeインデックスもmmapにしろOSのキャッシュにしろ実メモリ上にないと遅いと思うぞ。
>>238はDBに大変詳しいようだから、>>214に何かアドバイスするといいのでは？
247: 242 2009/06/20(土)05:18 ID:??? AAS
メモリ 512MB 環境下で LIMIT 10000 の時のみ
2回目の数値が極端に悪くなって1回目と大差なくなっているのは、
1回目検索時に読み込まれたデータが多すぎてキャッシュから溢れたためだろう。
実運用では同じ検索語が連続してくることなど希だから
このキャッシュミス状態はかなり起きやすくなるはず。
なのでインデックスは全部オンメモリであることが強く望ましいのは間違いない。
が、だからといって
>>235
> こいつらがオンメモリにないと単なるシーケンシャルスキャンより遅くなってもおかしくない
などというアホなこともない。
省11
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.809s*