組み込み型全文検索エンジンSenna
>>37 rm -rfで書き途中のヤツを消してしまった。 今は書き直して、basic APIまでできてる。 大量のデータをDBも使わずにいじるケースが想像しにくいんだけど PHPバインディングってどういう用途で使うの? >>39 んだ。特に今のSennaはストレージを持っていないから、 ドキュメントの更新は古いドキュメントの内容を渡さないといけない。 となると、実用的なアプリを書くとなると、 やはりBDBとかsqliteに別途ドキュメント情報を持っておく必要があると思うんだけどなあ・・・ >>37 というわけで、作り方だけ公開してみた。 地味にAPIを増やしていく予定。 現在PHP+MySQLでシステム運用してるけど、もしも導入が超簡単なら導入したい。 例えばsennaのファイルをどっかに置いて、ちょこっと設定ファイルをいじるだけでOK、とか。 それも現在のシステム構成に影響出さずに導入できるなら・・・ それならお金出してでも導入したい。 3万までなら出す。 パッケージソフトとして3万ならそこそこ高価だろ。 別にたいした規模のソフトじゃないし。 >>42 うひひ。果報は寝て待て。 >>44 オープンソースなので、勝手にrpm作って売ってもOKですよ。 >>45 >オープンソースなので、勝手にrpm作って売ってもOK 訴えられても知らんよ・・・ 訴えられるわけないだろw 元からそういうものなんだから >>47 じゃあ、お前が売れば? オープンソースの定義・概念や意味を本当に理解しているのなら、ね。 >>42 MySQLのリビルドが必要だから超簡単とは言いづらい. dump→リビルド→データ流し込むの作業が簡単かどうか. LudiaはPostgreSQLのリビルドの必要なく組み込めるらしい. >>49 NTTデータ社員乙 >>49 >dump→リビルド→データ流し込むの作業が簡単かどうか どっちって言うと、超難しい&めんどくさい。 dumpと流し込みはいいとして、リビルドってのが激しくイヤだ。 絶対に何かトラブルが発生するのが目に見えている。 >>51 うん、だからもっと簡単に導入できるソリューションが出るまで我慢する! >>39 ドキュメントは MySQL にもってるけど、Senna を MySQL に組み込むのはちょっと嫌というケースかな。 PHP バインディングで MySQL 上の ID とからめてインデックスを作っておいて、検索→ドキュメントは MySQL から引っ張り直す、みたいな。 しかし、PHP の検索部分を mod_php とかで動かすと、インデックスの読み込みで httpd のプロセスが肥大化したりしないのだろうか。 あと、ロードのオーバーヘッドとかも気になる。 そういう点では、PHPバインディングに実用性あるのかは俺も聞きたい。 >>53 なるほどね…疎結合でいいならそういう用途もあるなあ。 プロセス肥大化については、 インデックスファイルはmmapで読み込まれるので まあ大丈夫だとは思います。 ロードのオーバヘッドはある程度はあるかなあ。 mod_phpにもなんらかの形でインスタンスを保持しておく方法があると思うので、 それを利用すればイケるんじゃないかな…(適当) >>54 例えば mod_php を動かしている httpd のプロセスが複数動いているとして、インデックスをロードする領域は共有されてるって事ですか? 世界の権威であるCOMDEXが「21世紀のスタンダード」に認定したソフトウェア、 それがホームページ制作王である。ホームページ制作王に不可能はない! 標準外のイカサマ商品の売買で生計を立てるインチキ企業工作員が、 本当は血縁でもセレブでもなんでもない「叶姉妹」や、データを捏造した社員は 月曜朝に株で大儲けしている「あるある大辞典」にコロっと騙される日本人の気質を科学的に分析し、 ホームページ制作王を使ったことのない者や、使いこなせなかった者を煽動し、 彼らに八つ当たりのデタラメな風評をデッチ上げさせたために、我が国はホームページ制作王の 標準化に失敗し、21世紀も7年目に入った今、我が国のオーソリューションは世界に大きく遅れを取っている。 世界標準・ホームページ制作王の普及を妨げる、あらゆる工作活動を糾弾せねばならない。 制作王の普及によって、標準未満のオーサリングツールしか作れない連中を淘汰しなければならない。 そして、我が国は、1日も早くホームページ制作王の標準化を達成し、世界に追いつかねばならない。 世界が認めたホームページ制作王 http://pc11.2ch.net/test/read.cgi/hp/1144987720/ http://qwik.jp/senna/IndexFile.html ≫インデックスのサイズ ≫n-gramインデックスなら文書の賞味サイズの2.5倍程度になります。 とあるんですが、2GBのテーブルなら約5GBのファイルが出来るってこと なのでしょうか? 新しいサブプロジェクトできたみたい http://qwik.jp/tritonn/ OSC2007のSennaのプレゼン見てきたけど、かなりおもしろかった。 その日のセッションの中で一番よかったかも。 pearのインストールと同じくらい簡単になってくれないと、導入する気が起きない。 >>61 2GBの文書だったら、3GBくらいになると思う。経験的に… >>62 もれもOSC2007見てきたけど、なかなか良かった。 今後tritonnのドキュメントが充実していけば嬉しいな。 でも、確かにMeCabとSenna入れて、それからMySQLにパッチあてて コンパイルしないといけないってのはメンドイな。。。。 シェルから「senna install」だけで使えるようになってくれるなら、鯖1台につき1万ずつ払う。 そのsenna コマンドはどうやってインストールするんだ。 $ sudo apt-get install senna か $ cd /usr/ports/database/senna && sudo make install とかじゃだめなんか >>68 「たとえば」の話にマジレスするなよ。 要するに簡単にインストールできないかな、ってだけだ。 >>71 7秒平均かかってたクエリーが.5秒以下になった Webベースのアプリなんでこれで十分す >>72 mysqlのコマンドってmsecレベルの計測出来るの? どれぐらいのデータ量で7秒が.5秒になったのか教えてくれると 俺はきっとハッピーな気分になれるんだ like検索してたのをsennaに置き換えたらそうなるよね 10万件くらいあればlike検索で7秒くらいかかるんじゃない? 全然具体的じゃなかったですね、、 150万件でテーブル[int(10),text]サイズが1.5Gくらいです 検索は75の書いておられる通りで、 MATCH(title) AGAINST('+Sagasu -Iranai' IN BOOLEAN MODE) みたいなのをlikeでやってました “これで十分す”と書いておきながら構築中に気になった (スレ違いな)質問いいでしょか? http://qwik.jp/senna/mysql_configure.html CPU: Intel(R) Pentium(R) D CPU 3.20GHz stepping 04 なのですが、configure時の-mtuneってどれがよかったんでしょ? あと、MySQL+PHPではsmp対応カーネルを使わないほうがいい とググって得た情報なのですがこれは正しいですか? というような質問をしているものですのであまり参考にならないとは 思いますが。。 そういえばsennaがINDEXはったテーブルってdrop出来ない、、 ググると結構前に「直したよ」っていうのが見つかったんだけど あ、tritonn-1.0.0.mysql-5.0.37.senna-1.0.2でインストールしました (ブラジルの中の人ってここ見てるんでしょか?) 逆に言えば、そんなにレコードが莫大でないケース(たとえば社内イントラブログとか)なら、 無理にsenna導入しなくてもLIKE検索で十分ってことだな。。。 >>67 マジ!? 作業しにいきますよ… 手で入れるけどさ。 >>68 Senna本体のインストールは難しくないんだけどね… MySQL + SennaをDebianやFreeBSDの公式パッケージにしたいです。 パッケージ化の実作業はともかく、 メンテナとしてパッケージを投稿するための How Toを勉強する時間が足りないです。 >>72 うひひ。大規模サイトだと、それ結構効いてくるんすよ、 とマジレス。 >>76 SMPじゃないほうがいいのは、 多分InnoDBのことじゃないかしら。詳しくないけど。 OpteronとかNoconaとかガンガン指定して PHPフロントのシステムを動かしているけど、問題ないよ。 >>77 直ってるとは思うけど、 MyISAMのテーブルのドロップなら、 最悪ファイルをすべてrmすればOK。 tritonn-1.0.0はdrop indexで 一時インデックスが残るバグがあるけれど、 これも一時インデックス(#で始まるファイル名を持つ) をrmすればOK。1.0.1を急いで入れる必要なし。 >>78 そのとおり。 将来的に困ったら導入を検討してくだせぇ… (媚びた目をして) >>79-80 aptで入るとうれしいですね あといろいろ教えていただいてありがとうございます 一時インデックスはちょっと気になっていました 1.0.1でてたんですね >>78 速度面以外でもFULLTEXT INDEXになってクエリーがシンプルになったり MeCABの恩恵かと思いますが、カタカナや英数記号など 半角全角・大文字小文字を意識せずに検索出来るので その辺の処理を省けたりで文書量が少ないものでも 利用方法によってはメリットがあるような気がします SennaインストールのためMySQLにパッチ当てる ↓ MySQLバージョンアップ ↓ MySQLにパッチ ↓ MySQLバージョンアップ ↓ MySQLにパッチ ↓ MySQLバージョンアップ ↓ MySQLにパッチ MATCH (title,body) でエラーしたり全レコードHITしたり >>81 あいあいー。aptで入るように頑張りたい。 正規化は自前でやっているので、MeCabなしでも恩恵を受けられます。 >>82 CentOS 4.4でx86_64でよければ作るよ! RedHat系でi386環境がなくて… >>83 マンドクセーよね。 やはり公式パッケージ化を… ちなみに、Sennaの通常のバージョンアップがあっても MySQLの再コンパイルは必要ねっす。 でも、Tritonnのバージョンアップがあったら 再コンパイルが必要っす。 MySQL 5.1以降のplugin storageでなんとかなるか、とも思ったんだけど、 やはり高速にするには本体に手を入れないといけないのでアウト。 Ludiaは本体にパッチ入れなくていいけど、 それでもPg 8.1からPg 8.2のバージョンアップで動かなくなったしなあ… ま、Pg 8.1->8.2は中身変わりすぎなんだけど。 >>84 文字コード間違えてるとそんな挙動もあるかも。 >>86 Fedora用のパッケージ作って売ったら儲かると思うよ。 RHEL 用ならともかく Fedora 用じゃ儲からないだろ Senna, Tritonn, Ludia の Portfile (MacPorts) 書いたよ。 ttp://lapangan.net/darwinports/index.php?cmd=read&page=PrivatePortfile%2FSenna MeCab のデフォルト辞書を UTF-8 で作成する代わりに lex.c に手を入れて mecab_new() の引数で UTF-8 の辞書を指定するようにしています。 >>90 GJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ!!!! なんで、Sennaって、MySQLやPostgreSQLの 全文検索機能に公式に採用されないの? 一体なにがじゃましているの? 理解できない。 なんで、一介の日本語検索エンジンがMySQLやPostgreSQLの 全文検索機能に公式に採用されると考えるのか理解できない。 必要な人が組み込めばいいだけ。 英語圏の人がMeCabとSenna入れるなんて考えられんだろ。 Sennaはちょっと前にメジャーバージョンが出たばかりだし、 APIも結構変わってて安定しているとは言いがたい。 実際使ってるが動作はそこそこ安定してるけどね。 例 phpには日本語サポートが含まれている。 今の時代に、日本語サポートが含まれるはずが無いなんて どういう頭をしているんだ? ばかじゃねーの・・・・ PHPと同じようにMySQLは日本語サポートしてるよ。 でPHPと同じようにSennaバインディングは組み込まれてないよ。 どういう頭をしているんだ? > PHPと同じようにMySQLは日本語サポートしてるよ。 そうだな。 だから、 > なんで、一介の日本語検索エンジンが とか > 英語圏の人がMeCabとSenna入れるなんて考えられんだろ。 とか、 そういう考えがおかしいと言うことだな。 同じ理屈で、phpも公式に採用しない理由は無いということだな。 まあ、全文検索という機能はデータベースの方が重要だから、 phpよりも先にMySQLやPostgreSQLに採用されるべきだな。 ふーん。 「日本語で高度な全文検索をしたい」という99%以上のユーザに関係ない機能のために 配布パッケージに日本語形態素解析エンジンや日本語の辞書や日本語の検索エンジンライブラリを 含めることなんてありえない話だと思うがな。 あっという間にパッケージの容量とコンパイル時間が5割り増しだ。 まぁ含めろとまでは言ってなくてデフォルトで --enable-senna --senna-prefix=/usr とかをサポートしろとかいう話なのかも知れんが。 もっとも各言語の検索エンジンがMySQLに実装されてどの言語でも全文検索がデフォルトで できるようになったらすごいことだと思うけど。 MySQLはストレージであって高度な検索エンジンではないのでその方向性は限りなく ありえないものだとは言っておくよ。 必要なユーザが好きな検索エンジンを勝手に組み込めばよい。 別にMeCab使わずに日本語に特化した部分を除いても Sennaは高速全文検索として利用価値が高いと思うけど。 >>98 すでにMySQLやPostgreSQLにスペース区切りという、 特定の言語に依存した全文検索機能がついている以上、 高度な検索エンジンではないとか言っても説得力が無い。 全文検索が必要かどうかの話はとっくに済んでいる。 英単語区切り以外の区切り方という、国際化対応の話なんだよ。 >>100 > すでにMySQLやPostgreSQLにスペース区切りという、 > 特定の言語に依存した全文検索機能がついている以上、 > 高度な検索エンジンではないとか言っても説得力が無い。 どこが?スコア付けもしない全文検索機能が「高度な検索エンジン」か? ちがうだろ。 くすくす・・・くすくす・・・くすくす・・・・・・・・・・・・・・・・・・・・・・・・ぶわーはhっははっは http://dev.mysql.com/doc/refman/4.1/ja/fulltext-search.html MATCH() を WHERE 節で使用すると(上の例を参照)、 返されるレコードは関連性が最も高いレコードから 低いレコードの順に自動でソートされます。 >>101 重み付けはしてるよ。使ったことないけど。まぁ調べなよ。 >>100 実用的な全文検索方法って言うのは言語ごとにちがうのであって、 日本語の場合は形態素解析を用いるのが実際便利なわけだよね。 じゃぁ日本語サポートのためだけにどこかが作った日本語形態素解析器と エンジンを組み込むか?っていうとそれは無理なんじゃない? って言うことを言いたいだけだ。 メジャーバージョンがリリースされたばかりのSennaを公式に組みこまないのは 理解できないとか飛躍しすぎだよ。 各言語対応のN-gramインデックスでの検索機能を組み込んで欲しいというのならまだわかる。 ただその場合Sennaが採用されるかというと安定度や実績の面で明らかに微妙だろ。 > じゃぁ日本語サポートのためだけにどこかが作った日本語形態素解析器と > エンジンを組み込むか?っていうとそれは無理なんじゃない? だからなんでなんだよw >>104 書いてんじゃんよ。>>98 あというならライセンスの問題だってある。MySQLには商用ライセンスがあるでしょ。 個人で作ってるソフトウェアじゃあるまいし、そんなにかんたんに取り込めるもんでもないだろうよ。 そのほかのソフトを見てみろ。 99%の人には関係ない日本語を なんらかの形でサポートしているのが多いだろ。 それなのに日本語サポートするわけが無いなんて 理解不能。 そういう暴論はもういいって。 他のソフトと同じくMySQLだって日本語はサポートしてるっていってんじゃん。 日本語形態素解析を用いた全文検索をサポートするかって話だろ。 今のところどのオープンソースのデータベースサーバもしてないよ。 もし取り込むにしたってInnoDBとかFalconとか取り込むにも実際買収したり 取り込むクォリティにするまでにかなり時間がかかってるわけ。 そのぐらい理解してくれよ。 キモヲタ同士のキモキモ議論はその辺で終わりにしろ。 そんなことよりも、俺はとにかく簡単にsennaが使えるようになればそれでいいんだ。 組み込み易くする、ドキュメントとノウハウの充実を図る、 で必要十分じゃまいか。tritonnの中の人も、たぶんそう考えている だろうし。 まわりにsennaは良いよって言ったり、応援したりするだけで、 具体的にはなんの貢献もしていないフリーライダーの漏れが 意見する筋合いじゃないか。。。 うひひ。盛り上がってる。 公式に組み込まれない理由… MySQLはGPL/商用のデュアルライセンスで、 基本的にソースコードの著作権はMySQL ABが全部持っている。 (InnoDBなど例外あり) SennaはLGPLなので取り込めない。 PgはBSDライセンスなので、これも取り込んでもらえないと思う。 とりあえず、mysql-sennaとかpostgresql-sennaみたいなパッケージが DebianやFreeBSDで簡単に入るようになれば問題ないと思ってます。 tritonn-1.0.1.mysql-5.0.37.senna-1.0.3でインストールして使っています sennaというか全文検索エンジンの質問になると思うのですが… title:NGRAM,body:MECABで主に歌手のCD発売やコンサート情報をまとめています 例えばELLEGARDENというバンドがいるのですが、 今までLIKE '%〜%'でやっていた経緯もあり、利用者は "ELLE" などで検索をかけてきます "ELLEGARDEN"だとヒットするのですが、上記のように短縮した場合は ヒットしないようなのですが対処の方法はあるでしょうか? title(NGRAM)の方だけでもなんとかなればと思っています よろしくお願いいたします >>111 手パッチでもよいのなら… tritonn中にsen_index_createという関数が3つある。 この、第3引数、なんとかflagsを渡すところを、 なんとかflags | SEN_INDEX_SPLIT_ALPHA | SEN_INDEX_SPLIT_DIGIT | SEN_INDEX_SPLIT_SYMBOL にしてみ。 すでにパッチを当てたMySQLのソースディレクトリが残っているなら、 その中からgrepしたほうが早い。 その後make && make installして、インデックスを再作成してみて。 N-gramのtitleだけ英単語の部分一致検索が出来るようになる。 sennaで求人情報の検索サイトみたいなものを作成しようかと思っているのですが 求人の検索って基本的にチェック入れたりする方が多いですよね? そういう意味で、求人情報検索にsenna導入ってどうでしょう? >>112 うわっ、ありがとうございます! 自宅に戻りしだいやってみて結果を報告しますっ >>113 全文検索+他条件の検索だったら結構Sennaの得意なところ?だと思います。 全文検索が必要となった段階で導入してもいいと思います。 それまではlike '%xxx%'でしのぐといいと思うよ。 senna を mysql 5.0.37に組み込んでbuildしてみた。 mysqldがぜんぜん起動せず、senna patch 無しの mysqld に戻しても起動しなくなってぶち壊したかと 思ったら、libsenna.so をロードできてなかった。ldconfig したらあっさり動いた。以上今夜のチラ裏。 >>117 あるある。 /etc/ld.so.confをいじるか、 もしくはconfigure時に--prefix=/usrをつけるか。 >>112 すみません 昨日はちょっと遅くなったので今日やってみました >tritonn中にsen_index_createという関数が3つある。 3ファイル(4箇所)でよかったでしょうか SHOW SENNA STATUSで3つともONになりました (MECABの方もONになりましたがよかったのかな?) 結果は英単語の部分一致検索が出来るようになったのですが 時折クエリーに時間がかかる事が発生するようになりました 通常は0.1秒以内なんですが10秒とかかかるときが何度もあります 気になるのはインデックスファイルの更新時間なんですが データのinsert,updateでは更新されていないようです 上の問題とは関係ないかもしれませんが少し気になりました 設定などで見直す所等があったらご教示お願いします >>119 4箇所か… MeCabではそのフラグは無視されるから大丈夫。 うひ!10秒!それは実用にならないなぁ… スラッシングが発生しているかも… インデックスファイル(*.SEN*)の容量リストと メモリ容量、 テーブルスキーマと 投げているクエリを教えてもらえるともっとよく分かるかもしれません。 インデックスファイルはmmapしているので、 同期される時間はOSによると思います。 あと、kernel 2.6.18(Debianのみ)と2.6.19でmmap周りにバグがあるので、 そこらへんのカーネルを使っている人は注意が必要かも。 MySQL のレプリケーション環境での質問です。 Senna はスレーブとマスターの両方の MySQL にパッチ宛が必要ですか? 例えば検索クエリはスレーブの一つにしか投げないとき、マスターは Senna 無しでスレーブに Senna とかでもインデックスは更新されますか? >>121 大丈夫なはず。むしろ、そういう運用こそお勧めかも。 テーブルに付与されるインデックスがズレるので、 そこは気をつけないといけないかな。 あ、なんか軽く回答してもらっちゃてありがとうございます。 インデックスがずれる?てのが分かりませんでしたが、実際に環境作ってやってみます。 公式サイトでダウンロードできるmysql-5.0.24a-senna-0.8.1-win32.zipは バインディング済みってことでいいのでしょうか? >>124 バインディング済みだけど、中身かなり古いよ… Windows版ってそれなりに需要あるのかな…? ちゅっと試したい人にはありだと思うWindows版 素人考えで申し訳ないんだけど、ストレージを持たないことと、更新に古い値が必要なことって直接関係あるの? sen_index_upd()でold_valueを、sen_index_update()でold_valuesを指定せずにすむだけで使い勝手が良くなると思う。 >>128 Sennaのインデックスは転置インデックスという構造で、 単語1: 文書ID1, 文書ID2 単語2: 文書ID1, 文書ID3 という風に、単語ごとにその単語を含む文書IDのリストを持っている。 ある文書IDだけを削除する場合、 元の文書の内容がなくても、 上記のリスト中すべての単語について 指定の文書IDがあるかどうかをチェックして削除できる。 でも激遅い。実用にならない。 以下のようなリストを別途持っておけば、 削除が必要な単語についてのみ削除処理を走らせればよい。 文書ID1: 単語1, 単語2 文書ID2: 単語1 文書ID3: 単語2 このようなリストを削除時に手に入れる方法は ・上記のリストを別途インデックスとして作っておく ・元の文書を保存しておく ・元の文書を削除時に渡す(現在のSenna方式) の3つくらいある。 というわけで間接的だが結構影響あるぞ、ストレージ。 >>129 なるほど。削除を効率良く行うために元の文書が必要なんですね。 Sennaの場合は元の文書は別に保存されているはずで、重複して保存するのは ディスクの無駄であるという思想でストレージを持たない、ということで合ってます? >>130 思想としてはたぶんそうだと思います。 Sennaページの開発ロードマップによると、 http://qwik.jp/senna/Roadmap.html ストレージ機能が付いたバージョンが今月出るみたい。 たぶん、ストレージ機能が付くということは、 古い文書の内容を与えなくてもインデックスの削除や更新が できるようになるんじゃないかな。 MySQLバインディングなんかでは必要のない機能だけど、 単体で利用する場合にはかなり便利になるんじゃない? tritonn てのは mysql 本家がversion 更新したら 即更新パッチ出す。。。までは行かないの? "世界初、オープンソースの高速日本語 全文検索エンジンである「Senna」を 「MySQL Enterprise Server」に組み込んだ バイナリに対し、正式に技術サポートを提供" この「世界初」、どこにかかるのか分からん 書き方が、うざ素敵。 sennaを使っていて、 「ずっと死なないhttpdプロセス」が出来ることはありませんか? ロードアベレージが恐ろしい数になっていたので見ると、 ずっと前に生まれたhttpdプロセスがたくさん居座っていました。 apache本体を落としても、それらのプロセスは何故か生きていて、 ゾンビにはなっていません もっとも何が原因なのかは分かっていません。 普段入れていないものといえばeacceleratorとsennaくらいなので、 そのどちらかが原因じゃないか…と fulltext indexを再構築する際、 *.SEN,*.SEN.i,*.SEN.i.cファイルは 前もって削除しておいた方がいいですか? fulltext indexをdrop→create index あるいはmyisamchkでインデックスの再構築をする時に、 これらのファイルも勝手に削除や更新をやってくれるのでしょうか? read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる