春山 征吾のくけー

https://www.unixuser.org/~haruyama/blog/ に移転しました http://wiki.livedoor.jp/haruyama_seigo/d/FrontPage @haruyama タイトルが思いつかないときはそのときかかってた曲をタイトルにしています.

全文検索

Lucene/Solr でのフィールドのユニークな値の数の求め方

Lucene/Solr で フィールドに入っているユニークな値の数を求めたい場合があります. たとえばユニークユーザ数を求める場合です.

初級編

FieldCollapsing - Solr Wiki を利用します.

group.ngroups パラメータを true に指定するとクエリにマッチするグループの数を出力してくれます.

/solr/select?group=true&group.field=[フィールド名]&group.ngroups=true&...

1日1.5億PV/数百万UU 1時間最大1千数百万PV/百万UU という想定で, 1時間のUUを(qパラメータで時間を区切って)求めると, 数十秒(1分越えることもある)で得られました.

中級編

上記の想定では1日のUUを求めるにはちょっと重たそうです.

ここで Solr のコアは1日ごとに別々だとします.

コア単位でフィールドのユニークな値を求めるのに, LukeRequestHandler - Solr Wiki が利用できます.

/solr/admin/luke?fl=[フィールド名]

Solr Wiki のページを distinct で検索してもらえればわかりますが, フィールドのユニークな値の数が得られます.

上記の想定で1日のUUをこの方法で求めると, 10秒前後でした.

上級編

もし, 1時間のUUも初級編の方法では時間がかかりすぎる, 中級編であればいけるという場合はどうしたらいいでしょうか.

この場合は検証してないのですが, 1時間ごとにコアを作成することになるでしょう. 1時間ごとのUUはそのまま LukeRequestHandler を用います. 1日のUUは, インデックスをマージしてやはり LukeRequestHandler で求めます.

Solr のインデックスのマージについては MergingSolrIndexes - Solr Wiki に記述されています.

もしくは, 特定のフィールドの値が複数の shard に入らないようにして適当にするでしょうか.

2011/07/07 Sole 3.3 + lucene-gosen 1.1.1(ipadic)を評価 #SolrJP

2011/05/16のSolr勉強会の発表での条件で Solr 3.3 + lucene-gosen 1.1.1 を評価しまし.た.

Solr 3.2 + lucene-gosen 1.1.0 と大きなパフォーマンスの違いはないようです.

JapaneseTokenizer(ipadic,Solr 3.1, lucen-gosen 1.0.0) JapaneseTokenizer(ipadic,Solr 3.2, lucene-gosen 1.1.0) JapaneseTokenizer(ipadic,Solr 3.3, lucene-gosen 1.1.1)
時間(QTime,h:mm:ss) 36:53 29:26 29:20
サイズ(Gbyte) 6.75 6.75 6.75

2011/07/03 OpenGrokを利用したソースリーディング

2011/07/03 今日はだらだらするつもり.

