From ym_sabn-mysql ＠ yahoo.co.jp Thu Aug 2 12:03:17 2007 From: ym_sabn-mysql ＠ yahoo.co.jp (ym_sabn-mysql ＠ yahoo.co.jp) Date: Thu, 2 Aug 2007 12:03:17 +0900 (JST) Subject: [Senna-dev 647] Re: =?iso-2022-jp?b?VHJpdG9ubiAxLjAuMyAbJEIlaiVqITwlORsoQg==?= In-Reply-To: Message-ID: <20070802030317.52453.qmail@web2906.mail.tnz.yahoo.co.jp> はじめまして、井上と申します。 よろしくお願いいたします。 tritonn-1.0.3.mysql-5.0.41のインストールについて 1点質問させて下さい。 ------ tarボールを展開したら configure --with-senna && make && make install でビルド、インストールが完了します。 ------ とありましたので、その通り試してみましたところ、 configure時に、senna-cfgが見つからない、といった エラーが発生し止まりました。 「ああ、さすがにsenna自体は事前にインストールして おかないといけないんだな」と思いsennaをインストール しようと思ったのですが、ここで、 どのバージョンのsennaを入れればいいんだろう。。 というところで困ってしまいました。 従来のような表記、 tritonn-x.y.z.mysql-x.y.z.senna-x.y.z であれば、どのバージョンのsennaをインストールして おけばいいのか一目瞭然なのですが、tritonn-1.0.3以降 ではどのようにして必要となるsennaのバージョンを確認 すればよろしいでしょうか？ ＃結果的にはsenna-1.0.7で試しましたところ問題なく 　インストールできましたが。 見当違いであったりドキュメントを見落としていたならば 大変失礼なのですがご教授くださいますと助かります。 お手数をおかけしますがよろしくお願いいたします。 --- Kazuki Nakajima wrote: > こんにちは、中嶋＠Tritonnプロジェクトです。 > Tritonn 1.0.3をリリースしました。 > 今回のリリースからMySQLのソースに組み込んだ形での配布に変更しました。 > > インストール手順も簡略化されていますのでTritonnプロジェクトのサイトをご一読いただければ幸いです。 > http://qwik.jp/tritonn/FrontPage.html > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > From ikdttr ＠ gmail.com Thu Aug 2 12:28:07 2007 From: ikdttr ＠ gmail.com (Tetsuro IKEDA) Date: Thu, 2 Aug 2007 12:28:07 +0900 Subject: [Senna-dev 648] Re: =?iso-2022-jp?b?VHJpdG9ubiAxLjAuMyAbJEIlaiVqITwlORsoQg==?= In-Reply-To: <20070802030317.52453.qmail@web2906.mail.tnz.yahoo.co.jp> References: <20070802030317.52453.qmail@web2906.mail.tnz.yahoo.co.jp> Message-ID: こんにちは。池田＠Tritonnです。 記述漏れです、すみません。。 tritonn-1.0.3ではsenna-1.0.5以上が必要となります。 （マルチセクション対応のため） Wikiのニュースに加筆しました。 # マルチセクション対応のバグ調査、ドキュメントのアップデートを # 内部で進めております。ご迷惑をおかけいたしますが、宜しくお願いいたします。 07/08/02 に ym_sabn-mysql ＠ yahoo.co.jp さんは書きました: > はじめまして、井上と申します。 > よろしくお願いいたします。 > > tritonn-1.0.3.mysql-5.0.41のインストールについて > 1点質問させて下さい。 > > ------ > tarボールを展開したら > configure --with-senna && make && make install > でビルド、インストールが完了します。 > ------ > > とありましたので、その通り試してみましたところ、 > configure時に、senna-cfgが見つからない、といった > エラーが発生し止まりました。 > 「ああ、さすがにsenna自体は事前にインストールして > おかないといけないんだな」と思いsennaをインストール > しようと思ったのですが、ここで、 > > どのバージョンのsennaを入れればいいんだろう。。 > > というところで困ってしまいました。 > 従来のような表記、 > > tritonn-x.y.z.mysql-x.y.z.senna-x.y.z > > であれば、どのバージョンのsennaをインストールして > おけばいいのか一目瞭然なのですが、tritonn-1.0.3以降 > ではどのようにして必要となるsennaのバージョンを確認 > すればよろしいでしょうか？ > > ＃結果的にはsenna-1.0.7で試しましたところ問題なく > インストールできましたが。 > > 見当違いであったりドキュメントを見落としていたならば > 大変失礼なのですがご教授くださいますと助かります。 > > お手数をおかけしますがよろしくお願いいたします。 > > > --- Kazuki Nakajima wrote: > > > こんにちは、中嶋＠Tritonnプロジェクトです。 > > Tritonn 1.0.3をリリースしました。 > > 今回のリリースからMySQLのソースに組み込んだ形での配布に変更しました。 > > > > インストール手順も簡略化されていますのでTritonnプロジェクトのサイトをご一読いただければ幸いです。 > > http://qwik.jp/tritonn/FrontPage.html > > _______________________________________________ > > Senna-dev mailing list > > Senna-dev ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > > > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > From a ＠ razil.jp Thu Aug 2 15:50:04 2007 From: a ＠ razil.jp (Tasuku SUENAGA) Date: Thu, 02 Aug 2007 15:50:04 +0900 Subject: [Senna-dev 649] =?iso-2022-jp?b?U2VubmEgMS4wLjgbJEIkciVqJWohPCU5JDckXiQ3JD8bKEI=?= =?iso-2022-jp?b?GyRCISMbKEI=?= Message-ID: <46B17E9C.8050307@razil.jp> 末永です。 Senna 1.0.8をリリースしました。 http://sourceforge.jp/projects/senna/files/ APIの互換性は（ほぼ）保たれていますので、 Tritonn/Ludiaとも Sennaだけを入れ替えてバージョンアップ可能です。 しかし、現行のTritonn/Ludiaユーザの方は バージョンアップの必要はありません。 内部実装の都合上、 sen_query_openのmax_exprsの意味などが 変わってしまっています… が、Tritonn/Ludia上から利用する場合には 1.0.7と同様に利用できると考えます。 1.0系バージョンのSennaは、 1.0.8にて本当に最終リリースとなる予定です。 ●変更点 * APIの追加 sen_query_scan関数を追加しました。 --- Tasuku SUENAGA From kousakadi ＠ nttdata.co.jp Thu Aug 2 16:54:50 2007 From: kousakadi ＠ nttdata.co.jp (kousakadi ＠ nttdata.co.jp) Date: Thu, 2 Aug 2007 16:54:50 +0900 Subject: [Senna-dev 650] Re: =?iso-2022-jp?b?U2VubmEgMS4wLjgbJEIkciVqJWohPCU5JDckXiQ3GyhC?= =?iso-2022-jp?b?GyRCJD8hIxsoQg==?= In-Reply-To: <46B17E9C.8050307@razil.jp> References: <46B17E9C.8050307@razil.jp> Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71B7D@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 libsenna.def に、 sen_query_scan @?? がないように見受けられます。 次のバージョンアップの時で良いので、 追加していただけないでしょうか。 よろしくお願いします。 > -----Original Message----- > From: senna-dev-bounces ＠ lists.sourceforge.jp > [mailto:senna-dev-bounces ＠ lists.sourceforge.jp] On Behalf Of > Tasuku SUENAGA > Sent: Thursday, August 02, 2007 3:50 PM > To: senna-dev ＠ lists.sourceforge.jp > Subject: [Senna-dev 649]Senna 1.0.8をリリースしました。 > > 末永です。 > > Senna 1.0.8をリリースしました。 > http://sourceforge.jp/projects/senna/files/ > > APIの互換性は（ほぼ）保たれていますので、 > Tritonn/Ludiaとも > Sennaだけを入れ替えてバージョンアップ可能です。 > > しかし、現行のTritonn/Ludiaユーザの方は > バージョンアップの必要はありません。 > > 内部実装の都合上、 > sen_query_openのmax_exprsの意味などが > 変わってしまっています… > が、Tritonn/Ludia上から利用する場合には > 1.0.7と同様に利用できると考えます。 > > 1.0系バージョンのSennaは、 > 1.0.8にて本当に最終リリースとなる予定です。 > > ●変更点 > * APIの追加 > sen_query_scan関数を追加しました。 > > --- > Tasuku SUENAGA > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > From a ＠ razil.jp Thu Aug 2 17:55:03 2007 From: a ＠ razil.jp (Tasuku SUENAGA) Date: Thu, 02 Aug 2007 17:55:03 +0900 Subject: [Senna-dev 651] Re: =?iso-2022-jp?b?U2VubmEgMS4wLjgbJEIkciVqJWohPCU5JDckXiQ3GyhC?= =?iso-2022-jp?b?GyRCJD8hIxsoQg==?= In-Reply-To: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71B7D@MAILSV11.msg.nttdata.co.jp> References: <46B17E9C.8050307@razil.jp> <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71B7D@MAILSV11.msg.nttdata.co.jp> Message-ID: <46B19BE7.1000309@razil.jp> 末永です。 おおお！！！ご指摘ありがとうございます… リリースファイルを差し替えました。 エクスポートの指定方法は、 __declspec(dllexport)に変えたほうがいいかもしれないですね… kousakadi ＠ nttdata.co.jp さんは書きました: > 幸坂です。こんにちは。 > > libsenna.def に、 > sen_query_scan @?? > がないように見受けられます。 > > 次のバージョンアップの時で良いので、 > 追加していただけないでしょうか。 > > よろしくお願いします。 --- Tasuku SUENAGA From kousakadi ＠ nttdata.co.jp Fri Aug 3 13:11:54 2007 From: kousakadi ＠ nttdata.co.jp (kousakadi ＠ nttdata.co.jp) Date: Fri, 3 Aug 2007 13:11:54 +0900 Subject: [Senna-dev 652] Re: =?iso-2022-jp?b?U2VubmEgMS4wLjgbJEIkciVqJWohPCU5JDckXiQ3GyhC?= =?iso-2022-jp?b?GyRCJD8hIxsoQg==?= In-Reply-To: <46B19BE7.1000309@razil.jp> References: <46B17E9C.8050307@razil.jp><178CD7FD87EF4B4BB23F3D0B6C201D3F02B71B7D@MAILSV11.msg.nttdata.co.jp> <46B19BE7.1000309@razil.jp> Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71B83@MAILSV11.msg.nttdata.co.jp> 幸坂です。 > __declspec(dllexport)に変えたほうがいいかもしれないですね… そうですね・・・。 現在、scan_queryを使っています。 しかし、query.cの642行目の q->opt.mode = ope->u.op.mode == -1 ? q->default_mode : ope->u.op.mode; で落ちます（涙） opeがNULLのようです。 631行目は cell *e, *ope = NULL; でなく、 cell *e, *ope = NIL; ではないでしょうか？ > -----Original Message----- > From: senna-dev-bounces ＠ lists.sourceforge.jp > [mailto:senna-dev-bounces ＠ lists.sourceforge.jp] On Behalf Of > Tasuku SUENAGA > Sent: Thursday, August 02, 2007 5:55 PM > To: sennaの開発に関する日本語での議論 > Subject: [Senna-dev 651] Re: Senna 1.0.8をリリースしました。 > > 末永です。 > > おおお！！！ご指摘ありがとうございます… > リリースファイルを差し替えました。 > > エクスポートの指定方法は、 > __declspec(dllexport)に変えたほうがいいかもしれないですね… > > kousakadi ＠ nttdata.co.jp さんは書きました: > > 幸坂です。こんにちは。 > > > > libsenna.def に、 > > sen_query_scan @?? > > がないように見受けられます。 > > > > 次のバージョンアップの時で良いので、 > > 追加していただけないでしょうか。 > > > > よろしくお願いします。 > > --- > Tasuku SUENAGA > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > From a ＠ razil.jp Sat Aug 4 01:42:52 2007 From: a ＠ razil.jp (Tasuku SUENAGA) Date: Sat, 04 Aug 2007 01:42:52 +0900 Subject: [Senna-dev 653] Re: =?iso-2022-jp?b?U2VubmEgMS4wLjgbJEIkciVqJWohPCU5JDckXiQ3GyhC?= =?iso-2022-jp?b?GyRCJD8hIxsoQg==?= In-Reply-To: <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71B83@MAILSV11.msg.nttdata.co.jp> References: <46B17E9C.8050307@razil.jp><178CD7FD87EF4B4BB23F3D0B6C201D3F02B71B7D@MAILSV11.msg.nttdata.co.jp> <46B19BE7.1000309@razil.jp> <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71B83@MAILSV11.msg.nttdata.co.jp> Message-ID: <46B35B0C.3030500@razil.jp> 末永です。 おおお…sen_query_scanのためにリリースを行ったのに… 実装上の大きな変更について、 影響するポイントを修正し忘れておりました。 Subversion上で修正いたしました。 手元でテストを行ったところ動作しております。 Ruby bindingsでのテストを書いた上で 再度リリースを考えております。 1.0.8を差し替えリリースするか、1.0.9を出すかは考え中です… kousakadi ＠ nttdata.co.jp さんは書きました: > 幸坂です。 > >> __declspec(dllexport)に変えたほうがいいかもしれないですね… > そうですね・・・。 > 現在、scan_queryを使っています。 > しかし、query.cの642行目の > q->opt.mode = ope->u.op.mode == -1 ? q->default_mode : > ope->u.op.mode; > で落ちます（涙） > opeがNULLのようです。 > > 631行目は > cell *e, *ope = NULL; > でなく、 > cell *e, *ope = NIL; > ではないでしょうか？ > > >> -----Original Message----- >> From: senna-dev-bounces ＠ lists.sourceforge.jp >> [mailto:senna-dev-bounces ＠ lists.sourceforge.jp] On Behalf Of >> Tasuku SUENAGA >> Sent: Thursday, August 02, 2007 5:55 PM >> To: sennaの開発に関する日本語での議論 >> Subject: [Senna-dev 651] Re: Senna 1.0.8をリリースしました。 >> >> 末永です。 >> >> おおお！！！ご指摘ありがとうございます… >> リリースファイルを差し替えました。 >> >> エクスポートの指定方法は、 >> __declspec(dllexport)に変えたほうがいいかもしれないですね… >> >> kousakadi ＠ nttdata.co.jp さんは書きました: >>> 幸坂です。こんにちは。 >>> >>> libsenna.def に、 >>> sen_query_scan @?? >>> がないように見受けられます。 >>> >>> 次のバージョンアップの時で良いので、 >>> 追加していただけないでしょうか。 >>> >>> よろしくお願いします。 >> --- >> Tasuku SUENAGA >> >> _______________________________________________ >> Senna-dev mailing list >> Senna-dev ＠ lists.sourceforge.jp >> http://lists.sourceforge.jp/mailman/listinfo/senna-dev >> > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev --- Tasuku SUENAGA From a ＠ razil.jp Mon Aug 6 21:15:54 2007 From: a ＠ razil.jp (Tasuku SUENAGA) Date: Mon, 06 Aug 2007 21:15:54 +0900 Subject: [Senna-dev 654] =?iso-2022-jp?b?U2VubmEgMS4wLjgbJEIkcjo5JDdCWCQoJWolaiE8JTkbKEI=?= =?iso-2022-jp?b?GyRCJDckXiQ3JD8hIxsoQg==?= In-Reply-To: <46B17E9C.8050307@razil.jp> References: <46B17E9C.8050307@razil.jp> Message-ID: <46B710FA.40107@razil.jp> 末永です。 Senna 1.0.8を差し替えリリースしました。 http://sourceforge.jp/projects/senna/files/ 以前のSenna 1.0.8との違いは、 * sen_query_scan関数に存在したバグの修正 の１点のみです。 現在のバージョンのTritonn/Ludiaは このAPIを利用していないため、 再ダウンロードの必要はありません。 --- Tasuku SUENAGA From ishi.yukio ＠ gmail.com Wed Aug 8 17:43:00 2007 From: ishi.yukio ＠ gmail.com (yukio ishi) Date: Wed, 8 Aug 2007 17:43:00 +0900 Subject: [Senna-dev 655] =?iso-2022-jp?b?RE9SGyRCJEc/dEBpQzE4bCRyOCE6dyQ5JGskSDghOncbKEI=?= =?iso-2022-jp?b?GyRCN2syTCQsGyhCMBskQjdvJEskSiRrGyhC?= Message-ID: こんにちは、石野です。お世話になります。 Senna+mysql+tritonnで、medab辞書の単語をDORの後に連結して、DBに蓄積してあったデータを検索しているのですが、 mysql> SELECT count(*) FROM table_name WHERE MATCH(column_name) AGAINST('*DOR 単語1 単語2 単語3 ... 略 ' in boolean mode); この連結する単語数を多くしていくと、単語1などがテーブルに存在していても検索結果が0件になってしまいます。 mecab辞書で試した場合は、 1000単語のOR：12件ヒット 5000単語のOR：0件 10000単語のOR：0件 という結果でした。 文字列長に制限があるのかと思い、以下のように試してみたところ mysql> SELECT count(*) FROM table_name WHERE MATCH(column_name) AGAINST('*DOR 単語1 単語2 ランダム値 ランダム値 ... 略 ' in boolean mode); こちらは10000単語(文字列長は先ほどより長め）でも正常にヒットしました。 ご存知の方いらっしゃいましたらご教授願えませんでしょうか。どうぞよろしくお願い致します。 ■動作環境 Linux kernel 2.4.20 mysql-4.1.22 senna-1.0.4 tritonn-1.0.2.mysql-4.1.22.senna-1.0.4 テーブルはNGRAMで作成 -- ishi.yukio [at] gmail.com From a ＠ razil.jp Fri Aug 10 12:40:59 2007 From: a ＠ razil.jp (Tasuku SUENAGA) Date: Fri, 10 Aug 2007 12:40:59 +0900 Subject: [Senna-dev 656] Re: =?iso-2022-jp?b?RE9SGyRCJEc/dEBpQzE4bCRyOCE6dyQ5JGskSDghGyhC?= =?iso-2022-jp?b?GyRCOnc3azJMJCwbKEIwGyRCN28kSyRKJGsbKEI=?= In-Reply-To: References: Message-ID: <46BBDE4B.8060203@razil.jp> 末永です。 こんにちは。 Sennaのログはどのように出力されていますでしょうか。 おそらくメモリ不足だと思われます… ランダム値の場合にはマッチする結果が存在しないため、 結果が増えずメモリが不足しないものと予想します。 yukio ishi さんは書きました: > こんにちは、石野です。お世話になります。 > > Senna+mysql+tritonnで、medab辞書の単語をDORの後に連結して、DBに蓄積してあったデータを検索しているのですが、 > > mysql> SELECT count(*) FROM table_name WHERE MATCH(column_name) > AGAINST('*DOR 単語1 単語2 単語3 ... 略 ' in boolean mode); > > この連結する単語数を多くしていくと、単語1などがテーブルに存在していても検索結果が0件になってしまいます。 > mecab辞書で試した場合は、 > 1000単語のOR：12件ヒット > 5000単語のOR：0件 > 10000単語のOR：0件 > > という結果でした。 > 文字列長に制限があるのかと思い、以下のように試してみたところ > > mysql> SELECT count(*) FROM table_name WHERE MATCH(column_name) > AGAINST('*DOR 単語1 単語2 ランダム値 ランダム値 ... 略 ' in boolean mode); > > こちらは10000単語(文字列長は先ほどより長め）でも正常にヒットしました。 > > ご存知の方いらっしゃいましたらご教授願えませんでしょうか。どうぞよろしくお願い致します。 > > ■動作環境 > Linux kernel 2.4.20 > mysql-4.1.22 > senna-1.0.4 > tritonn-1.0.2.mysql-4.1.22.senna-1.0.4 > テーブルはNGRAMで作成 > > -- > ishi.yukio [at] gmail.com --- Tasuku SUENAGA From ishi.yukio ＠ gmail.com Mon Aug 13 12:11:35 2007 From: ishi.yukio ＠ gmail.com (yukio ishi) Date: Mon, 13 Aug 2007 12:11:35 +0900 Subject: [Senna-dev 657] Re: =?iso-2022-jp?b?RE9SGyRCJEc/dEBpQzE4bCRyOCE6dyQ5JGskSDghGyhC?= =?iso-2022-jp?b?GyRCOnc3azJMJCwbKEIwGyRCN28kSyRKJGsbKEI=?= In-Reply-To: <46BBDE4B.8060203@razil.jp> References: <46BBDE4B.8060203@razil.jp> Message-ID: こんにちは、石野です。 senna.log には以下のように出力されました。 メモリ不足だとすると、1件のマッチにつきどの程度のメモリを使用するのでしょうか？ ちなみにメモリ1GBのPCを使用して試しているのですが、その場合は何件程度のマッチまで 耐えられるか把握できると助かります。 ・1000単語のOR（12件ヒット） 08/13:10:41:44.162061|i| ft_init_boolean_search => sen_query_open: str='*DOR 草水 草摺 草瀬 草生 草生さ 草生し 草生しゃ ... 略 08/13:10:41:44.162285|d| ft_init_boolean_search => sen_query_rest: q=0x8a24e28, rest=0x41fe4f8c 08/13:10:41:44.162298|w| ft_init_boolean_search: too long query. rest(草津川 草津線 草津総合病院 草津電機 草津東 草津峠 ... 略 8/13:10:41:44.162396|d| ft_init_boolean_search => sen_records_open 08/13:10:41:44.162410|i| ft_init_boolean_search => sen_query_exec: i=0x89db780, q=0x8a24e28, r=0x8a175d8 08/13:10:41:44.162423|d| mode=0 option=0 w=5 o=0 08/13:10:41:44.162526|i| n=1 (草水) 08/13:10:41:44.162573|d| mode=0 option=0 w=5 o=0 08/13:10:41:44.162606|i| n=1 (草摺) 08/13:10:41:44.162863|d| mode=0 option=0 w=5 o=0 08/13:10:41:44.162881|d| mode=0 option=0 w=5 o=0 08/13:10:41:44.162897|d| mode=0 option=0 w=5 o=0 ... 略 08/13:10:41:44.163284|i| n=1 (草地) 08/13:10:41:44.163296|d| mode=0 option=0 w=5 o=0 08/13:10:41:44.163313|i| n=1 (草地) 08/13:10:41:44.163325|d| mode=0 option=0 w=5 o=0 08/13:10:41:44.163341|d| mode=0 option=0 w=5 o=0 08/13:10:41:44.163372|i| n=1 (草津) 08/13:10:41:44.163386|d| mode=0 option=0 w=5 o=0 08/13:10:41:44.163403|i| n=1 (草津) 08/13:10:41:44.163416|d| mode=0 option=0 w=5 o=0 08/13:10:41:44.163456|i| n=2 (草津港) 08/13:10:41:44.163470|d| mode=0 option=0 w=5 o=0 08/13:10:41:44.163500|i| hits(exact)=12 ・5000単語のOR（0件ヒット） 08/13:10:43:26.161732|i| ft_init_nlq_search => sen_index_sel index=0x89db780, string='*DOR 草水 草摺 草瀬 草生 草生さ ... 略 08/13:10:43:26.162447|i| sen_index_sel > (*DOR 草水 草摺 草瀬 草生 草生さ 草生し 草生しゃ 草生す 草生せ 草生せ 草生そ ... 略 08/13:10:43:26.163559|i| exact: 0 08/13:10:43:26.163964|i| unsplit: 0 08/13:10:43:26.164383|i| partial: 0 08/13:10:43:26.164396|i| hits=0 ・10000単語のOR（0件ヒット） 08/13:11:12:25.898474|i| ft_init_nlq_search => sen_index_sel index=0x89db780, string='*DOR 草水 草摺 草瀬 草生 草生さ ... 略 08/13:11:12:25.899846|i| sen_index_sel > (*DOR 草水 草摺 草瀬 草生 草生さ 草生し 草生しゃ 草生す 草生せ 草生せ 草生そ ... 略 08/13:11:12:25.901942|i| exact: 0 08/13:11:12:25.902747|i| unsplit: 0 08/13:11:12:25.903599|i| partial: 0 08/13:11:12:25.903614|i| hits=0 07/08/10 に Tasuku SUENAGA さんは書きました: > > 末永です。 > こんにちは。 > > Sennaのログはどのように出力されていますでしょうか。 > > おそらくメモリ不足だと思われます… > ランダム値の場合にはマッチする結果が存在しないため、 > 結果が増えずメモリが不足しないものと予想します。 > > yukio ishi さんは書きました: > > こんにちは、石野です。お世話になります。 > > > > Senna+mysql+tritonnで、medab辞書の単語をDORの後に連結して、DBに蓄積してあったデータを検索しているのですが、 > > > > mysql> SELECT count(*) FROM table_name WHERE MATCH(column_name) > > AGAINST('*DOR 単語1 単語2 単語3 ... 略 ' in boolean mode); > > > > この連結する単語数を多くしていくと、単語1などがテーブルに存在していても検索結果が0件になってしまいます。 > > mecab辞書で試した場合は、 > > 1000単語のOR：12件ヒット > > 5000単語のOR：0件 > > 10000単語のOR：0件 > > > > という結果でした。 > > 文字列長に制限があるのかと思い、以下のように試してみたところ > > > > mysql> SELECT count(*) FROM table_name WHERE MATCH(column_name) > > AGAINST('*DOR 単語1 単語2 ランダム値 ランダム値 ... 略 ' in boolean mode); > > > > こちらは10000単語(文字列長は先ほどより長め）でも正常にヒットしました。 > > > > ご存知の方いらっしゃいましたらご教授願えませんでしょうか。どうぞよろしくお願い致します。 > > > > ■動作環境 > > Linux kernel 2.4.20 > > mysql-4.1.22 > > senna-1.0.4 > > tritonn-1.0.2.mysql-4.1.22.senna-1.0.4 > > テーブルはNGRAMで作成 > > > > -- > > ishi.yukio [at] gmail.com > --- > Tasuku SUENAGA > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > From morita ＠ razil.jp Mon Aug 13 13:16:33 2007 From: morita ＠ razil.jp (morita ＠ razil.jp) Date: Mon, 13 Aug 2007 13:16:33 +0900 Subject: [Senna-dev 658] Re: =?iso-2022-jp?b?RE9SGyRCJEc/dEBpQzE4bCRyOCE6dyQ5JGskSDghGyhC?= =?iso-2022-jp?b?GyRCOnc3azJMJCwbKEIwGyRCN28kSyRKJGsbKEI=?= In-Reply-To: References: <46BBDE4B.8060203@razil.jp> Message-ID: <20070813041633.GA19198@epepe.com> こんにちは、森です。 Sennaではヒットしたレコードの情報を内部のハッシュテーブルに一旦全て登録します。 その時に消費するメモリは、32bit環境なら検索結果1件につきおよそ48byte程度になると 思います。100万件がヒットすると48MByte消費するぐらいの計算です。 そのほかに、検索語に対応する転置インデックスの領域を一時的にメモリにマッピングします。 この量はインデックスに登録されている文書件数や指定した検索語の数に応じて増加します。 今回のケースでは、ft_init_boolean_searchの中で "too long query"という警告が出ているので、 こちらがネックになっているようです。 tritonnの、myisam/ft_boolean_search.cの25行目で #define SENNA_MAX_N_EXPR 32 と定義されていますので、この数をもっと大きくすれば、 現在よりも多くの単語で検索することができる可能性があります。 >>> yukio ishi さんは書きました： > こんにちは、石野です。 > > senna.log には以下のように出力されました。 > メモリ不足だとすると、1件のマッチにつきどの程度のメモリを使用するのでしょうか？ > ちなみにメモリ1GBのPCを使用して試しているのですが、その場合は何件程度のマッチまで > 耐えられるか把握できると助かります。 > > ・1000単語のOR（12件ヒット） > > 08/13:10:41:44.162061|i| ft_init_boolean_search => sen_query_open: str='*DOR > 草水 草摺 草瀬 草生 草生さ 草生し 草生しゃ ... 略 > 08/13:10:41:44.162285|d| ft_init_boolean_search => sen_query_rest: > q=0x8a24e28, rest=0x41fe4f8c > 08/13:10:41:44.162298|w| ft_init_boolean_search: too long query. rest(草津川 > 草津線 草津総合病院 草津電機 草津東 草津峠 ... 略 > 8/13:10:41:44.162396|d| ft_init_boolean_search => sen_records_open > 08/13:10:41:44.162410|i| ft_init_boolean_search => sen_query_exec: > i=0x89db780, q=0x8a24e28, r=0x8a175d8 > 08/13:10:41:44.162423|d| mode=0 option=0 w=5 o=0 > 08/13:10:41:44.162526|i| n=1 (草水) > 08/13:10:41:44.162573|d| mode=0 option=0 w=5 o=0 > 08/13:10:41:44.162606|i| n=1 (草摺) > 08/13:10:41:44.162863|d| mode=0 option=0 w=5 o=0 > 08/13:10:41:44.162881|d| mode=0 option=0 w=5 o=0 > 08/13:10:41:44.162897|d| mode=0 option=0 w=5 o=0 > ... 略 > 08/13:10:41:44.163284|i| n=1 (草地) > 08/13:10:41:44.163296|d| mode=0 option=0 w=5 o=0 > 08/13:10:41:44.163313|i| n=1 (草地) > 08/13:10:41:44.163325|d| mode=0 option=0 w=5 o=0 > 08/13:10:41:44.163341|d| mode=0 option=0 w=5 o=0 > 08/13:10:41:44.163372|i| n=1 (草津) > 08/13:10:41:44.163386|d| mode=0 option=0 w=5 o=0 > 08/13:10:41:44.163403|i| n=1 (草津) > 08/13:10:41:44.163416|d| mode=0 option=0 w=5 o=0 > 08/13:10:41:44.163456|i| n=2 (草津港) > 08/13:10:41:44.163470|d| mode=0 option=0 w=5 o=0 > 08/13:10:41:44.163500|i| hits(exact)=12 > > ・5000単語のOR（0件ヒット） > > 08/13:10:43:26.161732|i| ft_init_nlq_search => sen_index_sel > index=0x89db780, string='*DOR 草水 草摺 草瀬 草生 草生さ ... 略 > 08/13:10:43:26.162447|i| sen_index_sel > (*DOR 草水 草摺 草瀬 草生 草生さ 草生し 草生しゃ 草生す > 草生せ 草生せ 草生そ ... 略 > 08/13:10:43:26.163559|i| exact: 0 > 08/13:10:43:26.163964|i| unsplit: 0 > 08/13:10:43:26.164383|i| partial: 0 > 08/13:10:43:26.164396|i| hits=0 > > ・10000単語のOR（0件ヒット） > > 08/13:11:12:25.898474|i| ft_init_nlq_search => sen_index_sel > index=0x89db780, string='*DOR 草水 草摺 草瀬 草生 草生さ ... 略 > 08/13:11:12:25.899846|i| sen_index_sel > (*DOR 草水 草摺 草瀬 草生 草生さ 草生し 草生しゃ 草生す > 草生せ 草生せ 草生そ ... 略 > 08/13:11:12:25.901942|i| exact: 0 > 08/13:11:12:25.902747|i| unsplit: 0 > 08/13:11:12:25.903599|i| partial: 0 > 08/13:11:12:25.903614|i| hits=0 > > > 07/08/10 に Tasuku SUENAGA さんは書きました: > > > > 末永です。 > > こんにちは。 > > > > Sennaのログはどのように出力されていますでしょうか。 > > > > おそらくメモリ不足だと思われます… > > ランダム値の場合にはマッチする結果が存在しないため、 > > 結果が増えずメモリが不足しないものと予想します。 > > > > yukio ishi さんは書きました: > > > こんにちは、石野です。お世話になります。 > > > > > > Senna+mysql+tritonnで、medab辞書の単語をDORの後に連結して、DBに蓄積してあったデータを検索しているのですが、 > > > > > > mysql> SELECT count(*) FROM table_name WHERE MATCH(column_name) > > > AGAINST('*DOR 単語1 単語2 単語3 ... 略 ' in boolean mode); > > > > > > この連結する単語数を多くしていくと、単語1などがテーブルに存在していても検索結果が0件になってしまいます。 > > > mecab辞書で試した場合は、 > > > 1000単語のOR：12件ヒット > > > 5000単語のOR：0件 > > > 10000単語のOR：0件 > > > > > > という結果でした。 > > > 文字列長に制限があるのかと思い、以下のように試してみたところ > > > > > > mysql> SELECT count(*) FROM table_name WHERE MATCH(column_name) > > > AGAINST('*DOR 単語1 単語2 ランダム値 ランダム値 ... 略 ' in boolean mode); > > > > > > こちらは10000単語(文字列長は先ほどより長め）でも正常にヒットしました。 > > > > > > ご存知の方いらっしゃいましたらご教授願えませんでしょうか。どうぞよろしくお願い致します。 > > > > > > ■動作環境 > > > Linux kernel 2.4.20 > > > mysql-4.1.22 > > > senna-1.0.4 > > > tritonn-1.0.2.mysql-4.1.22.senna-1.0.4 > > > テーブルはNGRAMで作成 > > > > > > -- > > > ishi.yukio [at] gmail.com > > --- > > Tasuku SUENAGA > > > > _______________________________________________ > > Senna-dev mailing list > > Senna-dev ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > -- morita From ishi.yukio ＠ gmail.com Tue Aug 14 12:02:45 2007 From: ishi.yukio ＠ gmail.com (yukio ishi) Date: Tue, 14 Aug 2007 12:02:45 +0900 Subject: [Senna-dev 659] Re: =?iso-2022-jp?b?RE9SGyRCJEc/dEBpQzE4bCRyOCE6dyQ5JGskSDghGyhC?= =?iso-2022-jp?b?GyRCOnc3azJMJCwbKEIwGyRCN28kSyRKJGsbKEI=?= In-Reply-To: <20070813041633.GA19198@epepe.com> References: <46BBDE4B.8060203@razil.jp> <20070813041633.GA19198@epepe.com> Message-ID: こんにちは、石野です。 ありがとうございます。非常に参考になります。 ちなみに、試したのは約15万レコードに対しての検索で発生した現象でした。 ORで多くの単語を一度に検索したほうが検索速度をさらに高速にできたので、 そうしたかったのですが、今後レコード数がかなり多くなることも想定しているので、 とりあえず、一単語づつ検索しようかと思います。 SENNA_MAX_N_EXPRの変更も必要になったら試してみたいと思います。 本当にありがとうございました。 07/08/13 に morita ＠ razil.jp さんは書きました: > > こんにちは、森です。 > > Sennaではヒットしたレコードの情報を内部のハッシュテーブルに一旦全て登録します。 > その時に消費するメモリは、32bit環境なら検索結果1件につきおよそ48byte程度になると > 思います。100万件がヒットすると48MByte消費するぐらいの計算です。 > > そのほかに、検索語に対応する転置インデックスの領域を一時的にメモリにマッピングします。 > この量はインデックスに登録されている文書件数や指定した検索語の数に応じて増加します。 > > 今回のケースでは、ft_init_boolean_searchの中で > "too long query"という警告が出ているので、 > こちらがネックになっているようです。 > > tritonnの、myisam/ft_boolean_search.cの25行目で > > #define SENNA_MAX_N_EXPR 32 > > と定義されていますので、この数をもっと大きくすれば、 > 現在よりも多くの単語で検索することができる可能性があります。 > > From poala1116 ＠ yahoo.co.jp Wed Aug 15 10:11:43 2007 From: poala1116 ＠ yahoo.co.jp (=?ISO-2022-JP?B?GyRCOzN5dRsoQiAbJEJNOjJwGyhC?=) Date: Wed, 15 Aug 2007 10:11:43 +0900 (JST) Subject: [Senna-dev 660] Re: =?iso-2022-jp?b?GyRCJSQlcyVHJUMlLyU5JHIlLSVjJUMlNyVlJEsbKEI=?= =?iso-2022-jp?b?GyRCSl07fSQ5JGtKfUshJEskRCQkJEYbKEI=?= In-Reply-To: <46A820C7.7060109@razil.jp> Message-ID: <20070815011143.53515.qmail@web3008.mail.tnz.yahoo.co.jp> $B$*@$OC$K$J$C$F$*$j$^$9!#;3:j$G$9!#(B $BJV;v$,CY$/$J$j?=$7Lu$"$j$^$;$s!#(B $B65$($FD:$$$?%$%s%G%C%/%9$r%-%c%C%7%e$K$N$;$kJ}K!$K$D$$$F(B $B;n$7$?7k2L$rJs9p$7$^$9!#(B >$B%-%c%C%7%e$rBg$-$/$7$?$$>l9g$K$O(B >initial_n_segments$B%Q%i%a!<%?$rBg$-$/$9$k$H$h$$$H;W$$$^$9!#(B /var/senna/senna.conf$B%U%!%$%k$K(BINITIAL_N_SEGMENTS 2048$B$HF~NO$7$F(B $B8!:w$r;n$7$F$_$^$7$?$,!"8!:w$OB.$/$J$j$^$;$s$G$7$?!#(B >MySQL$B$N%G!<%?%G%#%l%/%H%j$+$i%j%s%/$r$O$C$F!"(B >$B%$%s%G%C%/%9%U%!%$%k$r(Btmpfs$B$KCV$/$H$$$&$N$r;W$$$D$$$F$_$^$7$?!D(B $B%$%s%G%C%/%9%U%!%$%k$r(Btmpfs$B$KCV$/$H!"$^$5$K%$%s%G%C%/%9$,%-%c%C%7%e$K(B $BE83+$5$l$F$*$j!"(BMySQL$B%G!<%?%G%#%l%/%H%j$+$i$N%j%s%/$G$b%$%s%G%C%/%9$N(B $B;2>H!&99?7$H$b$KLdBj$J$$$h$&$J$N$G;H$($k$+$H;W$C$?$N$G$9$,!"(B tmpfs$B>e$N%U%!%$%k$O(BOS$B$r%j%V!<%H$9$k$H>C$($F$7$^$&$?$a!"(B OS$B$r%j%V!<%H$7$?8e$K%$%s%G%C%/%9$r:F:n ＠ .$7!"(Btmpfs$B$K:FG[CV$7$J$$$H$$$1$J$/$J$j!"1?MQ9`L\$,A}$($k$N$G:#2s$O;HMQ$7$^$;$s$G$7$?!#(B $B7k6I!":#2s$O%F!<%V%kDj5A$r8+D>$7$F8!:wMQ$H99?7MQ$N%F!<%V%k$r:n ＠ .$9$k$3$H$G!"(B $B8!:wB.EY$r>e$2$k$3$H$,$G$-$^$7$?!#(B $B%F!<%V%kDj5A8+D>$7$KH<$C$F%=!<%9$Kl9g$K$h$C$F$O;H$($=$&$J$N$G!"(B $B wrote: $BKv1J$G$9!#(B senna$B$N%$%s%G%C%/%9$rA4$F%-%c%C%7%e$KE83+$7$FJ];}$9$k5!G=$O$"$j$^$;$s!#(B OS$B$N%-%c%C%7%e$^$+$;$G$9!#(B $B%-%c%C%7%e$rBg$-$/$7$?$$>l9g$K$O(B initial_n_segments$B%Q%i%a!<%?$rBg$-$/$9$k$H$h$$$H;W$$$^$9!#(B $B8!:w;~$K$O(BI/O$B$,6I=j2=$5$l$F$$$k$N$G!"(B $B%$%s%G%C%/%9$N0lIt$,%-%c%C%7%e30$G$b$=$l$[$I8!:w$,CY$/$O$J$i$J$$$H(B $B9M$($^$9!#(B MySQL$B$N%G!<%?%G%#%l%/%H%j$+$i%j%s%/$r$O$C$F!"(B $B%$%s%G%C%/%9%U%!%$%k$r(Btmpfs$B$KCV$/$H$$$&$N$r;W$$$D$$$F$_$^$7$?!D(B $B;3yu(B $BM:2p(B $B$5$s$O=q$-$^$7$?(B: > $B$O$8$a$^$7$F!#;3:j$H?=$7$^$9!#(B > > Linux$B>e$G(Btritonn-1.0.2.mysql-5.0.41.senna-1.0.5$B$r;HMQ$7$F$$$^$9!#(B > > senna$B$N%$%s%G%C%/%9$rA4$F%-%c%C%7%e$KE83+$7$FJ];}$9$k$3$H$K$h$j(B > $B8!:w$N9bB.2=$r?^$j$?$$$N$G$9$,!"$=$N$h$&$J$3$H$O2DG=$G$7$g$&$+!#(B > > senna$B$N%$%s%G%C%/%9$r;HMQ$7$?8!:w$r9T$&$3$H$K$h$j!"(B > $B%-%c%C%7%e$K%$%s%G%C%/%9$,C_ ＠ Q$5$l$F$$$/$b$N$@$H9M$($F$$$?$N$G$9$,!"(B > $B8!:wCf$K%-%c%C%7%e$N;HMQNL$r3NG'$7$F$$$?$H$3$m!"(B > $B8:$C$F$$$k$3$H$,$"$j%-%c%C%7%e$KC_ ＠ Q$5$l$F$$$J$$$3$H$,$o$+$j$^$7$?!#(B > > $B%-%c%C%7%e$N;HMQNL$O(Bfree$B%3%^%s%I$G!|$N2U=j$r3NG'$7$^$7$?!#(B > total used free shared buffers cached > Mem: 2073288 2056760 16528 0 4604 1883516 > -/+ buffers/cache: $B!|(B168640 1904648 > Swap: 2048276 208 2048068 > $B!JC10L!'(BKB$B!K(B > > OS$B$N%a%b%j$O;HMQ2DG=NN0h$,==J,$K$"$k$N$G!"(B > OS$B$K$h$j%a%b%j$,3+J|$5$l$F$$$k$o$1$G$O$J$$$h$&$G$9!#(B > > senna$B$N%$%s%G%C%/%9$rA4$F%-%c%C%7%e$KE83+$7$FJ];}$9$kJ}K!$r65$($F$/$@$5$$!#(B > > $B$h$m$7$/$*4j$$CW$7$^$9!#(B --- Tasuku SUENAGA _______________________________________________ Senna-dev mailing list Senna-dev ＠ lists.sourceforge.jp http://lists.sourceforge.jp/mailman/listinfo/senna-dev --------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar From morita ＠ razil.jp Wed Aug 15 14:48:18 2007 From: morita ＠ razil.jp (morita ＠ razil.jp) Date: Wed, 15 Aug 2007 14:48:18 +0900 Subject: [Senna-dev 661] Re: =?iso-2022-jp?b?GyRCJSQlcyVHJUMlLyU5JHIlLSVjJUMlNyVlJEsbKEI=?= =?iso-2022-jp?b?GyRCSl07fSQ5JGtKfUshJEskRCQkJEYbKEI=?= In-Reply-To: <20070815011143.53515.qmail@web3008.mail.tnz.yahoo.co.jp> References: <46A820C7.7060109@razil.jp> <20070815011143.53515.qmail@web3008.mail.tnz.yahoo.co.jp> Message-ID: <20070815054818.GA9050@epepe.com> お世話になっております。森です。 すみません。INITIAL_N_SEGMENTSは主に更新速度の向上に寄与しますが、 検索速度にはあまり影響しないかもしれません。 ディスクI/Oがネックで検索速度が出ないのは、起動直後が特に顕著で、 必要な領域が適度にOSのキャッシュに載るに従って徐々に検索が高速になります。 起動前にインデックスファイルを以下のようにして読ませてしまうと効果があります。 cat *.SEN* > /dev/null これでインデックスファイルがOSのキャッシュに載るので、 起動直後でも、もたつかないと思います。 もし、インデックスファイルの総サイズがOSのキャッシュサイズよりも大きくなる場合は、 以下の優先順位でメモリに載せるようにしてください。 1. *.SEN.l 2. *.SEN 3. *.SEN.i 4. *.SEN.i.c 大量の文書を登録すると最終的には.i.cファイルが一番大きくなりますが、 これがメモリに載っていなくても、それなりの速度では検索できます。 >>> 山?u 雄介 さんは書きました： > お世話になっております。山崎です。 > 返事が遅くなり申し訳ありません。 > > 教えて頂いたインデックスをキャッシュにのせる方法について > 試した結果を報告します。 > > > >キャッシュを大きくしたい場合には > >initial_n_segmentsパラメータを大きくするとよいと思います。 > > /var/senna/senna.confファイルにINITIAL_N_SEGMENTS 2048と入力して > 検索を試してみましたが、検索は速くなりませんでした。 > > > >MySQLのデータディレクトリからリンクをはって、 > >インデックスファイルをtmpfsに置くというのを思いついてみました… > > インデックスファイルをtmpfsに置くと、まさにインデックスがキャッシュに > 展開されており、MySQLデータディレクトリからのリンクでもインデックスの > 参照・更新ともに問題ないようなので使えるかと思ったのですが、 > tmpfs上のファイルはOSをリブートすると消えてしまうため、 > OSをリブートした後にインデックスを再作成し、tmpfsに再配置しないといけなくなり、運用項目が増えるので今回は使用しませんでした。 > > > 結局、今回はテーブル定義を見直して検索用と更新用のテーブルを作成することで、 > 検索速度を上げることができました。 > テーブル定義見直しに伴ってソースに手を加える前に使用可能なメモリがあったので > メモリを使ってなんとかしたいと思っていたのですが。。 > > tmpfsを使う方法なんて思いつきませんでした。 > tmpfsを使うという方法は場合によっては使えそうなので、 > 次の機会に試してみたいと思います。 > > ご回答ありがとうございました。 > > Tasuku SUENAGA wrote: > 末永です。 > > sennaのインデックスを全てキャッシュに展開して保持する機能はありません。 > OSのキャッシュまかせです。 > > キャッシュを大きくしたい場合には > initial_n_segmentsパラメータを大きくするとよいと思います。 > 検索時にはI/Oが局所化されているので、 > インデックスの一部がキャッシュ外でもそれほど検索が遅くはならないと > 考えます。 > > MySQLのデータディレクトリからリンクをはって、 > インデックスファイルをtmpfsに置くというのを思いついてみました… > > 山?u 雄介 さんは書きました: > > はじめまして。山崎と申します。 > > > > Linux上でtritonn-1.0.2.mysql-5.0.41.senna-1.0.5を使用しています。 > > > > sennaのインデックスを全てキャッシュに展開して保持することにより > > 検索の高速化を図りたいのですが、そのようなことは可能でしょうか。 > > > > sennaのインデックスを使用した検索を行うことにより、 > > キャッシュにインデックスが蓄積されていくものだと考えていたのですが、 > > 検索中にキャッシュの使用量を確認していたところ、 > > 減っていることがありキャッシュに蓄積されていないことがわかりました。 > > > > キャッシュの使用量はfreeコマンドで●の箇所を確認しました。 > > total used free shared buffers cached > > Mem: 2073288 2056760 16528 0 4604 1883516 > > -/+ buffers/cache: ●168640 1904648 > > Swap: 2048276 208 2048068 > > （単位：KB） > > > > OSのメモリは使用可能領域が十分にあるので、 > > OSによりメモリが開放されているわけではないようです。 > > > > sennaのインデックスを全てキャッシュに展開して保持する方法を教えてください。 > > > > よろしくお願い致します。 > --- > Tasuku SUENAGA > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > > > > > --------------------------------- > Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev -- morita From poala1116 ＠ yahoo.co.jp Thu Aug 16 20:42:49 2007 From: poala1116 ＠ yahoo.co.jp (=?ISO-2022-JP?B?GyRCOzM6ahsoQiAbJEJNOjJwGyhC?=) Date: Thu, 16 Aug 2007 20:42:49 +0900 (JST) Subject: [Senna-dev 662] Re: =?iso-2022-jp?b?GyRCJSQlcyVHJUMlLyU5JHIlLSVjJUMlNyVlJEsbKEI=?= =?iso-2022-jp?b?GyRCSl07fSQ5JGtKfUshJEskRCQkJEYbKEI=?= In-Reply-To: <20070815054818.GA9050@epepe.com> Message-ID: <20070816114249.64690.qmail@web3005.mail.tnz.yahoo.co.jp> お世話になっております。山崎です。 cat *.SEN* > /dev/null を実行した後に検索した結果、見事に速くなりました！！ OS起動時と定期ジョブに使いたいと思います。 ありがとうございました。 余談ですが、Windowsバーチャルマシン上のCentOSでは コマンドを入力してもキャッシュに載りませんでした。 バーチャルマシン上ではきかないんでしょうね。 --- morita ＠ razil.jp wrote: > お世話になっております。森です。 > > すみません。INITIAL_N_SEGMENTSは主に更新速度の向上に寄 与しますが、 > 検索速度にはあまり影響しないかもしれません。 > > ディスクI/Oがネックで検索速度が出ないのは、起動直後が 特に顕著で、 > 必要な領域が適度にOSのキャッシュに載るに従って徐々に検 索が高速になります。 > > 起動前にインデックスファイルを以下のようにして読ませて しまうと効果があります。 > > cat *.SEN* > /dev/null > > これでインデックスファイルがOSのキャッシュに載るので、 > 起動直後でも、もたつかないと思います。 > > もし、インデックスファイルの総サイズがOSのキャッシュサ イズよりも大きくなる場合は、 > 以下の優先順位でメモリに載せるようにしてください。 > > 1. *.SEN.l > 2. *.SEN > 3. *.SEN.i > 4. *.SEN.i.c > > 大量の文書を登録すると最終的には.i.cファイルが一番大き くなりますが、 > これがメモリに載っていなくても、それなりの速度では検索 できます。 > -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From ikdttr ＠ gmail.com Sat Aug 25 18:41:25 2007 From: ikdttr ＠ gmail.com (Tetsuro IKEDA) Date: Sat, 25 Aug 2007 18:41:25 +0900 Subject: [Senna-dev 663] =?iso-2022-jp?b?bXlzcWwtNS4wLjQ1LXRyaXRvbm4tMS4wLjQbJEIlaiVqGyhC?= =?iso-2022-jp?b?GyRCITwlORsoQg==?= Message-ID: 皆さんこんにちは。池田@Tritonnプロジェクトです。 Tritonn 1.0.4をリリースしました。MySQL 5.0.45をベースにしています。必要SennaバージョンはSenna 1.0.5以上です。 ダウンロードはこちらから： http://sourceforge.jp/projects/tritonn/files/ 今回のリリースでの変更点は以下です。 * マルチセクション機能のバグ修正 * 対象MySQLのバージョンをMySQL 5.0.45にアップデート tritonn-1.0.3ではマルチセクション機能が正しく機能していませんでした。ご迷惑をお掛けしましたことをお詫び申し上げます。 またTritonn 1.0.4のリリースに伴って、Tritonn公式サイト(http://qwik.jp/tritonn)の各ドキュメントを大幅に更新しています。Tritonnではver1.0.2からver1.0.3に上がる際に、それまでのパッチ配布方式からソース一式配布方式へと変更を行いましたが、ドキュメントの更新が今回のリリースにてやっと完了となりました。こちらもご不便をお掛けしましたことをお詫び申し上げます。 また今回のタイミングで過去のリリースファイルを整理しています。ダウンロードページをご覧いただくとお気づきになると思うのですが、Tritonnパッチとして配布していたリリース物をまとめて並べています。 今後ともTritonnプロジェクトおよびSennaをよろしくお願いいたします。 From ym_sabn-mysql ＠ yahoo.co.jp Thu Aug 30 17:21:03 2007 From: ym_sabn-mysql ＠ yahoo.co.jp (ym_sabn-mysql ＠ yahoo.co.jp) Date: Thu, 30 Aug 2007 17:21:03 +0900 (JST) Subject: [Senna-dev 664] =?iso-2022-jp?b?TkdSQU0gGyRCJEckTjFRP3Q7eiROSXRKLDBsQ1c4ITp3GyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= Message-ID: <20070830082103.30465.qmail@web2908.mail.tnz.yahoo.co.jp> お世話になっております。井上です。 表題の件について質問させてください。 CREATE TABLE t1 (c1 TEXT, FULLTEXT INDEX ft USING NGRAM (c1)) ENGINE = MyISAM DEFAULT CHARSET utf8; INSERT INTO t1 VALUES ("FedoraCore500の技"); という状態で、 SELECT * FROM t1 WHERE MATCH(c1) AGAINST("500"); と検索するとヒットするのですが、 SELECT * FROM t1 WHERE MATCH(c1) AGAINST("00"); や SELECT * FROM t1 WHERE MATCH(c1) AGAINST("Core"); と検索するとヒットしませんでした。 英数字に限り単語単位に分けているのかなと思い、 SELECT * FROM t1 WHERE MATCH(c1) AGAINST("Fedo"); と試してみたのですが、これはヒットします。また、 SELECT * FROM t1 WHERE MATCH(c1) AGAINST("50"); もヒットします。 純粋にNGRAM化されているのであれば「Core」や「00」でも ヒットすると思っていましたので少々意外でした。 また、非正規化（NO NORMALIZE）を付けて試してみたのですが、 その場合には、 SELECT * FROM t1 WHERE MATCH(c1) AGAINST("00"); SELECT * FROM t1 WHERE MATCH(c1) AGAINST("Core"); の両方ともヒットいたします。 私の方での使用用途でのお話で恐縮ですが、「00」や「Core」 もヒットする方がしっくりくるようなサービスの予定ですので、 何かよい手はないかと困っております。 ＃例えば「DiningBar ルイーダの酒場」なんてお店があった場合、 ＃「Bar」で検索してもヒットして欲しい、といったような…。 非正規化のオプションを付けると当然ながら今度は、 SELECT * FROM t1 WHERE MATCH(c1) AGAINST("５００"); と全角で検索するとヒットしなくなりますのでこれも避けたく 思っています。 ＃アプリケーションレイヤーで対応できる内容ではありますが。 と、色々試してみまして、正規化と非正規化でいったいどのような 差が出るのか、また、正規化を生かした状態で、 SELECT * FROM t1 WHERE MATCH(c1) AGAINST("Core"); をヒットさせる方法はないのか、といった点をご教授いただけ ないでしょうか。 バージョンは、下記のとおりです。 senna-1.0.8 mysql-5.0.45-tritonn-1.0.4 以上、お手数をおかけしますが何卒よろしくお願いいたします。 From yu ＠ irx.jp Thu Aug 30 17:30:00 2007 From: yu ＠ irx.jp (Yutaro Shimamura) Date: Thu, 30 Aug 2007 17:30:00 +0900 Subject: [Senna-dev 665] Re: =?iso-2022-jp?b?TkdSQU0gGyRCJEckTjFRP3Q7eiROSXRKLDBsQ1cbKEI=?= =?iso-2022-jp?b?GyRCOCE6dyRLJEQkJCRGGyhC?= In-Reply-To: <20070830082103.30465.qmail@web2908.mail.tnz.yahoo.co.jp> References: <20070830082103.30465.qmail@web2908.mail.tnz.yahoo.co.jp> Message-ID: こんにちは。島村です。 SEN_INDEX_SPLIT_ALPHAやSEN_INDEX_SPLIT_DIGITフラグを インデックス作成時につけることによって、 文字数ごとの分割が可能になります。 今のトリトンでは指定できなかったような気がしますが、 Sennaのソースコードlib/lex.cの 44 lex->uni_alpha = (nstr->ctypes && !(lex->sym->flags & SEN_INDEX_SPLIT_ALPHA)); 45 lex->uni_digit = (nstr->ctypes && !(lex->sym->flags & SEN_INDEX_SPLIT_DIGIT)); 46 lex->uni_symbol = (nstr->ctypes && !(lex->sym->flags & SEN_INDEX_SPLIT_SYMBOL)); 辺りをコメントアウトすると可能です。 (インデックス作成からやり直す必要がありますが) On Aug 30, 2007, at 5:21 PM, wrote: > お世話になっております。井上です。 > 表題の件について質問させてください。 > > CREATE TABLE t1 (c1 TEXT, FULLTEXT INDEX ft USING NGRAM (c1)) > ENGINE = MyISAM DEFAULT CHARSET utf8; > INSERT INTO t1 VALUES ("FedoraCore500の技"); > > という状態で、 > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("500"); > > と検索するとヒットするのですが、 > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("00"); > や > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("Core"); > > と検索するとヒットしませんでした。 > 英数字に限り単語単位に分けているのかなと思い、 > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("Fedo"); > > と試してみたのですが、これはヒットします。また、 > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("50"); > > もヒットします。 > 純粋にNGRAM化されているのであれば「Core」や「00」でも > ヒットすると思っていましたので少々意外でした。 > > また、非正規化（NO NORMALIZE）を付けて試してみたのですが、 > その場合には、 > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("00"); > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("Core"); > > の両方ともヒットいたします。 > 私の方での使用用途でのお話で恐縮ですが、「00」や「Core」 > もヒットする方がしっくりくるようなサービスの予定ですので、 > 何かよい手はないかと困っております。 > > ＃例えば「DiningBar ルイーダの酒場」なんてお店があった場合、 > ＃「Bar」で検索してもヒットして欲しい、といったような…。 > > 非正規化のオプションを付けると当然ながら今度は、 > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("５００"); > > と全角で検索するとヒットしなくなりますのでこれも避けたく > 思っています。 > ＃アプリケーションレイヤーで対応できる内容ではありますが。 > > > と、色々試してみまして、正規化と非正規化でいったいどのような > 差が出るのか、また、正規化を生かした状態で、 > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("Core"); > > をヒットさせる方法はないのか、といった点をご教授いただけ > ないでしょうか。 > > > バージョンは、下記のとおりです。 > senna-1.0.8 > mysql-5.0.45-tritonn-1.0.4 > > > 以上、お手数をおかけしますが何卒よろしくお願いいたします。 > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev ------- 島村 優太郎 yu ＠ irx.jp From ikdttr ＠ gmail.com Thu Aug 30 17:35:15 2007 From: ikdttr ＠ gmail.com (Tetsuro IKEDA) Date: Thu, 30 Aug 2007 17:35:15 +0900 Subject: [Senna-dev 666] Re: =?iso-2022-jp?b?TkdSQU0gGyRCJEckTjFRP3Q7eiROSXRKLDBsQ1cbKEI=?= =?iso-2022-jp?b?GyRCOCE6dyRLJEQkJCRGGyhC?= In-Reply-To: References: <20070830082103.30465.qmail@web2908.mail.tnz.yahoo.co.jp> Message-ID: こんにちは。池田＠tritonnです。 となるとUSING句をもうちょい拡張して対応、というのが良さそうですね。 今後のロードマップに入れさせていただきます。 07/08/30 に Yutaro Shimamura さんは書きました: > > こんにちは。島村です。 > > SEN_INDEX_SPLIT_ALPHAやSEN_INDEX_SPLIT_DIGITフラグを > インデックス作成時につけることによって、 > 文字数ごとの分割が可能になります。 > > 今のトリトンでは指定できなかったような気がしますが、 > Sennaのソースコードlib/lex.cの > > 44 lex->uni_alpha = (nstr->ctypes && !(lex->sym->flags & > SEN_INDEX_SPLIT_ALPHA)); > 45 lex->uni_digit = (nstr->ctypes && !(lex->sym->flags & > SEN_INDEX_SPLIT_DIGIT)); > 46 lex->uni_symbol = (nstr->ctypes && !(lex->sym->flags & > SEN_INDEX_SPLIT_SYMBOL)); > > 辺りをコメントアウトすると可能です。 > > (インデックス作成からやり直す必要がありますが) > > > On Aug 30, 2007, at 5:21 PM, mysql ＠ yahoo.co.jp> wrote: > > > お世話になっております。井上です。 > > 表題の件について質問させてください。 > > > > CREATE TABLE t1 (c1 TEXT, FULLTEXT INDEX ft USING NGRAM (c1)) > > ENGINE = MyISAM DEFAULT CHARSET utf8; > > INSERT INTO t1 VALUES ("FedoraCore500の技"); > > > > という状態で、 > > > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("500"); > > > > と検索するとヒットするのですが、 > > > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("00"); > > や > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("Core"); > > > > と検索するとヒットしませんでした。 > > 英数字に限り単語単位に分けているのかなと思い、 > > > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("Fedo"); > > > > と試してみたのですが、これはヒットします。また、 > > > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("50"); > > > > もヒットします。 > > 純粋にNGRAM化されているのであれば「Core」や「00」でも > > ヒットすると思っていましたので少々意外でした。 > > > > また、非正規化（NO NORMALIZE）を付けて試してみたのですが、 > > その場合には、 > > > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("00"); > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("Core"); > > > > の両方ともヒットいたします。 > > 私の方での使用用途でのお話で恐縮ですが、「00」や「Core」 > > もヒットする方がしっくりくるようなサービスの予定ですので、 > > 何かよい手はないかと困っております。 > > > > ＃例えば「DiningBar ルイーダの酒場」なんてお店があった場合、 > > ＃「Bar」で検索してもヒットして欲しい、といったような…。 > > > > 非正規化のオプションを付けると当然ながら今度は、 > > > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("５００"); > > > > と全角で検索するとヒットしなくなりますのでこれも避けたく > > 思っています。 > > ＃アプリケーションレイヤーで対応できる内容ではありますが。 > > > > > > と、色々試してみまして、正規化と非正規化でいったいどのような > > 差が出るのか、また、正規化を生かした状態で、 > > > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("Core"); > > > > をヒットさせる方法はないのか、といった点をご教授いただけ > > ないでしょうか。 > > > > > > バージョンは、下記のとおりです。 > > senna-1.0.8 > > mysql-5.0.45-tritonn-1.0.4 > > > > > > 以上、お手数をおかけしますが何卒よろしくお願いいたします。 > > > > _______________________________________________ > > Senna-dev mailing list > > Senna-dev ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > > ------- > 島村 優太郎 > yu ＠ irx.jp > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > From ym_sabn-mysql ＠ yahoo.co.jp Thu Aug 30 18:22:58 2007 From: ym_sabn-mysql ＠ yahoo.co.jp (ym_sabn-mysql ＠ yahoo.co.jp) Date: Thu, 30 Aug 2007 18:22:58 +0900 (JST) Subject: [Senna-dev 667] Re: =?iso-2022-jp?b?TkdSQU0gGyRCJEckTjFRP3Q7eiROSXRKLDBsQ1cbKEI=?= =?iso-2022-jp?b?GyRCOCE6dyRLJEQkJCRGGyhC?= In-Reply-To: Message-ID: <20070830092258.45689.qmail@web2908.mail.tnz.yahoo.co.jp> お世話になっております。井上です。 ＞島村様 > > Sennaのソースコードlib/lex.cの > > > > 44 lex->uni_alpha = (nstr->ctypes && !(lex->sym->flags & SEN_INDEX_SPLIT_ALPHA)); > > 45 lex->uni_digit = (nstr->ctypes && !(lex->sym->flags & SEN_INDEX_SPLIT_DIGIT)); > > 46 lex->uni_symbol = (nstr->ctypes && !(lex->sym->flags & SEN_INDEX_SPLIT_SYMBOL)); > > > > 辺りをコメントアウトすると可能です。 試してみました。 バッチリです！希望通りの結果となりました！ ありがとうございました！ ＞池田様 > となるとUSING句をもうちょい拡張して対応、というのが良さそうですね。 > 今後のロードマップに入れさせていただきます。 はい！ぜひよろしくお願いいたします！ ＃島村様の方法でうまくはいきましたが、やはりソースに手を ＃加えるのは抵抗がありますので… ^^; 以上、ありがとうございました！ m(_ _)m --- Tetsuro IKEDA wrote: > こんにちは。池田＠tritonnです。 > > となるとUSING句をもうちょい拡張して対応、というのが良さそうですね。 > 今後のロードマップに入れさせていただきます。 > > 07/08/30 に Yutaro Shimamura さんは書きました: > > > > こんにちは。島村です。 > > > > SEN_INDEX_SPLIT_ALPHAやSEN_INDEX_SPLIT_DIGITフラグを > > インデックス作成時につけることによって、 > > 文字数ごとの分割が可能になります。 > > > > 今のトリトンでは指定できなかったような気がしますが、 > > Sennaのソースコードlib/lex.cの > > > > 44 lex->uni_alpha = (nstr->ctypes && !(lex->sym->flags & > > SEN_INDEX_SPLIT_ALPHA)); > > 45 lex->uni_digit = (nstr->ctypes && !(lex->sym->flags & > > SEN_INDEX_SPLIT_DIGIT)); > > 46 lex->uni_symbol = (nstr->ctypes && !(lex->sym->flags & > > SEN_INDEX_SPLIT_SYMBOL)); > > > > 辺りをコメントアウトすると可能です。 > > > > (インデックス作成からやり直す必要がありますが) > > > > > > On Aug 30, 2007, at 5:21 PM, > mysql ＠ yahoo.co.jp> wrote: > > > > > お世話になっております。井上です。 > > > 表題の件について質問させてください。 > > > > > > CREATE TABLE t1 (c1 TEXT, FULLTEXT INDEX ft USING NGRAM (c1)) > > > ENGINE = MyISAM DEFAULT CHARSET utf8; > > > INSERT INTO t1 VALUES ("FedoraCore500の技"); > > > > > > という状態で、 > > > > > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("500"); > > > > > > と検索するとヒットするのですが、 > > > > > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("00"); > > > や > > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("Core"); > > > > > > と検索するとヒットしませんでした。 > > > 英数字に限り単語単位に分けているのかなと思い、 > > > > > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("Fedo"); > > > > > > と試してみたのですが、これはヒットします。また、 > > > > > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("50"); > > > > > > もヒットします。 > > > 純粋にNGRAM化されているのであれば「Core」や「00」でも > > > ヒットすると思っていましたので少々意外でした。 > > > > > > また、非正規化（NO NORMALIZE）を付けて試してみたのですが、 > > > その場合には、 > > > > > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("00"); > > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("Core"); > > > > > > の両方ともヒットいたします。 > > > 私の方での使用用途でのお話で恐縮ですが、「00」や「Core」 > > > もヒットする方がしっくりくるようなサービスの予定ですので、 > > > 何かよい手はないかと困っております。 > > > > > > ＃例えば「DiningBar ルイーダの酒場」なんてお店があった場合、 > > > ＃「Bar」で検索してもヒットして欲しい、といったような…。 > > > > > > 非正規化のオプションを付けると当然ながら今度は、 > > > > > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("５００"); > > > > > > と全角で検索するとヒットしなくなりますのでこれも避けたく > > > 思っています。 > > > ＃アプリケーションレイヤーで対応できる内容ではありますが。 > > > > > > > > > と、色々試してみまして、正規化と非正規化でいったいどのような > > > 差が出るのか、また、正規化を生かした状態で、 > > > > > > SELECT * FROM t1 WHERE MATCH(c1) AGAINST("Core"); > > > > > > をヒットさせる方法はないのか、といった点をご教授いただけ > > > ないでしょうか。 > > > > > > > > > バージョンは、下記のとおりです。 > > > senna-1.0.8 > > > mysql-5.0.45-tritonn-1.0.4 > > > > > > > > > 以上、お手数をおかけしますが何卒よろしくお願いいたします。 > > > > > > _______________________________________________ > > > Senna-dev mailing list > > > Senna-dev ＠ lists.sourceforge.jp > > > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > > > > ------- > > 島村 優太郎 > > yu ＠ irx.jp > > > > _______________________________________________ > > Senna-dev mailing list > > Senna-dev ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > > > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev >