Solr勉強会に行ってきました[solr][ecnavi][mapion][recruit]

Solr勉強会に行ってきました。
ECナビさんの事例の最後の質問付近から参加させていただきました。

Solr(ソーラー)

全文検索エンジンライブラリLuceneをベースに、管理画面やキャッシュ機構を取り入れたアプリケーション。

各事例紹介

ECNavi
  • parasearch商用サーチエンジンを使っている
  • ECTokenizerという独自Tokenizerで型番等のゆれを吸収している
  • WebServer pound
リクルート
  • スピーカー
    • 植野さん
    • リクルートの人
    • 開発、テスト
    • MITの人
    • 全社のインフラ
    • 事業
      • 営業、企画は社内
      • 技術は大手SIerさん
      • 全社的なインフラとかはMIT
  • 某サイト (新作hotpepper?がSolrつかってる？)
    • 25-280QPS
    • ドキュメント150万
    • 10分間隔で差分更新
  • Fastじゃなくて大丈夫?
    • Solrは5台,LBで負荷分散
    • 更新は全台
    • 大規模サイトの場合は5台+スタンバイ5台
  • 開発どうするのか？
    • Solrクライアントを積極的に作る(学習コストを下げる)
    • Seaser FWになじむように
    • Excelで定義すると　設定
    • O/RMapper的にEntityクラスを自動生成
  • Solrをどう使っているか?
    • Solr .3+拡張
    • 形態素:Mecab
    • N-gram:Ngram-Tokenizer
    • ある一定数以上のSolrが死んだらupdateしない
  • Solrの売り込み
    • フリーワード検索
    • ファセット
  • 今後展開
    • Solr UIレベルの研究開発
    • ほぼ、リアルタイム検索
  • 質問
    • 相乗りのときは？
      • 1つのサービスに1tomcat
    • クライアントを実装する苦労
      • Solr知らない人向けに使いやすいように
      • まったくSolrを意識せずにDB同様に使う
      • Solrの特長意識しないで実装してしまう
      • 開発チームにSolrのノウハウがたまらない
    • サーバースペック
      • RAM 16G
      • CPU Quad core x2
      • IBM製サーバを使っている
    • リアルタイム更新で想定しうる問題
      • キャッシュをupdateしないとだめ
      • Solrのインデックスがmemcached上においてある?
      • プロトタイプ
      • レイテンシ(遅延:一桁秒)を目標
マピオン
  • スピーカー
  • つかっているところ
    • 緯度経度周辺検索
    • フリーワード検索
  • Solr導入の理由
    • MySQL5.0+Sennaを使っていた(マピオン電話帳)
    • 負荷が高い(重い)
    • 更新が厳しい
    • 企画者がやりたいことが全てSolrでいける
  • Spec
    • 1MQuery/day
      • 30% 地図名
      • 70% フリーワード
    • 電話帳
      • 9M
    • ランドマーク、住所
      • 0.4M
  • データ更新
    • 電話帳は差分更新
      • 一日２回
      • 20時間かかる
      • 他のデータと結びつける
    • それ以外は更新頻度に応じて
  • 構成図
    • index x 1
    • search x 8
    • shards x 3
  • Mapion 拡張
    • 周辺検索
    • 緯度経度、半径n km,中心から距離が近い順に出す
      • 円が入る正方形をエリアとして出す(円よりも正方形で考えたほうがやりやすい)
      • 距離計算
    • 緯度経度にメモリ上にキャッシュ
    • あらかじめ緯度経度をピクセル座標に変換したものを持っておく
    • 拡張コンポーネントとして実装
    • 住所の番地データは件数が多いため、Solrに入れてない
    • apache-solr-core-1.3.0.jar
      • 1ホストに対して20コネクションしかはれない仕様だったがソースをいじってコンパイル,パラメータで渡せるように改造
  • Tokenizer
  • 質問
    • 1box検索で地名みたいなキーワードがあったらどうする？(店名に場所とか駅名があったら)
    • 位置的なクエリかどうかを判定している
      • 駅とか、住所とか、スポットとか
      • ひとつを住所として判断することもできるが、大手町とカフェだったら"大手町"を住所として周辺検索することも可能
      • 東京の大手町と判断しちゃって良い?
    • Tokenizerハイブリッドのアイデア
      • まだありません

ジオコーダーの話(LT)

  • スピーカー
    • 西岡さん(Y!の人)
    • ジオコーダーの開発
    • 住所検索
    • ランドマーク検索
    • 郵便番号検索
  • 渋谷xラーメン
    • 渋谷を住所として、周辺検索
  • 5000万件のデータ
  • 100万件はリアルタイム更新
  • 住所は一ヶ月一回
  • ジオコーダー(前処理 同義語)
  • ジオコーダー(表記ゆれ)
    • 六本木6-10-1
    • 六本木六丁目１０-1
  • ジオコーダー(バースト word)
  • ジオコーダー(かな漢字変換)
    • roppongi -> 六本木
    • APIで公開中
  • ジオコーダー(ソート条件お

EC2+OpenSocial+Android(LT)

Solr@twitter検索(LT)

  • スピーカー
    • 兼山さん
  • http://pcod.noip.or/yats/
  • 3億のつぶやきを収集
  • 日本語ユーザの5500万つぶやきを検索
  • 60秒でindex
  • 50万pv/月
  • 250万query
  • 日付でソート
  • 更新頻度たかい
    • インデックス更新にかかる時間を得荒らす
  • 同じquery
    • キャッシュ
  • queryの重さが均一じゃない
    • 重いクエリをはじく
  • linkedin ゾーイを使う
  • 更新専用のSolrを作る
一日分 40万 100秒 数秒
一ヶ月 1000万 12時間 数十秒
    • キャッシュヒット率64%(5時間)->77%(一週間)
    • 検索時間 が半分に
  • 遅いクエリをはじく
    • 50ページ目
    • 複雑な条件式
  • SSDにしたら7倍くらい高速くなった

Solr+SSD(LT)

  • スピーカー
    • 春山さん