第４回Solr勉強会 - sub usuilog;

第２回から３回目の参加。
http://atnd.org/events/9458

1.Lucene Revolution 参加報告

Basis Technology　平賀一昭 (日本支社)さま, 黒坂輝彦(サンフランシスコ支社)さま

Lucene Revolutionとは
- Lucid Imagination社主催によるLucene/Solrに関するユーザ会議
Lucid Imagination社
- LuceneとSolrの商用利用促進のために設立
- コミッタが多数参加
エンジニア向けトレーニング
- Luceneのソースコードを確認しながら、理解する
BASISさん主催
- Solrアプリケーション開発３日間コース
- 「Solr勉強会で聞いた」で10% Off !
- 本年度中に申し込みで20% Off!
Lucene & Solr User Conferenceについて
- ハイアットハーバーサイド（ボストン空港のすぐそば）
- ダウンタウンは遠い。カンファレンスに集中しろって？
会場の様子
- ４箇所くらいでセッション
- ホールでは朝食、コーヒー、クッキー
- http://www.lucidimagination.com/events/revolution2010
Lucene/Solrロードマップ
- 各々のコミッタがやりたいことを主張しているだけ？
- Solr Cloud、大規模処理、リアルタイムが大筋の方向性っぽい
TwitterでのLuceneの活用
- A Billion Queries Per Day１日１０億クエリー
- MySQLからLuceneへ以降
- Luceneの索引周りを改変している模様
- かなりマニアックな内容
- 1000 tps (tweets/sec) => 80M tweets/day
- 12,000 qps => 1G queries/day
- tweetから10秒latency( tweet後検索できるようになるまでの時間)
- tweetから1秒いないにindexing
- 最新のつぶやきを最初に表示したい索引項目中のdoc listの後ろからスキャン
- 全部検索しないで途中でうちきり
- LUCENE-2329前 postingListはクラスオブジェクトを指していた。オブジェクトの生成が必要で効率が悪い->三つのArrayに分割して効率があがった。Lucene4.0で出てくる？
- docIdとpositionを別々に持っていた。Twitterは文字数が少ないのでpositionは１バイトでよい。docIDを24bit、positionを8bitで表現 > ひとつのintに押しこむ
- Lock-freeアルゴリズム（スレッド間の同期でロックを使わない)
- volatile変数ひとつを使って、スレッド間の同期をとる話
- Java言語規約を深読み。volatile変数の処理順？が決められている
- 実際はJVM内でロックしている気もする
Solr 3.1とその後
- LuceneとSolrサブプロジェクトの合併
- 次期リリースはSolr 3.1 (Solr 1.5ではなく)
- 現在trunkにあるのは、Solr 4.0になる？
Solr 3.1新機能
- 拡張DisMaxパーサー。Luceneパーサの構文をサポート。例外をおこらなくするのが目的だった。それを教科。Boostは加算のみだったのが積算で出来るようになる
- 空間・地理検索。緯度経度情報をもとに検索
- 結果のグループ化／フィールドたたみ込み（collapsing)。グーグルの同じサイト内の検索結果をまとめるやつ。任意のフィールドでまとめることができる
- ファセット機能改善。ピボットとして指定されたフィールドによってさらに再分割できる。数値の範囲も指定できる
- Solr Cloud。シェーディングするときにホスト名を羅列しないでよくなる
柔軟な索引（？）
- 索引構造もプラグイン化して変更可能に
- テキスト表現をUTF-8にしたり、BOCU1（Unicode圧縮）にしたりできる
- Codec部分をプラグインに
LucidWorks Enterprise
- Solr + GUI管理ツール + クローラ+ いろいろ
- 有償(要サポート契約)
- 某アプライアンス並の簡単設定
- DB連携もサポート
- 現在Early Access
- 来年初旬GA
- 目玉機能
  - クローラ、DB連携
  - Click Scoring 関連度フレームワーク
  - アラート
  - REST API。管理機能も
  - セキュリティ
  - スケジュール機能
  - 改良型クエリー・パーサ
