全文検索エンジンを作りたい、作っている人のｽﾚ
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/03/27(土) 02:29:11いまつくってる
0002デフォルトの名無しさん
2010/03/27(土) 02:35:27findは有料だし
0003デフォルトの名無しさん
2010/03/27(土) 02:42:25リアルタイムでindexして全文検索出来るやつってこと?
0004デフォルトの名無しさん
2010/03/27(土) 02:43:190005デフォルトの名無しさん
2010/03/27(土) 02:48:460006デフォルトの名無しさん
2010/03/27(土) 04:31:120007デフォルトの名無しさん
2010/03/27(土) 05:39:050008デフォルトの名無しさん
2010/03/27(土) 06:27:30言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
0009デフォルトの名無しさん
2010/03/27(土) 10:31:03下のスレが唯一参考になるんだが。
Googleデスクトップとかはどうやってるんだろ？
第20回 転置インデックスの実装（その2）
ttp://gihyo.jp/dev/serial/01/make-findspot/0020
0010デフォルトの名無しさん
2010/03/27(土) 13:13:49ブロックを拡張する方法は、やっぱり遅かった。一般のHDDではシークが
ネックになるので、極力シークしないで作るようにしたよ。
つまり、これまで作った巨大な転置インデックスはそのまま利用し、十分
小さい転置インデックスだけを書き換えるようにしていた。検索時は巨大な
インデックスと小さいインデックスの両方を検索してマージ。小さいインデックス
が大きくなってきたら、バックグラウンドで巨大インデックスとマージ（これは時間
掛かるので週1処理とか)。マージが終われば、小さいインデックスを空にする。
こんな実装してますた
0012デフォルトの名無しさん
2010/03/27(土) 19:29:32すげー参考になります！さんくす！
今考えてるのは単語の出現確率であらかじめ予定サイズを割り振っておいて
最初に全体で800MBとか巨大に取ってしまって、そこに割り振る、という感じです。
（Google Desktopがそんな感じ？ぽいので）
0013デフォルトの名無しさん
2010/03/27(土) 19:36:05200個くらいに分割すれば、一個5Mでも1ギガ扱える。
更新は5M程度済む。
0014デフォルトの名無しさん
2010/03/27(土) 19:38:48であらわせる。
1Mあれば、100万個の位置を記録できる。
001510
2010/03/27(土) 20:05:59それも考えたんだけど、結局小さいインデックスを多数用意するという事は、
シークがそれだけ増えるのであんまりパフォーマンスでなかった。
でも、RDBMSのようにテーブルスペースを定義し、複数のストレージに
同時アクセスできれば状況が違うかも知れない。少し考え方が違うけど、
H.E. のバックエンドであるqdbmは、そういう事ができる
>>14
H.E. .なんかだと、そもそも位置情報はいらないんじゃないかという大胆な
発想だけど、>>9でもポイントされているFINDSPOTでは位置情報をあいまい
検索なんかに利用していて、バッサリ切るにはもったいない。
位置情報に限らず、転置インデックスにはデルタが必ず正の数になる数列が
色々出てくるわけで、この性質に特化した専用圧縮は、確かに効果が高い。
今、圧縮sufix arrayのイイトコドリして転置インデックスを圧縮できないか奮闘中
一応言っとくけど、自分はH.E.の中の人でも FINDSPOTの中の人でもない、ただの人です。
0016デフォルトの名無しさん
2010/03/27(土) 20:17:30シークじゃなくてファイルのopenなどが時間くう。
100個-200個程度なら開きっぱなしでいけるはず。
0017デフォルトの名無しさん
2010/03/27(土) 20:26:09うん。だからランダムアクセスはなるべく使わないようにやってみたよ。
つまり"foo"のインデックスは、1ファイルの一箇所に常にまとめる。
分散すると"foo"のインデックスを複数ファイルから検索する事になる
ので遅くなってしまうのが分散のデメリットだと思った。
だけどこれだと書き込みが出来ない（やりにくい）ので、苦肉の策で
間を取ったのが、>>10で書いた大きいのと小さいのとの2つに分散する方法
0018デフォルトの名無しさん
2010/03/27(土) 20:29:11一ファイルずつ分けたって同じだろう。
0019デフォルトの名無しさん
2010/03/27(土) 20:33:28open()の負荷は別問題として、それならいいんじゃないの？
問題としてたのは、"foo"を数箇所から取得するという事だから。
あくまで、うちで作った実装での話しだけどね。
0020デフォルトの名無しさん
2010/03/27(土) 20:40:10一ファイルだと一部の追加だけでまるまるコピーしないといけない。
0021デフォルトの名無しさん
2010/03/27(土) 20:52:45大移動を避けるかどうかという視点だと、ファイルシステムレベルなら確かに
1-gram 1ファイルはアリのように見える。
でも、それはあくまでファイルシステムから見た場合の話しであって、ファイルが
細切れになっていると、せっかく同一ファイルの同一位置に情報を集約しても物理
的な配置がばらばらになって検索パフォーマンスは悪くなったんだよ。
0022デフォルトの名無しさん
2010/03/27(土) 21:03:47どちらにしたって断片化は防げないし
断片化しないように書き込むには毎回
領域確保して書き込まないとね
0023デフォルトの名無しさん
2010/03/27(土) 21:08:11だね
その辺は実はまだ追求が甘いんだけど、テキトーに確保したりそんな感じ
いずれにせよ、うちの実装だと大移動があるのは事実なので、そこは確かに
弱点なんだなー
0024デフォルトの名無しさん
2010/03/28(日) 05:27:24アルゴリズムでブロック単位で読みことが確定していれば別だが。
0025デフォルトの名無しさん
2010/03/28(日) 05:29:160026デフォルトの名無しさん
2010/03/28(日) 05:32:17デスクトップで使ってほかにもソフト動くなら占有できないが
0027デフォルトの名無しさん
2010/03/28(日) 05:39:42俺のソフトでは何も考えずに後ろにぽんぽん追加してたら（転置インデックス部分じゃないけど）
10000とかに断片化していて直近のデータサーチするのが死ぬほど重くなった。
100MB単位とかで確保してしまった方がいいような希ガス。
0028デフォルトの名無しさん
2010/03/28(日) 06:16:25あまり断片化のことは気にしなくなったな…
扱うデータがそれほど大きくないので外に
出して管理したほうが楽だった…
0029HDDは安価になり申したがﾒﾓﾘはそれなり
2010/03/28(日) 06:34:50環境復旧までかかる手数を最小限に押さえ込む
いま必要な道具だけzip風な形式で固めておいて
展開して復旧。あとはいらないpluginの見直し(これでだいぶ軽くなる
この辺か…ｸﾗｲｱﾝﾄｻｲﾄﾞで気をつけてることは…。
0030デフォルトの名無しさん
2010/03/28(日) 07:24:20うちは商用だけど、転置インデックスそのものは自分の私物。
いつか公開したいと思ってたりするんだけど、特色ないとつまらないよな。
0031デフォルトの名無しさん
2010/03/28(日) 09:58:07どっちなの？
0032デフォルトの名無しさん
2010/03/28(日) 18:56:12ん、つまりRDBMSで例えるなら自分で開発したMySQLみたいな物を
持っていて、仕事ではそれを利用してアプライアンス作ったり、WEB
サイトのバックエンドに利用したりしてるってイメージ。
だからデスクトップ用とかサーバー用とかいう以前に、ただの部分でしかないね。
0033デフォルトの名無しさん
2010/03/30(火) 21:14:320034デフォルトの名無しさん
2010/03/30(火) 21:20:560035デフォルトの名無しさん
2010/05/31(月) 12:03:360036名無しさん＠そうだ選挙に行こう
2010/07/11(日) 11:13:240037南沢木綿子 ◆b9XrZzBUdaVS
2010/09/01(水) 12:34:07( ・∀・) ほー それで
( ： )
し─J
0038デフォルトの名無しさん
2010/10/18(月) 18:26:37intの範囲も超えるし、基本データ構造から作り直さないとダメっぽい。
転置ファイルを高速化するチャンスではあるんだけど(>>10さんの方法で行く予定)
やっぱ面倒（はぁ）
と愚痴をこぼしつつ保守でした。
0039デフォルトの名無しさん
2010/10/18(月) 21:13:480040デフォルトの名無しさん
2011/01/04(火) 21:44:29自分用にインターフェース部だけ作りたい
0041デフォルトの名無しさん
2011/02/01(火) 18:23:080042デフォルトの名無しさん
2011/04/02(土) 11:07:07.680043デフォルトの名無しさん
2011/04/12(火) 03:23:24.57一文字を含むすべての2文字にしたら計算時間かかると思いますが。
004443
2011/04/13(水) 19:29:43.570045デフォルトの名無しさん
2011/07/22(金) 22:38:45.850046デフォルトの名無しさん
2011/09/27(火) 18:16:42.84>>1は完成したのか？
>>43
>>44の方法は一見よさげだけど、占有するディスクサイズ以外に、キャッシュヒット率が
落ちるという問題があるのであまりお勧めできない。
2gramのaa~az を物理的な近傍に配置し、"a"で検索する時に一気に読み込みできるロジックがあると良いよ。
0047デフォルトの名無しさん
2011/11/28(月) 02:26:57.90http://www.kensaku-giken.com/2/904-2.htm
PCのYahoo!・Google・MSNの順位・インデックス数・被リンク数チェック
携帯のYahoo!モバイル・Googleモバイル・gooモバイルの順位・インデックス数・被リンク数チェック、
ライバルサイトのインデックス数・被リンク数のチェックなどができます。
毎日１回起動して、【検索】ボタンを押すだけで、
数百サイトの順位チェックを自動で行い、過去の検索結果も記録して残します。
SEO対策の検証に不可欠な順位・インデックス数・被リンク数の変動をチェックすることができます。
市販されている順位チェックツールは１万円以上するものばかりですが、
そのようなツールよりも高機能なのに無料です。
利用制限なども一切ありません。
PC＆モバイル対応の検索順位チェックツールです。
0048デフォルトの名無しさん
2011/12/11(日) 16:26:09.55http://www.ne.jp/asahi/sun/patagonia/fulltext/fulltext.html
うまく全文検索できないときには掲示板に書きこんでくれ。
0049デフォルトの名無しさん
2011/12/11(日) 19:02:03.190050デフォルトの名無しさん
2011/12/11(日) 21:52:05.64乙。
ソースは見てないけどリアルタイムにデータの追加は可能？
0051デフォルトの名無しさん
2011/12/12(月) 05:11:57.940052デフォルトの名無しさん
2011/12/12(月) 17:46:11.130053デフォルトの名無しさん
2011/12/12(月) 23:34:40.61一文字単位で登録して漏れなし検索を実現する。PHPのみで。
0054デフォルトの名無しさん
2012/01/11(水) 21:20:24.630055デフォルトの名無しさん
2012/01/13(金) 22:06:26.23アダルト専門の検索エンジンだったら、結構、人気が出るかもしれんが。
■ このスレッドは過去ログ倉庫に格納されています