-
kimukou2628
- 3763
- 0
- 3
- 1
-
- いいね！1
close_yutori
@kimukou2628
#solrjp RedBulｌ を検索してみましょう～ 1）出現位置をメモリ上にロード ＜どの文章にあるか 2）出現位置をソート 3）左側からソート 4）ソートしたデータから回数を出現回数取得
2011-12-19 20:37:31
MOROZUMI,Hiroyuki
@morozumi_h
RT @johtani: 先ほどの発表資料をSlideShareにアップしました。http://t.co/Mq8NUu76 #solrjp
2011-12-19 20:37:59
KITAZAKI Shigeru
@kshigeru
一般論として、速度的には 転置インデクス > Suffix Array > n-gram らしい。100%ではないけれど。 #SolrJP
2011-12-19 20:39:41
close_yutori
@kimukou2628
#solrjp SuffixArrayの長所） ・検索漏れがない＜n-gramと同じ ・n-gramより速い＜文字の長さに依存しない 転置ファイル ・・「This IS IT」 は大変＜これも楽
2011-12-19 20:40:11
焼肉8人前
@ryonext
RT @morozumi_h: 2011/12/19_第7回 Solr＆検索エンジン勉強会( #SolrJP ) http://t.co/7qFdLtpd
2011-12-19 20:40:19
close_yutori
@kimukou2628
#solrjp インデックス構築） ・構築アルゴリズムが難しい＜Haskellで作られているらしい ・インデックス＝メモリ上に納められない ＝＞HDD上で作る＝＞ランダムアクセスの形だと凄く大変<sc3,dc5アルゴリズムを使う必要があり
2011-12-19 20:42:04
close_yutori
@kimukou2628
#solrjp インデックス更新） ・差分更新・・一から構築し直しになるので出来ない＜転置ファイルなら追記が可能 ・ファイル入出力が多いので一度に沢山は作れない・・ディスク性能に依存 ＜＝Sedueでは？ SA＋インメモリn-gram＜更新分＞ のハイブリッド
2011-12-19 20:43:56
close_yutori
@kimukou2628
#solrjp 二分探索・・HDDと相性最悪＝＞SSDならOK ＝＞SSD対応のクラウドが増えると良いな～の話 圧縮接尾辞配列＝＞可能だが低速 Sedye。。最初の20段（80MB）をキャッシュとして挟む
2011-12-19 20:46:15
Jun Ohtani
@johtani
2011に治ってるｗ #solrjp RT @Ijokarumawak: Check out this SlideShare presentation : ApacheCon NA 2011 report http://t.co/Hr5DwCJ2
2011-12-19 20:49:30
close_yutori
@kimukou2628
#solrjp ストップワード） ・SAを二分探索・・ネックにはならない ・該当区間＝＞出現位置ロード 500万ポジション（位置情報アクセス）／秒＜4000万くらい無いと厳しいらしい ・出現位置ソート ＜＝実際はmallocしたページフォルトが凄くヤバイ
2011-12-19 20:49:39
close_yutori
@kimukou2628
#solrjp インデックスサイズ・・でっかいSSD買ってね＜「Fusion-io」でもいい気がするんだがw Sedue・・40バイトぐらい。
2011-12-19 20:51:38