トップページ⇒unix
987コメント301KB

全文検索エンジンEstraier

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。NGNG
個人用途向けの全文検索エンジンEstraierに関する話題を扱う
スレッドです。

http://estraier.sourceforge.net/
0161名無しさん＠お腹いっぱい。2005/04/09(土) 05:29:41
どのエンジンも一長一短でやはりエンジンを一つ決めて自作するしかないな。
0162名無しさん＠お腹いっぱい。2005/04/09(土) 06:04:38
エンジンは鯰よりも早くて良いな。

IF（単純なHTML）の自由度がないのが惜しい。
0163名無しさん＠お腹いっぱい。2005/04/09(土) 16:35:42
>>160
estindex register -tattr recipient -tattr author ...
とかやればいんじゃね?
0164名無しさん＠お腹いっぱい。2005/04/10(日) 19:20:31
subversionのレポジトリの中身を、ワーキングコピーに取り出さずに
うまいことsvn cat とかsvn lsとかだけ使ってestindexに食わせるこ
とはできるでしょうか。
0165名無しさん＠お腹いっぱい。2005/04/10(日) 21:15:47
>>164
gonzui
0166名無しさん＠お腹いっぱい。2005/04/13(水) 19:24:58
短い識別子でないとダメって今時珍しい人だな。
0167名無しさん＠お腹いっぱい。2005/04/16(土) 14:28:33
Hyper estraier がリリースされたね。
さて、APIをながめてみるか。
0168名無しさん＠お腹いっぱい。2005/04/16(土) 15:22:52
>>167
リンクはどこ？
0169名無しさん＠お腹いっぱい。2005/04/16(土) 15:52:31
ttp://hyperestraier.sourceforge.net/

APIはヘッダファイルを見た限りでは取っつきやすそう。
01701682005/04/16(土) 16:06:38
>>169 thx。
んで、estraierとhyper-eでのindexは全く別モノ？
共存さすのは無問題？
0171名無しさん＠お腹いっぱい。2005/04/16(土) 17:48:55
インデックスは別物だろう。
共存は別にできるんでないの。
0172名無しさん＠お腹いっぱい。2005/04/16(土) 19:05:10
デふぉだとindexは同じcasketつう名前の
フォルダの中にできるわけだが。
0173名無しさん＠お腹いっぱい。2005/04/17(日) 18:53:45
デフォっつーか、インデックス名は引数で指定してるだけじゃん。
違う名前にすればOK。
0174名無しさん＠お腹いっぱい。2005/04/17(日) 20:06:05
hyper-eいいね。対応フォーマットを増やしてくれるともっといい。
0175名無しさん＠お腹いっぱい。2005/04/17(日) 20:23:18
フィルタは簡単に書けるんじゃない?

rastと違ってDB作成時に属性を決める必要がないみたいで便利そう。
0176名無しさん＠お腹いっぱい。2005/04/17(日) 20:47:15
フィルタ増やすというよりLuceneみたいにいろんなアプリに組み込めると面白そう。
0177名無しさん＠お腹いっぱい。2005/04/17(日) 21:28:31
>>176
libestraier.so は飾りじゃありませんよ。
APIドキュメントが早く欲しいところ。
0178名無しさん＠お腹いっぱい。2005/04/17(日) 23:40:28
つ【doxygen,gtk-doc】
0179名無しさん＠お腹いっぱい。2005/04/18(月) 00:07:36
え、引数の意味を自分で調べてその上でわざわざDoxygenタグを自分で書けと?


ドキュメントを待つか、ヘッダファイルだけでぶっつけ本番でやった方が
いいとおもうけど。
0180名無しさん＠お腹いっぱい。2005/04/18(月) 00:15:56
ドキュメントはAPI freezeしてからでいいかも。
しかしautomakeもlibtoolも使ってないのか。
0181名無しさん＠お腹いっぱい。2005/04/18(月) 03:56:06
そいつぁいいや
0182名無しさん＠お腹いっぱい。2005/04/18(月) 06:23:55
autoconfすら使ってないzlibみたいなのもあるんだし、別にいいんじゃない?
0183名無しさん＠お腹いっぱい。2005/04/18(月) 07:52:57
コンパイルするときは便利だと思うが自分で書こうとすると
嫌になる。

バッドノウハウのかたまりだもんな。>autoconf一味

0184名無しさん＠お腹いっぱい。2005/04/18(月) 11:22:50
コンパイルするときも邪魔だと思うが、
バッドノウハウとかいう人はもっとウザい。
0185名無しさん＠お腹いっぱい。2005/04/19(火) 10:08:12
APIドキュメントも出たね。rastより簡単そうかな。
0186名無しさん＠お腹いっぱい。2005/04/19(火) 11:19:35
そう? rastよりもずいぶんと低レベルで複雑じゃない?とおもったら意図的にやってたのか、、バインディングを書いてもいいと思ってたけど、ノードAPIが出るまで待つか、、
0187名無しさん＠お腹いっぱい。2005/04/19(火) 21:27:33
全文検索のようにスケールに敏感な機能の場合、ある程度低水準の方が使いやすいことない?
内部で勝手にMutex使われていると性能が出なかったりして、API自体をいじらないといけなくなる。
本家にパッチ送って反映待ちになるのも面倒いから、自分で好きにいじれる方が、、、
0188名無しさん＠お腹いっぱい。2005/04/20(水) 15:06:10
rastとsennaの話題はここですか?
0189名無しさん＠お腹いっぱい。2005/04/20(水) 17:02:10
>>188
つ【http://pc8.2ch.net/test/read.cgi/linux/1036088927/】
0190名無しさん＠お腹いっぱい。2005/04/20(水) 17:44:09
>>187
スケーラビリティの点から見るとたしかに日記に書いてあるような
サーバークライアント方式の導入は正しいように思えるね。
mnogosearch見たいな感じになるのかしらん。

やっぱノードAPI待ちかな。それともTigerが出たらSpotlightとSearchKitに
浮気しようかな。正直迷うな
0191名無しさん＠お腹いっぱい。2005/04/20(水) 18:15:04
すげー、Windows版が出とる。
0192名無しさん＠お腹いっぱい。2005/04/24(日) 02:24:32
>>190
サーバ方式にしてもスケーラビリティは上がらないんじゃない?
検索速度は上がるかもしれないけど、ネットワークの負荷を考えると微妙。
0193名無しさん＠お腹いっぱい。2005/04/25(月) 04:38:56
ネットワーク遅延はデータベース検索においてそれほど大きな問題じゃない
と思うよ。そもそもデータベースのスケールによらず一定だし。

コアAPIの守備範囲であるローカルホストならなおさらじゃない?
0194名無しさん＠お腹いっぱい。2005/04/25(月) 10:24:35
確かにそうかも。
それと、DBとは別のマシンでアプリケーションを動かせだろうから、フィルタと登録を
パイプライン的にやれば効率いいかもね。
秒速104文書登録ってのをどこまで維持できるかが見もの。
0195名無しさん＠お腹いっぱい。2005/05/02(月) 10:13:17
rast 0.1.0ｷﾀｰ
0196名無しさん＠お腹いっぱい。2005/05/02(月) 20:03:29
Estraier と HyperestraierとCGIの検索スピード比べると、
大体Hyper...のほうが倍くらい早いかなて感じだ（当社比）。
0197名無しさん＠お腹いっぱい。2005/05/02(月) 20:23:55
唐突に出てきた「CGI」という謎の実体について。
0198名無しさん＠お腹いっぱい。2005/05/02(月) 20:54:06
HyperestraierをCGIとして使った場合の速度＞Estraier をCGIとして使った場合の速度
ってことでわ？
0199名無しさん＠お腹いっぱい。2005/05/03(火) 11:59:48
検索インターフェイスってwebしかないの？
コンソールとXで動くやつもあると嬉しいんだが。
0200名無しさん＠お腹いっぱい。2005/05/03(火) 12:35:57
ライブラリ使ってなんとかしろ。
0201名無しさん＠お腹いっぱい。2005/05/03(火) 12:37:35
インクリメンタルな全文検索インターフェースを頼む。
0202名無しさん＠お腹いっぱい。2005/05/03(火) 13:09:05
Hyperestraierでestcmd gatherするとき、
sym link をdereferenceしないようにお願い
したいんだが、どうすれば良い？
0203名無しさん＠お腹いっぱい。2005/05/04(水) 16:46:01
中の人に言えば?
02042022005/05/04(水) 20:12:26
static const char *pathtourl() のなかで
realpath()を呼んでるからだ、つうとこまでは分かった
んだが、絶対パスに展開するのやめさすと各方面に
色々面倒が起きそうな希ガス。
>>203の言うとおり、作者に頼むしかないかな。
0205名無しさん＠お腹いっぱい。2005/05/04(水) 21:30:07
APIの呼び方さえ変えなければ特に問題ないと思うけど。
MLに投げれば対応してくれるかも。
0206名無しさん＠お腹いっぱい。2005/05/08(日) 11:02:50
mboxファイル用のフィルタはないですか?
0207名無しさん＠お腹いっぱい。2005/05/08(日) 18:34:26
>>201
高林さんとかの JavaScript を参考に組めば出来ると思うけど、
たぶんめっちゃおもくなるとおもわれ。
0208名無しさん＠お腹いっぱい。2005/05/08(日) 20:54:44
>>207
>>201 は Ajax なインターフェースのことを言ってると思われ。
0209名無しさん＠お腹いっぱい。2005/05/08(日) 20:59:06
>>208
> >>201 は Ajax なインターフェースのことを言ってると思われ。

ちがう。
0210名無しさん＠お腹いっぱい。2005/05/08(日) 21:01:23
>>207
> 高林さんとかの JavaScript を参考に組めば出来ると思うけど、
> たぶんめっちゃおもくなるとおもわれ。

migemoのアイデアって、1990年ころに、プライベートな
研究会で見たことがあるよ。いや、べつにそっちの方が
先だとか言いたいわけではない。みんな同じことを考え
ていたんだということ。で、「たぶんめっちゃおもくな
るとおもわれ」とコメントされ、それで終わっていた。
0211名無しさん＠お腹いっぱい。2005/05/08(日) 21:46:12
>>209
ありゃ、違うのか。 >>208 で合ってたのかな。
0212名無しさん＠お腹いっぱい。2005/05/08(日) 22:30:05
Ajax風に難しいことをやるのでなければ、
onChangeイベントでsubmitするだけでしょ？

たぶんめっちゃおもくなるとおもわれるけど。
0213名無しさん＠お腹いっぱい。2005/05/08(日) 22:34:28
前に Ajax でリクエストをばんばん飛ばすスクリプト書いたけど、結構レスポンス良かったよ。

ただ、インクリメンタルにする意義が感じられなくて結局使ってないけど。
0214名無しさん＠お腹いっぱい。2005/05/08(日) 22:42:49
インクリメンタル検索って、オモチャとしては面白いけど、実用的ではないよね。
エディタで使うみたいに、一個のファイルの中をインクリメンタル検索するのは便利
なんだけど、不特定多数の文書をファイルを対象にた場合は意味がない。
インクリメンタルである利点は、前後関係が確定している場合にのみ享受できる。
0215名無しさん＠お腹いっぱい。2005/05/08(日) 23:39:23
エディタでも実用的じゃないし
0216名無しさん＠お腹いっぱい。2005/05/08(日) 23:41:20
インクリメンタルなんてほしがるのは素人だけ。
あれは単なるけばけばしい包装、はなばなしいだけの
ファンファーレ。
そんなものをほしがるやつには、UNIXを使う資格はない。
0217名無しさん＠お腹いっぱい。2005/05/08(日) 23:50:04
プログラマなら、エディタのインクリメンタル検索は使いまくる
と思うんだけど、みんなは違うの?
0218名無しさん＠お腹いっぱい。2005/05/08(日) 23:58:20
目と頭が付いていけないから使ってない
俺の言う事を最後まで聞け（ｺﾞﾙｧ　と思う事多し