昨日の [[Luceneとか読んでモヒカン生やす会 - [PARTAKE]>http://partake.in/events/31ec4a0e-e028-4759-847f-aa4112cc0f8e]] では OpenGrokGNU GLOBAL の準備をしていった. がほぼ OpenGrok のみで読んだ. 手を動かさずに読むだけなら全文検索ができる OpenGrok のほうがよいと感じた.

Jenkins CI などでCIする際は, ソースコードを持ってくるので OpenGrok などでソースコード検索もできるようにしてしまうのがよいと思う. ECナビでも少しやっていたが, 広く展開するところまではやれなかった.

Xでの日本語入力をDebian sidの都合にあわせてuim->ibus->uimとした. ~/.uim でのローマ字かな表の上書きが効かなくなったみたい?

2011/07/02 Luceneとか読んでモヒカン生やす会に参加

2011/07/02 Luceneとか読んでモヒカン生やす会に参加.3時間じっくりコードを読んだのでだいぶLuceneの動きがわかった.

以前全文検索エンジンLuxの山田さんに検索エンジンの基本的な動きを講義していただいたことがあって,その知識が役にたった.

その後会場やお店でいろいろ雑談.大変面白かった.

〜のコードの読む会というのは小さな勉強会ネタとしてよさそうなので,今度企画してみようかしら.

Solr: Kuromojiを評価 その2 #SolrJP

春山 征吾のくけー : Solr: Kuromojiを評価 #SolrJP - livedoor Blog(ブログ) にてコメントを頂きました.

参考になります。

kuromojiのは、検索用に小さいトークンを生成するために、追加の処理をしているようです。normalモードで比較したらそんなに遅くないんじゃないかと思ったりします。

というわけで normal モードでも測定しました.

Solr/Tokenizer評価201105/KuromojiTokenizer - 春山征吾のWiki - livedoor Wiki(ウィキ)

searchモードと結果はあまり変わりませんでした.

lucene-gosen 1.1.0 を第5回Solr勉強会の発表の条件で評価しました #SolrJP

2011/05/16のSolr勉強会の発表での条件で Solr 3.2(3.1ではない) + lucene-gosen 1.1.0 を評価しまし.た.

私の評価では以前の環境よりも20%高速になっています.

JapaneseTokenizer(ipadic,Solr 3.1, lucen-gosen 1.0.0) JapaneseTokenizer(ipadic,Solr 3.2, lucene-gosen 1.1.0)
時間(QTime,h:mm:ss) 36:53 29:26
サイズ(Gbyte) 6.75 6.75

Solr: Kuromojiを評価 #SolrJP

Twitter / @ブルーツリー: Sen以外でのJavaのOSSの形態素解析器があるな ... で知った Kuromoji - ATILIKA Community Innovation という形態素解析器は, Solrで利用することができます.

5/16のSolr勉強会での評価をKuromojiでも行ない追記しました.

Kuromojiは...dictionaries are based on MeCab-IPADIC とのことです.

lucene-gosenのJapanizeTokenizer(ipadic)と比べると倍以上遅い結果になりました.

JapaneseTokenizer(ipadic) KuromojiTokenizer
時間(QTime,h:mm:ss) 36:53 1:21:48
サイズ(Gbyte) 6.75 6.70

JapaneseTokenizerとCompositeTokenFilter, compositePOS #SolrJP

Solr勉強会でJapaneseTokenizerの説明をした際, naist-chasen辞書を用いた際のTokenize結果のサンプルで, いくつかのASCIIで構成された単語が1文字ずつ分解されてしまったと説明しました.

すると CompositeTokenFilter への入力を compositePOS 属性で渡せばよいというご指摘を頂きました.

compositePOS として以下を与えて未知語と記号-アルファベットとマージしたところ, 単語が1つの未知語Tokenとして切り出されるようになりました.

未知語 未知語 記号-アルファベット

Solr/Tokenizer評価201105/JapaneseTokenizer - 春山征吾のWiki - livedoor Wiki(ウィキ) の末尾に設定とTokenizeサンプルを追加しました.

2011/05/16 Solr勉強会/ECナビ退職日 経営者と専門家

2011/05/16 Solr勉強会でECナビ退職日. 勉強会の資料はできたのでwktkしながら待つ.

高木浩光@自宅の日記 - 富士通総研が研究員のコラムを削除、国民ID・共通番号制度を巡る現況 を読んで, すこしだけ私の退職理由に関係があったので触発されて書く. 公の場で退職理由について書くのは今日で最後にしようと思っている.

私の退職の理由は, 個人情報の連携について専門家としての意見が(正規の手段では)経営側に受けいれられなかったためだ(Twitterに退職すると書くという非正規の手段を使って少し変化があった).

(非専門家な)経営者と(非経営者な)専門家の間では, 最終的な事業の決定権は経営者にあると私も考える. 事業に可能性があれば, それが小さくても, 経営者が追求するというならば専門家は雇用条件の範囲で従う必要がある. しかし, 専門家がこの事業は(例えば, セキュリティ面で)100%やっちゃだめだと明言したならば, 専門家としての知識・経験を買って雇用している以上, その意見を聞いてもらわないと困る. どうしても進めるならば会社都合で馘首してもらうしかない. IT技術者だけではなく法務などのすべての専門家についていえることだ.

以上が原則でかつそうあるべきだと思うが, 現実にはそうなっていない. 専門家が自分の意見をよりはっきり言えるようになるためには, 経営者と専門家を含む社会の変化が必要となるだろう. 私は扶養家族がなく無職になってもすぐには飢えないですむので今回退職の決断ができたが, すべての人がそうではない. 自分になにができるか/なにをするべきか現時点ではわからないが, なにかできればいいなと思っている.

QRコード
QRコード
  • ライブドアブログ