- サポート料は未定

2.SI向けパッケージ製品でのSolr利用と事例紹介

　(株)NTTデータ　イントラマート　清彰宏さま [twitter:@seikun]さん

ちょっとだけ会社紹介
- intra-martという開発基盤パッケージ製品を開発
- 以上！
謝辞
- 素敵なTシャツとか配れません
- パンフレット用意してません＞社長すいません
Solrを利用した製品の話( IM-ContentsSearch )
- 標準でインストールされる。Solrは別でセットアップ
- コアAPIはcmecab-java作者の武田さんが作成されたものを使用
intra-martの機能
- ユーザ管理系のマスタとAPI
- 権限管理系のマスタとAPI
- メニュー＆ポートレット管理
- 簡易ばっち機能
- ワークフロー＆BPMエンジン（一番の売り。日本の業務に特化している）
- Server Side JavaScriptを約１２年前から採用（エンジンは昔はiPlanet, 今はRhino)
- グループウェアとしてIntranet Start Packもあります
IM-ContentsSearch
- ワークフロー、スケジュール、ブログ、掲示板、文書管理。これらを全文検索（コンテンツ内容＆添付ファイル）
- 業務データのクローラ作成 -> 全文検索（売れそうなのに売れない・・・）
- コアはひとつだけ
Solrの利用について
- Solr 1.3
- cmecab-java (形態素解析エンジン)
専用スキーマを設定
- 形態素解析フィールド
- コンテンツタイプフィールド。ただの文字列配列フィールド。業務とかグループウェアのどの種類かを判別
- 参照許可・不許可フィールド。ただの(ry。エンタープライズでは重要
- 参照許可・不許可フィールドをフィルタクエリで検索（速度の観点）
- わりと普通につかっている
事例紹介
- 社内の共有ファイル3TBを社内システム(intra-mart)から全文検索したい
- 頑張って上司を口説いた＞「やりましょう」
- Solrでの開発は楽しかった・・・・が苦しい道のりの始まりだった
基本的な設定など
- Tomcat 6.x
- cmecab-java-1.3
- jcifs-1.3.14 ActiveDirectoryだったので
- jvm : -Xmx, -Xms 12G。他はfessを参考にチューニング
形態素解析
- 定期的にipadicのユーザ辞書を更新（品番・品名・特殊な略称などへの対応）
ActiveDirecotyとの権限情報の連携
- jcifsで接続して権限情報を取得
- intra-martのグループに専用ツリーを作成
- ADの権限をバッチで同期
- 検索クエリに反映される
独自でクローラを開発
- 索引化対象の詳細な設定が可能
クロール時の苦労話
- データセンタに共有ディスクはない＞ファイルは拠点ごとにある
- データセンタの外向き帯域は？？>15Mbps
- 対象ファイルは3TB
- 全部クロールするのに２０日の計算（帯域全部使ったとして）
- 100M以上のファイルは文書数の2%なので対象外(データの40％を削減）
- お客様の現地でのクローリング1.2T/1.8Tできた
- のこり４日でクロールできる。＞初期移行可能に
これから
- 本番運用開始から５ヶ月経過
しめ(SIでの)
- 社内用語（商品名、品番、略称）があり、辞書の拡張(形態素解析前提)が必要
- ソリューション化しないと学習コストがたかくなりがち
- 汎用的なスキーマ定義が必要（dynamicFieldを多用するなど)
- スループットや応答時間の要求は低い
- 次回Solr 1.3からSolr 1.4への移行（イントラマートの場合）
Q&A
- Q. 1.8Tのドキュメントでインデックスは？
- A.200Gで済んだ
- Q.差分更新はどうしている？
- A.更新日付をつかってチェックしている。削除には専用のクローラを作っていて存在チェックをしてなければインデックスから消す
- Q. JavaVMのGCは発生しない？
- A. かなり発生している。マルチコアのCPUなので分割GCで対応。クローリング中は80〜90%くらいCPU使う。コンカレントGC使っている

3.Field Collapsing/Result Groupingについて

　(株)シーマーク　大谷純さま

Field Collapsing / Result Groupingの概要
- SQLでいうdistinctやgroup byのような機能
- SOLR-236としてJIRAに登録
- Solr 1.4.1時点で正式にサポートされていない
Field Collapsing(SOLR-236)について
- Solr1.4.1にSOLR-236-1_4_1.patchを適用
- QueryComponentの代わりにCollapseComponentを利用
動作
- 検索にヒットするドキュメントセットを取得
- 取得したドキュメントセットをcollapse.fieldの値をもとにHashMapを利用してグループ化
- 残念ながらtrunkに採用されず。今後メンテナンスされない可能性大
- Distributed Searchを利用できるのはいいところ。Result Groupingは対応していない
- collapse.fieldにmultiValuedのフィールドは指定できない
Result Grouping (SOLR-1682 => trunk) について
- trunkのSolrに利用( Solr 4.0 ) Solr 3.1からいける？
- QueryComponentの機能として実装されているため設定不要
- グループ化を行うために２回の検索
- 検索にヒットするドキュメントセットの中のトップグループのドキュメントを取ってくる
- クエリーの結果が同じもの、関数の結果が同じ物など、いろいろグループ化できる
- troup.query=age[20 TO 39]などができる
- Distributed Searchは未対応
- 総グループ数が不明
- multiValuedフィールドでのグループ化は未対応
- SolrJも未対応
結論
- Result Groupingの実装を待てる場合は待つ
- 今すぐ使いたければField Collapsingを利用
- 利用しない手を考えるのが現状は妥当かも

4.全文検索エンジンgroongaについて

　(有)未来検索ブラジル　末永匡さま [twitter:@tasukuchan]さん

プロローグ
- 人に歴史あり -> groongaにも歴史あり
全文検索エンジンSenna
- 高速なインデックス更新
  - 参照ロックフリーなデータ構造を採用
  - データ更新時に検索を阻害しない
- Twitterなどのリアルタイム検索をターゲット
- 全文検索「ライブラリ」
  - 全文検索用の転置インデックスのみを更新
  - 文書の情報を持たない -> 文書情報を保存する場所が必要
- 文書情報の保存 -> MySQLにやらせれば？
  - MySQL + Senna = Tritonn MySQL組み込みの全文検索演算子を乗っ取る -> SQLを用いて全文検索ができる
- Tritonnのクエリ
  - SQLを用いた柔軟な問い合わせ。並び替え、グループ化など
- Tritonnのよいところ
  - MySQLの資産が使える（人的資産、ソフトウェア資産）
  - SQLを用いた柔軟なクエリが書ける
- Tritonnのよくないところ
  - 特にチューニングしないSolrとTritonnなら、Solrが10倍以上速かった
  - 更新が遅い！
  - 更新時に、検索スループットが悪い
  - 高速な更新をうたっていたのに？？
- Tritonnの仕組み
  - TritonnはMyISAMの性能特性に引きずられた
  - MyISAMはテーブル単位でロックを行う
  - Sennaの構造と矛盾している -> Sennaの設計特性を生かせていなかった
- めざせTritonn越え -> grroonga
groonga
- 文書の情報も保存。単体で全文検索可能。MySQLにもMyISAMにも頼らない -> 高速な更新を活かせる
- 文書情報の保存：カラムごとに保存 key-valueストアを並列に並べたイメージ
- ベクターカラム(multi valued)
  - (例)タグ
- テーブルカラム
  - カラム値として、他のテーブルの行、もしくは配列を保存できる。1対Nのデータを扱える
- 単体で全文検索可能
  - ネットワークサーバとして起動。HTTP GET, memcached, 独自プロトコル、MessagePackも予定
  - HTTP経由では管理ツールが利用出来る（phpMyAdminみたいなもの）
- クエリ言語
  - JavaScriptライクな文法（自前パース）
  - 結果はJSON(P)/XML/CSV
- コマンドライン
- groongaライブラリ。C言語、Ruby
- その他の特徴
  - ドリルダウン(ファセット)
  - ジオサーチ(地理情報検索)
  - サジェスト(検索キーワード候補)
- ドリルダウン
  - 検索結果を特定のカラムでグループ化(GROUP BY)
  - ベクターカラム(multiValued)でも可能
  - 転置インデックスを用いたドリルダウンは実装予定 ( Solrは実装済 )
- ジオサーチ
  - ある地点からの距離計算
  - 矩形内
  - 楕円体としてきちんと計算しているよ！
  - 日本測地系、世界測地系両方に対応（アメリカが中心じゃなくても大丈夫）
  - インデックスを用いて高速に検索可能
- サジェスト
  - ユーザの検索クエリログを収集。変換途中も含めて全て収集
  - 上記ログを解析し、おすすめのクエリを提案
  - 提案「全文検索」-> 「grooonga」
  - 訂正「gloonga」-> 「groonga」
  - 補完「gro」-> 「groonga」
- SQL経由で使いたい
  - groongaストレージエンジン。MyISAMそのものを置換
  - textsearch_groonga　PostgreSQLのインデックス拡張
  - 現在開発中
- 複数プロセスでの利用
  - 複数スレッド・プロセスで共有可能
  - MySQLで更新しつつ、groongaデーモン経由でHTTP検索。参照ロックフリー
- ドキュメント
  - http://groonga.org/docs/
導入事例
- groongaデーモン。某Webサイトでのアイテム検索
- groongaライブラリ(Ruby)
  - 某裏組情報サイトの検索
  - buzztter
groongaとSolr
- １つの判断規準。「ゾウの時間ネズミの時間」
- 技術というのは次の3つの点から評価されなければならない
  - 使い手の生活を豊かにすること -> 実運用に近い環境で所定の性能がでるかどうか
  - 使い手と相性がいいこと -> 実際につかってみててになじむかどうか
  - 使い手の住んでいる環境と相性がいいこと -> Javaで運用しているならLucene/Solrがあっている
まとめ
- groongaは、Sennaの特徴である「高速な更新」を新に実現するために書かれた全文検索エンジンである
- ためしにつかってみて
- 2010/11/29に勉強会やります。次バージョンリリースします
- http://atnd.org/events/9234
Q&A
- Q.KVSの場合シーケンシャルな扱いが苦手。range scanなどはうまくいく？
- A.KVSと固定長と可変長のものをわけている。固定長のものはシーケンシャルな扱いはうまくいく。トランザクションをサポートしていないので、range検索しているときに違うものが入ってくることはある。
- Q.大規模なデータに対するものと、拡張性はどうか
- A. 参照が大規模な場合は、MySQLエンジンをちゃんとかけば、MySQL レプリケーションが使える。更新が多い場合はシェーディングが必要。Spiderストレージエンジンなどと組み合わせて高速な更新ができる想定
- Q. Tokenize機能は？
- A. bi-gramとmecabが入っている。bi-gramで1文字検索も高速にできる

LT: Solrの重複uniqueKeyの扱い

ECナビ春山さん

単一のshardの場合はないが、複数shardの場合で重複する場合がある
QueryComponent.javaで処理されている
- uniqueKeyの重複を検出したら、最初に見つかったものが結果に入る。以降は処理しない
uniqueKeyを重複させたい場合
- 一部の文書だけ頻繁に更新したい
  - 最新情報の反映（価格、在庫など)
- 更新は重たい
- 更新用のデータ数の小さいshardをつくる
- shardの名前の大小で優先順位をつける
- timestampNoフィールドで優先順位をつける
- 作ってみた
  - https://github.com/haruyama/solr
  - 実装はちょー適当