動的なインターフェイスは使用者に掛かる負荷が大きいんだよね
何も考えずにインクリメンタルサーチ使える人は正直感心する
0219名無しさん＠お腹いっぱい。2005/05/09(月) 00:14:29
んなこと言ってたら自動車の運転もできないじゃん。
0220名無しさん＠お腹いっぱい。2005/05/09(月) 01:27:21
これは複数サーバ(or ディスク)を使って分散処理を行う事は出来るの？
チュートリアルにそれに関した記述が見当たらなかったんだけどやっぱり無いのかな。
0221名無しさん＠お腹いっぱい。2005/05/09(月) 01:55:12
estの方はできるでしょ。hyperの方は知らない。
0222名無しさん＠お腹いっぱい。2005/05/10(火) 11:37:13
自分でインデックスを更新するのでなく、新しく保存したファイルを自動検知
してその分だけ更新するようにできないかな。
0223名無しさん＠お腹いっぱい。2005/05/10(火) 12:03:00
>>222
もちろんできるでしょ。
0224名無しさん＠お腹いっぱい。2005/05/10(火) 12:38:46
新しいかどうかを検査する負荷もバカにならないから現実的じゃ無い気も。
0225名無しさん＠お腹いっぱい。2005/05/10(火) 13:04:17
>>224
そう思うなら、口を閉じて引っ込んでろ。
0226名無しさん＠お腹いっぱい。2005/05/10(火) 13:34:10
FAMとかgaminとか使うといいかも。
FAM：http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&fname=/SGI_Developer/books/IIDsktp_IG/sgi_html/ch08.html
gamin：http://www.gnome.org/~veillard/gamin/

いずれにせよOS依存なので、自分の環境にかなり精通していないと難しいだろう。
Google Desktop Searchはどうやってるのか知ってる？
0227名無しさん＠お腹いっぱい。2005/05/10(火) 13:51:17
>>225
なにそんなカリカリしてるの？
02282222005/05/10(火) 14:26:13
>>226
どうもです。でもプログラミングしないといけないのは辛いですね。
過去1時間に更新された更新ファイルのパスのリストがどっかのファイル
に記録されているような仕様だったら嬉しいのですが。

あ、ちなみに225は私じゃないですよ。
0229名無しさん＠お腹いっぱい。2005/05/10(火) 14:41:52
>>223
それどうやるの？
0230名無しさん＠お腹いっぱい。2005/05/10(火) 15:02:09
>>226
Beagleは使える環境の場合はInotifyを使うみたい。
0231名無しさん＠お腹いっぱい。2005/05/10(火) 16:15:10
dnotifyだと指定したディレクトリ直下しか見れなかったけど、
inotifyでもそこんとこは変わってないよね?
監視対象を再帰的に広げるよりは、定期的にfindした方が負荷が小さいような。
0232名無しさん＠お腹いっぱい。2005/05/10(火) 16:32:35
>>231
そう思うなら、口を閉じて引っ込んでろ。
0233名無しさん＠お腹いっぱい。2005/05/10(火) 16:40:20
>>231
軽量高速な更新検出手段の探求/実現が必要ですねッ!!
0234名無しさん＠お腹いっぱい。2005/05/10(火) 16:47:45
>>233
ガンバレー！！
0235名無しさん＠お腹いっぱい。2005/05/10(火) 17:44:25
高速じゃなくてもいいなら、適当にsleepして軽量にすることは可能だろう。
明示的に更新を通知する手段と、更新頻度が高い場所は巡回頻度も高めると
いった工夫を併用すればかなり使いやすくなるんじゃない?
0236名無しさん＠お腹いっぱい。2005/05/10(火) 17:54:10
>>232
そうカリカリすんなよ。歯痛にでもなったか?
0237名無しさん＠お腹いっぱい。2005/05/10(火) 23:44:55
あとOracleのFull-Text Searchは専用のデーモンを立ち上げて監視させる
仕組みになってたと思う。
0238名無しさん＠お腹いっぱい。2005/05/11(水) 18:00:03
ファイルシステムから作ればいいんだっ！！
0239名無しさん＠お腹いっぱい。2005/05/11(水) 18:20:12
>>238
わかった。全部お前にまかすわ。あとはよろしくな。
0240名無しさん＠お腹いっぱい。2005/05/11(水) 18:24:58
あと重要なのは、特定の格納形式/更新形式を持つファイル群を
ハンドリングするプラグインを扱う枠組みだな。
0241名無しさん＠お腹いっぱい。2005/05/11(水) 18:29:16
>>240
わかった。そっちはお前にまかすわ。あとはよろしくな。
0242名無しさん＠お腹いっぱい。2005/05/11(水) 18:53:11
APIがあるからアプリケーション主導で開発できるわけで、
プラグイン機構は不要だと思われる。
それよりPerlかRubyのバインディングを早く出してほしい。
0243名無しさん＠お腹いっぱい。2005/05/11(水) 19:57:37
>>242
いや、じゃなくて、新しい文書扱いシステムを作った側が、
検索エンジンがそれを効率良く扱えるように
一連の設定やプログラミングを行なう枠組みが
いるのではないかという話だ。
02442422005/05/11(水) 22:48:38
なるほど。
更新処理をトリガとして関数が呼ばれる仕組みが大抵のDBには備わっているけど、
一般的な文書扱いシステムではどうなんだろう。
0245名無しさん＠お腹いっぱい。2005/05/12(木) 11:45:47
監視対象のディレクトリがわかっているなら、そのディレクトリに対して
select() かけることで対応できないかなあ｡
0246名無しさん＠お腹いっぱい。2005/05/12(木) 12:18:15
それだとcreatとunlinkは検出できるけど、writeが検出できなくない?
0247名無しさん＠お腹いっぱい。2005/05/14(土) 02:55:39
日本製全文検索が開発中のもよう
Rast: A full-text search system
ttp://www.netlab.jp/rast/

●検索対象となる文書の分野や言語を選ばない
テキストデータを n 個の文字の並びである N-gram に分割して検索を行うため，「検索漏れが生じない」，「辞書の整備が必要ない」という特徴がある N-gram 方式を選べます．
これにより，検索対象となる文書の分野や言語を選ばずに広く利用することができます．

●多様なファイル形式への対応
HTML や Microsoft Word といった多様なファイル形式の文書からテキストデータやタイトルや作成日などの属性情報を抽出し，検索対象にできます．

●全文検索ライブラリの提供
C 言語と Ruby で利用可能な全文検索ライブラリを提供することにより，本ソフトウェアを利用した全文検索を行うアプリケーションを開発することができます．
さらに，ライブラリの利用例として，過去のメールを全文検索できる電子メールソフトを開発します．

●インクリメンタルな文書の追加登録
作成したデータベースに対して，インクリメンタルに文書の追加登録ができます．このため，一度作成したデータベースを作成し直す必要がありません．


誰か試して
0248名無しさん＠お腹いっぱい。2005/05/14(土) 03:58:31
精度とかはまだまだ。euc-jpだとutf-8にくらべてバグが多い気がする。
C APIを提供してるわりにクライアントライブラリまでGPLなのはちょっと痛い。

せめてXMLRPCの仕様を公開してほしいが、だったらEstraierのノードAPIを
待った方が幸せになれそう。

Matzのお膝元のnetlabで開発してるので、Rubyを使ったアプリケーションが
いろいろ出回ってきたら面白くなるのかもしれない。
0249名無しさん＠お腹いっぱい。2005/05/14(土) 17:02:09
Rubyがどうしたとかテストにはtcl使ってね
とか言われた時点でもう、センスつうか趣味
つうか合わないを思いますわ、パスですわ
>>247
0250名無しさん＠お腹いっぱい。2005/05/14(土) 17:18:49
>>249 Perlだったらいいわけか?
0251名無しさん＠お腹いっぱい。2005/05/14(土) 19:50:07
Javaだったらよかったのにね。
0252名無しさん＠お腹いっぱい。2005/05/14(土) 20:45:23
>>251 lucene
0253名無しさん＠お腹いっぱい。2005/05/14(土) 22:58:21
hyperestraier 0.3.8 コンパイルしないな。
ML archive も落ちてる。
0254名無しさん＠お腹いっぱい。2005/05/14(土) 23:58:14
「QDBMのバージョンが古い」に一票 >> 253
02552532005/05/15(日) 07:59:47
その通りだった。トンクス >>254
02562542005/05/17(火) 00:09:15
俺もはまったからさ。
0257名無しさん＠お腹いっぱい。2005/05/25(水) 10:37:35
0.3.10あげ
http://hyperestraier.sourceforge.net/
0258名無しさん＠お腹いっぱい。2005/05/25(水) 16:35:21
インクリメンタル検索がサポートされたね
0259名無しさん＠お腹いっぱい。2005/05/25(水) 22:28:14
>>258
SUGEEEEEEEEEEE!!!!!!!
0260名無しさん＠お腹いっぱい。2005/05/27(金) 18:44:35
rastをCygwinで構築出来た人いる？
■ このスレッドは過去ログ倉庫に格納されています