組み込み型全文検索エンジンSenna
>>147 > 一応・・・動くんだけど、どうして動くのか判らない、そんなものができつつあります。 そういうふうにReadmeに書いておけば、自然と情報が集まってくる希ガス 「max_exprsに、検索クエリに指定する式の最大値を指定します。」 ってどういうこと?「検索クエリの式」は判るけど、「式の値」って何? ググって出てきた http://www.koders.com/python/fid8CE7DA8C27987E7393CB41EAD4B402A2741A5C1F.aspx?s=max_exprs を見ると「検索式の最大の数」だそうだが・・・。 じゃぁ、「*D+ nana」でPerlのSenna::Index->query_execを経由してsen_query_execで検索するときに、 0だと検索に失敗し、他の数字(試した数字の例:1,2,3,10,32,50)を指定して検索すると「セグメンテーション違反です」と 怒られるのはどうして? 文字コードの問題と切り分けるべく英数字で検索しても失敗する。何故? >>149-150 の問題があるけど 大体できたから 一応アップしてみた。 人柱版ということでよろしく。動作保証ナシ。でも俺の環境では動いた。 http://takatyan.info/sss/Senna_Site_Search-0.01.zip スクリプトなどのファイルは全部UTF8でエンコードしていますから 対応エディタをお使いください・・・。 >>150 の件について、 Senna::IndexのupdateメソッドにSenna::Values型のデータを渡して インデックス作ってみたけどやっぱりダメですね・・・。 >>151 試してみた。 なんかやたらモジュール要求されるな。 Senna の他にこんだけ追加モジュール要求された。 File::Extract Class::Data::Inheritable File::MMagic::XS Spreadsheet::ParseExcel OLE::Storage_Lite MP3::Info CAM::PDF RTF::Lexer 俺の環境が Perl 5.8.0 と古いせいもあるかもしれんが… で、なんとか mksss.pl 起動までこぎつけたが 新規 1778個 更新 0個 削除 0個 と出た後 Can't call method "mime_type" on an undefined value at mksss.pl line 156. でこける… 直前の $e->extract($key); が undef を返してるようなんだが… >>153 >>151 を作ったものです。 モジュールが大量に要る件についてはすみません・・・。俺自身も大量にインスコしました・・・。 えっとですね・・・それらはほとんどFile::Extractが必要とするものです。 File::Extractは、HTMLからテキストだけを抜き出すのに使ってます。 新規1778個っていうのはファイル数ですけど、そのくらいありますか? そういえば・・・画像ファイルとかを除外する処理をしていませんね。 ですから画像ファイルをインデックスしようとして失敗しているのかも。 $e->extract($key)がundefを返したらスキップするのがいいかもしれません。 そもそもHTMLファイルだけの環境でしかテストしてませんでした・・・ $e->extract($key)がundefを返したらスキップするには、 $e->extract($key) を $e->extract($key) || return; に直すといいかもしれません。 明日にでも画像ファイルなどが混在した状況でテストしなおしてみます・・・。 >>154 ども。 検索対象にしようとしたのは某 2ch 過去ログサイトで、 新規1778個っていうのはほとんど 2ch の過去ログです。 とはいえ関係ない種類のファイルも若干混じっているので 試しに明らかに HTML しか含んでいないディレクトリ指定してやってみても 新規 67個 更新 0個 削除 0個 Can't call method "mime_type" on an undefined value at mksss.pl line 156. てな感じでした… この67個は全部 DAT2HTML で HTML 化した 2ch の過去ログです。 漏れももう少し探ってみます… >>155 mksss.plの89〜92行目ぐらいの &update($index,$constants_code{$index->encoding()},\%StorageDB,\%ModifiedDB,\%TitleDB,$_); と print "新規: $i / @{[$#new + 1]} $_ \n"; を入れ替えて実行すると、どのファイルが問題なのか判るかと思います。 >>156 thx. 試してみたけど1個目の HTML でいきなりこけてた… あーうちの環境依存の問題かな… どんな HTML 食わせても File::Extract が undef 返すっぽいわ… Perl 5.8.0 環境で動かすのは諦めておとなしく Perl 5.8.8 で動かすことにしたらすんなり先に進んだよ。 で、やたら文字化けするから変だと思ったら、 $main::IndexConvert を 1 に変えておかないとダメなのね。 それでもやっぱりスニペットが文字化けしまくるし その関係か日本語でほとんどヒットしない。 で、さらに調べたところ、 File::Extract::Result->text() は 元の HTML の文字コードにかかわらず UTF-8 バイト列を返すっぽい (たまに UTF-8 文字列を返すこともある) ので、 164行目の Encode::from_to($buf,$guess, $encoding) if($main::IndexConvert); は Encode::from_to($buf, 'utf8', $encoding) if($main::IndexConvert); にしないとダメぽ。 ほか俺が使う時にデフォルト設定から変えた部分↓ $main::Indexcode = SEN_ENC_EUCJP; (MeCab に合わせて) $main::Indexflags = SEN_INDEX_NORMALIZE; (正規化する、N-gram 使わない) @main::GuessCode = qw/cp932 euc-jp utf8 7bit-jis/; (shiftjis より cp932 の方が無難かな) $main::SkinDir = 'skinfiles/'; (パッケージ展開した直後の状態に合わせて) で、文字化け問題は大方解決したんだが、 多数ヒットするキーワードで検索すると Out of Memory というエラーメッセージが出て結果が出ないことがある。 それから Readme にも書いてあるけど TITLE とか H1, H2 とか A とかに重み付けしたスコアリングは欲しいね。 >>157-159 これはこれはありがとうございます。 File::Extractはコントラクタにオプションを渡すと文字コードの変換をやってくれるらしいので、 それに任せることにして、mksss.pl自体での本文の変換はしないことにします・・・。 重み付けをやるには、前述のSenna::Valuesクラスを使ってのインデックス化と検索ができれば Senna側としては可能です。 あとは、そのためのHTMLを解釈する部分が作れればよいのですが・・・。 File::Extractじゃ無理っぽいね。自前で書くしかないかなぁ。 >>149 遅レスだけど、max_exprsはクエリで列挙できるキーワードの数の最大値ってことだよ。例えば、 "+ああん -いやん +ばかん -うふん" だと4つのキーワードがそれぞれの演算子と共に評価されるけど、max_exprsを超える数については無視される。 Tritonnだとmax_exprs=32固定なので、一度に指定できるのは32個までという仕様になってる。 sennaのインストールや使用方法がウンコするくらい簡単になったら お金出してでも導入する。 今のように難しくて面倒くさいうちは、LIKE%%検索で乗り切る。 likeで乗り切れるくらいならsennaいらないだろう 全文検索入れるか、まったく入れないかの選択になる ってか、mysqlのバージョンが進めば、標準でマルチバイトの全文検索に対応するかな? ところで Senna っていうと MySQL で使う話ばっかり出てくる気がするんだが Ludia 使ってる香具師おらんの? トリdってRPMで入れられるんだね 大分前にソースからパッチ当てて入れた時にはかなり大変だったけど ありがたいねえdd RPMのトリトン入れました 辞書をEUC-JPとして再構成したいのですが /usr/libexec/mecab/mecab-dict-index -d /usr/lib/mecab/dic/ipadic/ -f utf-8 -o /usr/lib/mecab/dic/ipadic1/ -c euc-jp とすると /usr/lib/mecab/dic/ipadic/char.def is not found. minimum setting is used /usr/lib/mecab/dic/ipadic/unk.def is not found. minimum setting is used. /usr/lib/mecab/dic/ipadic/unk.def is not found. minimum setting is used. reading /usr/lib/mecab/dic/ipadic/unk.def ... 2 emitting double-array: 100% |###########################################| dictionary_compiler.cpp(117) [dic.size()] no dictionaries are specified と言われてしまいます。 ipadic1の中を見ると char.bin unk.dic だけしかありません。 どうすればうまく辞書の再構成ができますか? >>164 そうだよそうだよソースだよ! MySQLが標準で日本語の全文検索に対応してくれりゃいいんだよね。 どこかの会社が全文検索を初めから使えるようにしたバージョン発売しないかな。 >>168 住商情報システムが売ってるんじゃないの? >>151 をなんとかこしらえた者ですが・・・ 試行錯誤の果て、Perlバインディングによる実現は挫折しました。 結局私はMySQLバインディング Tritonnに逃げました。 というか・・・ >>151 はインデックスの更新のために文書データを丸ごとBerkeleyDBに保存しておくので 実は、MySQLなりでDB作って検索するのと本質的に変わらないということに気付きました。 そんなわけでMySQL+tritonnでやるのなら、マトモに動くのが書けそうです・・・な。 Sunに買収されたことだし、ネイティブで日本語全文検索に対応してほしいね。 もちろん無償バージョンでも。 Perlバインディングがぜんぜん動かないので 買ったはいいがPerlから乗り換える気も起きずしまいこんでいた、Rubyの入門書を 引っ張り出してきてRubyバインディングを触ってみたらこれが 簡単に動く。 あのPerlバインディングどうなってるの・・・。 tritonnにmysql_configって入ってないですか? phpでmysqliを使えるようにするために必要みたいなのですが・・・ tarボールの中に入ってたのでコピーしたらできました >>175 それはまずいんじゃ…? mysql_config って私の認識では MySQL のインストール情報を 記録しておく (いつでも表示できるような) ミニアプリなので、 手順を踏んでインストールしないと意味がないもののような気がする。 パッケージ管理システムを採用しているような Linux ディストリビューションなら、 mysql-devel とか mysql-dev みたいな名前のパッケージを導入するのがいいのではないかな。 >>178 確かに妙な感じになったので RPM版をすべてアンインストールしてtarball版を使うことにしました たしかmysql-dev相当のがなんかしらんけどインストールされなかったよね -configもそのひとつだったとおもう specを調整しないといけなかったような 2chのスレのdatファイルをgz圧縮して格納しているんだが、 これをSennaで検索できるようにしたい。 インデックスを作るだけなら単に解凍してインデックスすればいいから いいけど、 問題はスニペット。 検索結果を20件ずつ分けて表示するとしても、 検索結果を表示するたびに20個のgz圧縮datを解凍して スニペットを作るというのは解凍が無駄なような気がする。 どうしたものか・・・。 スニペットを消すというのも手と言えば手だが思考停止に他ならないような気がする。 そうすると、解凍したdatをキャッシュするとかですかね・・・。 ちなみに現在の格納数は2818個です。 この2818個が196052KB(圧縮したサイズ)、 今後70GB程度まで格納を続けるつもりです。 196052KBの70GBに占める割合は0.2%ぐらいです。 解凍したものをポスグレとかMySQLに突っ込むのはダメなの? ポスグレの場合は、大きいレコードは勝手に圧縮されるはずだから、 容量もあまり食わないし、キャッシュとかもしてくれると思う。 MySQLもそうなんじゃない?知らないけど。 >>180 レスありがとうございます。 データベースですか・・・ 一応MySQLを使っていますがまだ勉強途中で圧縮されるかどうかは知らないです。 解凍したものをキャッシュするとすればそれが最適ですかね・・・ 判りました、ありがとうございました。 トリトンのipadicのdicrcで config-charset = EUC-JP ってなってるんですが、これ間違いですか? トリトンに組み込んでる辞書はUTF-8にしてるはずですよね? EUC-JPへの辞書コンバートがどうもうまくいかず 調べているうちに見つけました これが原因なのかどうかはまだ分かりませんが dirrcで設定したら正しくコンバートできました コンバートしてもdirrcは書き換わらないので そのままになってるみたいですね >>111-112 の SEN_INDEX_SPLIT_ALPHA とかを有効にしたいんだけど ソースからいれないと駄目なのかな? TritonnのLinux x86(non RPM packages)を使っています >>186 バイナリ配布のものでもいけるはずですよー。 http://pc11.2ch.net/test/read.cgi/php/1183501450/ から誘導されてきました。 ■環境 CentOS release 5.2 (Final) + Apache/2.2.3 + PHP 5.1.6 + Mediawiki v1.13.1 + Tritonn組み込みMySQL(http://qwik.jp/tritonn/ ) on MW ware version 5.0.0 (メモリ256MB) Tritonn組み込みMySQL = mecab + tritonn + senna +MySQL ■問題 Mediawikiの検索窓から、例えば検索キー「を膜上に」で検索すると、msqldが潰れます。 傾向としては、助詞を前に付けて検索を行うと、検索が終わらなくなるようです(例外はあった)。 ×:「を膜上に」「と化学物質の」「と化学物質」「に毛細血管」 ○:「を膜上」「膜上に」「化学物質」「化学物質の」「毛細血管」「毛細血管の」 同じようなトラブルにあった方いませんか?対応はどうしました? ■Backtrace シェル上にはBacktraceが延々と *** glibc detected *** /usr/sbin/mysqld: double free or corruption (out): 0x091c1018 *** ======= Backtrace: ========= /lib/libc.so.6[0x6a9b16] /lib/libc.so.6(cfree+0x90)[0x6ad070] /usr/lib/libsenna.so.0(sen_free+0x1d)[0x236409] 以下略 ■mysqlの遺言。最後に投げたクエリー SELECT /* Medicine */ page_id, page_namespace, page_title FROM `medntpage`,`medntsearchindex` WHERE page_id=si_page AND MATCH(si_title) AGAINST('+ U8e381ab U8e6af9bU8e7b4b0U8e8a180U8e7aea1 ' IN BOOLEAN MODE) AND page_is_redirect=0 AND page_namespace IN (0) LIMIT 20 ↑あわわ「medntsearchindex」か 誤:MW ware ↓ 正:VMware workstation version 5.0.0 潰れるってナニ? コア吐いてプロセスが死んじゃうの? ps -eFしてみると/usr/sbin/mysqld は残っているんだけど、サーバ越しには反応しない。 /sbin/service mysql restart とか打つと、延々反応無し。 kill -9 して再起動させないと駄目。 止まっちゃうような検索キー「と化学物質」を投げた直後にシェルには、これコアダンプって言うんでしょうか? メモリダンプしてるから多分そうなんでしょうね。 他の環境で再現されなければ、インストール方法とか環境の問題で片付けるしかなさそう。 ちなみにMediawikiにぶち込んだデータは3万件です。 どなたか、ヒントを頂ければ幸いです。とりあえず、環境を変えて再現性を取る予定。 *** glibc detected *** /usr/sbin/mysqld: double free or corruption (out): 0x091c1018 *** ======= Backtrace: ========= /lib/libc.so.6[0x6a9b16] /lib/libc.so.6(cfree+0x90)[0x6ad070] /usr/lib/libsenna.so.0(sen_free+0x1d)[0x236409] ・・・略 ======= Memory map: ======== 00110000-00263000 r-xp 00000000 fd:00 565891 /usr/lib/libsenna.so.0.0.0 00263000-00264000 rwxp 00153000 fd:00 565891 /usr/lib/libsenna.so.0.0.0 0037d000-00388000 r-xp 00000000 fd:00 720898 /lib/libgcc_s-4.1.2-20080102.so.1 ・・・略・・・ b7569000-b756a000 ---p b7569000 00:00 0 b756a000-b7f6e000 rw-p b756a000 00:00 0 bfe4b000-bfe61000 rw-p bfe4b000 00:00 0 [stack] っっっっ VMWare上でCentOS5.2を入れてやってみたんだけど、確かにインストールうまくいかない。init scriptが問題ある。 さらに、phpで使うときにどこで詰まるかも↓これ読んでちょっと分かった。 http://www.akiyan.com/blog/archives/2008/09/tritonnmysqlsen.html Tritonnの開発者の人に、CentOSですんなりインストールできないです、 と報告を上げておいたので、状況が改善するまでお待ちあれー。 Tritonn 1.0.9使用 INSERTとかUPDATEしようとすると反応しなくなっちゃう現象発生。 /etc/init.d/mysql restartでリスタートしようとしても反応なしでkill -9しないとダメ。 再起動したあともINSERTとUPDATEしようとすると無反応。 ぐぐったらSennaで2007年にデッドロックの問題があって修正されてるみたいだけど Tritonnに反映されてるの? http://lists.sourceforge.jp/mailman/archives/senna-dev/2007-September/000673.html >>193 インデックスのロックかかってるみたいね。 mysqldを落としてmyisamchk -rをすれば直るはず。 稼動中のデッドロックの問題は反映されてるけど、 途中でお亡くなりになった場合にはロックがかかりっぱになることがある。 FULLTEXTで使われる、()"' 等を含んだ語や、頭に+-~のついた語を検索したい場合 どのようにエスケープするべきでしょうか? 検索は下記のように行っています。 〜WHERE match (myText) AGAINST("*E-4D+ ABC" IN BOOLEAN MODE) >>195 \(とか\)とか\"とか\'とか、 "+test"とか"-word"とか、 できた記憶が。 >>196 早速有難う御座います。 この方法で試してみたいと思います。 明けましておめでとうございます 今年もよろしくです>Senna&Tritonn あめおめ書きこみキタコレ 今年はSennaの次期バージョンが出ますよー。名前も変わるお 今日FreeBSDのportsにtoriton当てようとして失敗した私が通りますよっと バージョンアップ早すぎだって グルーンガってamazonのsimpleDBとかっぽい感じかなー >>201 MonetDB的な感じでー。いちおうデータ保存についてはブログ書いてみた。 find.2ch.netみたいに2chのログを検索出来るようにするには、どうすればいいのだろうか 〜WHERE match(myText) AGAINST("+あああ -いいい" IN BOOLEAN MODE) いける 〜WHERE match(myText) AGAINST("-いいい" IN BOOLEAN MODE) 駄目・・・ NOTのみの検索ってどうしたらいいんでしょか? >>205 Senna dev メーリングリスト 2008年1月 保存書庫 http://lists.sourceforge.jp/mailman/archives/senna-dev/2008-January/thread.html 上記に「NOT検索のみを行うとAND検索になってしまう件について」というのがあるので 見てもらうと判るんだが、お望みのよう検索をするには WHERE NOT match(myText) AGAINST("いいい" IN BOOLEAN MODE) とMATCH句を否定すればよい。 加えて、「あああ」も「いいい」もどちらも含まないレコードを探したければ WHERE NOT match(myText) AGAINST("*D+ あああ いいい" IN BOOLEAN MODE) tritonnこれからどうなるんだろ・・・ >>206 ありがとうございます 出来ました! MLで >クエリを発行する用途 について書かれていたのですが、 私の場合(Senna導入以前からの実装を引きずってますが)一旦 大分類・小分類・期日指定 で全文検索を用いずにある程度データを絞ります 抽出されたデータのうち95%程度が条件Aに起因するものとして、残り5%の レアケースを調べたい場合に -条件A とやりたかったのです amazon EC2上の Ubuntu8.04 にtritonnをインストールしようとしているのだが、 ソースをmake install した後、mysql_install_dbをするといつまでたっても終わらん。 普通このコマンドってどれくらいの時間で終わるんだ? mysql自体ソースから入れたことないからわからんのだ・・ ちなみに以下の手順でやった *mecabをインストール #apt-get install mecab #apt-get install mecab-ipadic #apt-get install libmecab-dev +IPA辞書をUTF-8に変換 # /usr/lib/mecab/mecab-dict-index -d /usr/share/mecab/dic/ipadic -o /var/lib/mecab/dic/ipadic -f euc-jp -t utf-8 -p #/usr/lib/mecab/mecab-dict-index -d /usr/share/mecab/dic/juman -o /var/lib/mecab/dic/juman -f euc-jp -t utf-8 Mecabで利用する辞書の切り替え # update-alternatives --config mecab-dictionary (続く) (続き) *Sennaをビルドする #apt-get install build-essential senna を解凍したフォルダで #wget http://osdn.dl.sourceforge.jp/senna/33763/senna-1.1.4.tar.gz #tar xvzf senna-1.1.4.tar.gz #cd senna-1.1.4 #./configure --prefix=/usr #make #make install #ldconfig (念のため) *tritonnをビルドする #wget http://keihanna.dl.sourceforge.jp/tritonn/36449/tritonn-1.0.12-mysql-5.0.67.tar.gz #tar xvzf tritonn-1.0.12-mysql-5.0.67.tar.gz #cd tritonn-1.0.12-mysql-5.0.67 # apt-get install libncurses5 libncurses5-dev #./configure --with-senna --with-mecab #make #make install #groupadd mysql #useradd -g mysql mysql # cd /usr/local # cd mysql # chown -R mysql . # chgrp -R mysql . # bin/mysql_install_db --user=mysql $ time mysql_insert_db read 0m0.594s user 0m0.180s sys 0m0.260s ローカルでやってみたよ 人柱乙m9(^Д^) >>210 orz... 6時間待っても終わらなかった・・・ むー、Amazon EC2ためしにやってみようかしら。 今度はamazon公式イメージのfedora8でやって、rpmで入れたらすんなりはいった。 よくわからないubuntuイメージを使ったのがいけなかったのか? sanna+mecab+mysqlでためしてますが、検索結果がおかしい… windowsだと200件ヒットするのにwinだと10件しかヒットしないんですけど何が原因ですか? "win" in boolean mode や ft_min_word_len=1 など設定して再ビルドしましたがうまくいきません。 グニャラくんのブログをしっかり読めばわかる 要するに検索漏れ >>214-215 漏れじゃないお! SPLIT_ALPHA的なフラグを指定するといいです。 winのようなprefixだったら、 "*E-7 win"とかでもひっかかるかな。 ft_min_word_lenとかはSennaには全く影響がないので注意。 お礼遅れて申し訳ないです。 *E−7で解決できました。 多くの回答いただき感謝します。 ps wikipediaデータで実験してますが流石に全文検索は5分くらいかかりますねorz.. >>218 5分って遅すぎ! メモリか論理空間足りなくてスラッシングが起こってるんじゃね? 遅いですか?(ということはもっと早くなる!?) メモリは2GでWikipediaデータは5Gぐらいです まだチューニングをあまりしていないのでちょっといじって見ます >>220 0.何秒で検索できるはず。 Wikipediaデータが5Gくらいあるなら、メモリも5Gくらいないと厳しいよー。 んで、メモリ5G積むためには、OSも64bit化しないと。 >>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 Encoding: utf8 Index_type: NGRAM Sectionalize: OFF Normalize: ON Split_alpha: OFF Split_digit: OFF Split_symbol: OFF Initial_n_segments: 512 Senna_keys_size: 1146887 Senna_keys_file_size: 33628160 Senna_lexicon_size: 430378 Senna_lexicon_file_size: 12656640 Senna_inv_seg_size: 136482816 Senna_inv_chunk_size: 18223104 おもに参考にしたのは以下です。 ttp://lucene.jugem.jp/?eid=158 ttp://qwik.jp/senna/query.html どううまくいかないのかを書き忘れましたorz… 完全一致が1番目にこないです。 --------------------- Top_10_Google_hits Google_マップ Google_Earth Google←これが1番にきてほしい … -------------------- >>223 それは検索スコアの問題だから難しいす。 僕が作っている実システムでは、 ・タイトル完全一致のみで検索(Sennaのインデックスを使わずに、MySQLのB-Treeインデックスを作る) ・全文検索 を分けて2回クエリ投げています。 >>221 >Wikipediaデータが5Gくらいあるなら、メモリも5Gくらいないと厳しいよー。 DBを基礎から勉強し直せ デフォルトではスコア順にソートされないです。こんな風に書くとどうですかねぇ。。 select title, match(title) against('*E1,5 Google' in boolean mode) as score from searchindex where match(title) against('*E1,5 Google' in boolean mode) order by score desc limit 10\G みなさまありがとうございます。 >>224 さん いろいろ調べてみましたがそのやり方しかないのかもしれません… 公式ではEプラグマで実現できそうなのですが… >>226 さん *E数値1[,数値2]プラグマもためしたのですが公式に記載されている挙動をしていないようです。 公式の説明ではE1,5で全文一致が1つ以下なら5つスコアを下げて部分一致をとる挙動になると思うのですが完全一致も部分一致も同じスコア値になっています。 +--------------------+-------+ | page_title | score | +--------------------+-------+ | Top_10_Google_hits | 5 | | Google_Earth | 5 | … | Google | 5 | +--------------------+-------+ また"Google"で完全一致がとれません。"Google*"でも前方一致以外がとれたり(Top_10_Google_hitsもとれる)します。 >>225 全部キャッシュに載ってないと厳しいよ。 SSDならなんとかなるかもしれないけど。 >>227 Top_10_Google_hitsは前方一致でひっかかってるよ。 _は記号扱いなので、 Top 10 Google hitsと同じような感じでひっかかります。 >>228 これって全部キャッシュにのってないと 0.何秒が5分になるような検索エンジンなのかよw 少なくともインデックスがオンメモリであれば十分速度は出るんじゃないのか? >>228 お前がDB利用経験ないのはよくわかったからまず基礎を学んでから来い、な? >>230 5Gのコンテンツだと、経験上インデックスサイズがだいたい5Gになるんすよ。 というわけで、いつも目安としてコンテンツサイズ分はメモリとって、と言っています。 コンテンツがテストデータだったりして、同じ文言ばっかりだとコンテンツデータに比例してサイズ増えねっす。 インデックスを全部オンメモリに載せないと速度は出ないと思う。 インデックスファイルのうち、.lと.iはメモリに載っていてほしい。 i.cはメモリに載ってなくてOK。 スラッシング起きたら、どのエンジンでも速度でないよー。 >>231 基礎から学んでくるお!いいサイト教えて。 5G5分って16.7MBpsだぞ、シーケンシャルアクセス以下だ。インデックスが使われてない状態だろうが。 >インデックスを全部オンメモリに載せないと速度は出ないと思う。 >スラッシング起きたら、どのエンジンでも速度でないよー。 「最高のパフォーマンス」と「まともな速度」の区別もつかないDQNなのかよ >>>231 >基礎から学んでくるお!いいサイト教えて。 つGoogle >>233 >シーケンシャルアクセス以下だ おお、論点理解。確かにそうだねー。 >>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)が 実メモリサイズを超えていたら危険な香り。 >.SEN/.SEN.lは激しくランダムアクセスが走るので、 >こいつらがオンメモリにないと単なるシーケンシャルスキャンより遅くなってもおかしくないな。 オンメモリでないとシーケンシャルより遅くなるって、そんなのインデックスとは呼べないだろ インデックスをメモリに載るようにするのってDBの常識じゃないの? 最高のパフォーマンスとまともなパフォーマンスの区別もつかない奴が常識を語る時代なのか… >>238 最高のパフォーマンス: インデックスも実データもメモリ上 まともなパフォーマンス: インデックスはメモリ上、実データはメモリ外 パフォーマンスでない: インデックスがメモリ外で、スラッシング起こしている だろ。 B-treeインデックスもmmapにしろOSのキャッシュにしろ実メモリ上にないと遅いと思うぞ。 >>238 はDBに大変詳しいようだから、>>214 に何かアドバイスするといいのでは? パフォーマンスでない場合って検索に5分かかって当然なの? 仮にインデックスがメモリに乗らなかったとして、それで5分はないだろ。何か間違ってるとしか。 もしスラッシングが起きてるならメモリの割り当て量間違ってるってことだし。 とりあえず Wikipedia のデータ全文投入してインデックス作ってみたよ。 ■データサイズ 37822464 2009-06-19 01:03 wiki.001.SEN 387616768 2009-06-19 01:03 wiki.001.SEN.i 1073614848 2009-06-19 01:03 wiki.001.SEN.i.c 1073741824 2009-06-19 01:03 wiki.001.SEN.i.c.001 247463936 2009-06-19 01:02 wiki.001.SEN.i.c.002 801185792 2009-06-19 01:03 wiki.001.SEN.l 4686036956 2009-06-19 01:03 wiki.MYD 15630336 2009-06-19 01:03 wiki.MYI MYD と MYI の合計が 5G 弱、 SEN と SEN.i と SEN.l の合計が 1.2G 強。 ■mysqld メモリ使用量 インデックス作成時 → 1.3GB 検索時 → 60MB ■検索にかかる時間 SELECT * FROM wiki WHERE MATCH(text) AGAINST(?) LIMIT 10 で0.5秒くらい ■環境 D945GCLF (ATOM 230) メモリ: 2GB OS: Debian 5.0.1 おっと書きかけで送信してしまった ■検索にかかる時間 … 「wiki」や「space」等1万件以上ヒットする単語で検索 SELECT * FROM wiki WHERE MATCH(text) AGAINST(?) LIMIT 10 →初回0.2秒、2回目以降2ミリ秒 SELECT * FROM wiki WHERE MATCH(text) AGAINST(?) LIMIT 10000 →初回40〜60秒程度、2回目以降1.5秒程度 ■環境 D945GCLF (ATOM 230) メモリ: 2GB HDD: 40GB の IDE OS: Debian 5.0.1 (32bit) …ということで、LIMIT さえ効かせれば1秒以下で検索できるよ。 オンメモリじゃないとシーケンシャルスキャンより遅くなってもおかしくないとかアホじゃね? >>218 は LIMIT 句付けてないんちゃう? それかクエリ間違っててインデックス使われてないとか >>242-243 それか!全件結果を返すのはそりゃ重い。 .SENと.SEN.lがオンメモリなら十分速度出ると思うよー! この2つの一部がページアウトしてるとマジキツいっす。 2回目以降異常に早いのはクエリキャッシュが効いてそう。 /* SQL_NO_CACHE */を入れてみると本来の2回目以降の速度が計れるんじゃないかな。 測定基準整理して計り直してみた。 OS 起動直後、インデックスがキャッシュに一切載っていない状態で 「wiki」で検索 (1万件以上ヒットする) し、応答時間を測定。 1回目 LIMIT 10: 0.643秒 LIMIT 100: 1.129秒 LIMIT 1000: 5.787秒 LIMIT 10000: 49.523秒 2回目以降 (SQL_NO_CACHE 無しの場合) LIMIT 10: 0.007秒 LIMIT 100: 0.029秒 LIMIT 1000: 0.203秒 LIMIT 10000: 1.467秒 2回目以降 (SQL_NO_CACHE 指定の場合) LIMIT 10: 0.007秒 LIMIT 100: 0.029秒 LIMIT 1000: 0.202秒 LIMIT 10000: 1.462秒 SQL_NO_CACHE 指定の有無は優位な差を生まなかった。 搭載メモリ 2GB だったのを 512MB に減らした状態でも測定してみた。 SEN と SEN.l の合計が 800MB 強なので、明らかに物理メモリよりインデックスの方が大きい状態。 1回目 LIMIT 10: 0.634秒 LIMIT 100: 1.104秒 LIMIT 1000: 5.787秒 LIMIT 10000: 50.292秒 2回目以降 (SQL_NO_CACHE 無しの場合) LIMIT 10: 0.007秒 LIMIT 100: 0.030秒 LIMIT 1000: 0.207秒 LIMIT 10000: 42.752秒 2回目以降 (SQL_NO_CACHE 指定の場合) LIMIT 10: 0.007秒 LIMIT 100: 0.030秒 LIMIT 1000: 0.208秒 LIMIT 10000: 42.771秒 LIMIT 1000 まではメモリ 2GB の時と同じ状態。 今回も SQL_NO_CACHE 指定の有無は優位な差を生まなかった。 メモリ 512MB 環境下で LIMIT 10000 の時のみ 2回目の数値が極端に悪くなって1回目と大差なくなっているのは、 1回目検索時に読み込まれたデータが多すぎてキャッシュから溢れたためだろう。 実運用では同じ検索語が連続してくることなど希だから このキャッシュミス状態はかなり起きやすくなるはず。 なのでインデックスは全部オンメモリであることが強く望ましいのは間違いない。 が、だからといって >>235 > こいつらがオンメモリにないと単なるシーケンシャルスキャンより遅くなってもおかしくない などというアホなこともない。 きちんと LIMIT 切ってやればメモリに全く載って無い状態ですら1秒で帰ってくる。 (ORDER BY とかつけてると LIMIT 付けててもダメな予感がするがまだ試してない) また、 >>230 > 5Gのコンテンツだと、経験上インデックスサイズがだいたい5Gになるんすよ。 そういうケースもあるのかもしれんが、少なくとも今回試した Wikipeida 全文では コンテンツ 5GB 弱に対してインデックス 1GB 弱になった。 よって 2GB で十分オンメモリになる。 それにしても、今回テストした ATOM で IDE 40GB の HDD で OS 起動直後で 1万件ヒットする単語でも1分越えしなかったわけだが、 >>214 はいったいどういう環境とクエリで検索したんだ? read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる