2009年4月8日セミナー 2.Sedue新機能
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

2009年4月8日セミナー 2.Sedue新機能

on

  • 4,970 views

2009年4月8日開催のセミナー「Extreme Search! 次世代検索エンジンSedue 24が実現する驚異のパフォーマンス」における、セッション「全文検索エンジンSedue ...

2009年4月8日開催のセミナー「Extreme Search! 次世代検索エンジンSedue 24が実現する驚異のパフォーマンス」における、セッション「全文検索エンジンSedue ~新機能の紹介~」の配布資料。

Statistics

Views

Total Views
4,970
Views on SlideShare
4,185
Embed Views
785

Actions

Likes
5
Downloads
61
Comments
0

5 Embeds 785

http://preferred.jp 752
http://mt.kzk9.net 14
http://www.slideshare.net 12
http://okyuu.com 5
http://stage.preferred.jp 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

2009年4月8日セミナー 2.Sedue新機能 Presentation Transcript

  • 1. 全文検索エンジン Sedue ~新機能の紹介~ (株)プリファードインフラストラクチャー 最高技術責任者 太田一樹 1
  • 2. アジェンダ 全文検索エンジン Sedue(セデュー)紹介 製品概要 導入事例 新バージョンの紹介 カラム指向アーキテクチャ 検索と推薦の統合 SSD向けインデックス方式の搭載 2
  • 3. Sedue 全文検索エンジン 最先端の検索インデックス方式を実装 インデックスとは車で言う所の”エンジン” 速度・マシン台数などを決定づける リニアなスケールアップ 128スレッド @ Sun UltraSparc T2 容易なスケールアウト 文章容量・クエリ数の増加に柔軟に対応 用途 Web検索, サイト内検索, ブログ検索 企業内文書, 文献検索, 特許 テキストマイニング 3
  • 4. 弊社導入実績・取引実績 株式会社エフルート http://froute.jp/ 携帯検索サービスへの製品提供ならびにLLP設立 400万UU / 月 はてな株式会社 http://b.hatena.ne.jp/ 『はてなブックマーク』への製品提供ならびに戦略的提携 約1300万URLの全文検索 某大学・研究機関 ゲノム解析研究への製品提供 ゲノム塩基配列上の高速曖昧検索 4
  • 5. Sedueの性能 OSS検索エンジンとの比較 インデックス構築速度 インデックスサイズ 検索スループット 少ないインデックスサイズでオンメモリ検索を実現 検索スループットも他のエンジンを圧倒 5
  • 6. システム導入事例:はてなブックマークシステム (http://b.hatena.ne.jp/search) インデックス クローラー マネージャー 文章登録 ブックマーク 登録 Webからページを取得 本文データ ① オンメモリ検索 保存 文章サイズと同程度の総メモリ量のみで Web 漏れのない高速な検索が可能 ③半リアルタイム(2~3分) サーチャー 検索用インデックス作成 サーチャー インデクサ 検索 サーチャー クエリサーバー インデクサ インデックス サーチャー 送信 インデクサ サーチャーに並列に 検索させて結果を取得 サーチャー 更新量が増加した場合 無停止でインデクサの増減が可能 サーチャー Sedue ② スケーラビリティ 全文検索システム 文章サイズが増加した場合 無停止でサーチャーの増減が可能 6
  • 7. 既存のSedueの利点・欠点 利点 オンメモリでの高速な検索 複数マシンを利用した分散検索 分散検索 ノード追加の容易さ 半リアルタイムインデクシング 欠点 データに対する柔軟性に欠く あるフィールドに対する“検索”しかできない • タイトルだけで検索、タイトル+本文で検索 データベースとの統合の難しさ • 様々なテーブル定義からのデータインポート 検索インデックス手法が固定 ハードウェアの進化への対応が遅れてしまう 7
  • 8. 例: 多彩な検索条件 (livedoorグルメさん) 8
  • 9. Sedue 新バージョンのご紹介 9
  • 10. 新バージョン: 2つの特徴 汎用性 様々なデータに対する柔軟な検索操作 検索方法・精度の柔軟な調整 様々な条件でのソート・フィルタリング 高速性 物理デバイスに合わせた最適化 SSDに最適化された検索インデックス方式の搭載 カスタマイズコスト、HWコストを劇的に削減 10
  • 11. 新旧ソフトウェアスタック比較 カラム指向アーキテクチャ 複数の検索方式、推薦エンジンを統合 コスト Sedueという単一のシステムで検索と推薦を導入可能 削減 SSD向けインデックスエンジン 数十GB単位のデータでも1つのSSDドライブで処理可能 旧 新 分散クエリ 分散クエリ スコアリング カラム指向アーキテクチャ 推薦 CSA CSA SA 転置ファイル, N-Gram エンジン DRAM DRAM SSD HDD 11
  • 12. カラム指向アーキテクチャ (1) スキーマ定義 データに対して、RDBMSのようなスキーマを定義 型: int, string, double, datetime, etc. インデックス定義 どのスキーマの列に対して検索を行うか? どのインデックス方式を用いるか? 転置ファイル, n-gram, 接尾辞配列、etc インデックスに対して検索クエリを投げる 事で、データに対する検索が可能 12
  • 13. カラム指向アーキテクチャ (2) インデックス 定義 検索1 検索2 参照 ID Title Content Date タイトル1 内容1 ID123 2009/03/10 (値の参照) (タイトル+本文検索) (本文のみの検索) 転置ファイル N-Gram タイトル2 内容2 ID124 2009/03/11 タイトル2 内容2 ID125 2009/03/11 フィルタ タイトル2 内容2 ID126 2009/03/11 同義語拡張, ソート, 条件式, ドリルダウン, etc. フィールド定義 ユーザー 13
  • 14. カラム指向アーキテクチャ (3) スキーマ例 ID: string TITLE: string CONTENT: string DATE: datetime インデックス例 Search_All: インデックス方式A(TITLE, CONTENT) Search_Content: インデックス方式B(CONTENT) クエリ例 (Search_All: テスト) (Search_Content: テスト)?DATE>20090312 (Search_Content: テスト)?DATE>20090312?desc=DATE 14
  • 15. 推薦技術との統合 15
  • 16. 推薦技術とは? あるデータについての関連情報を推薦 この本を買っている人はこんな本も買っています この記事に似ているのはこの記事です 実現方法 全てのデータに対してインデックスを作成 インデックスを利用し、関連度を計算 関連度の高いアイテムを抽出 詳しくは最後のセッション 16
  • 17. “検索”と”推薦”の類似性 インデックスにクエリを与えると、結果を返す 検索 入力: 検索クエリ 結果: クエリを含む文章群 例: “検索”を渡すと、”検索”を含む文章群 推薦: データのIDを渡すと、類似するデータID列を返す 入力: あるデータID 結果: 与えられたデータに類似するデータのID列 例: ある本のIDを渡すと、それに関連する本のID列 本質的に統合可能ではないか? データに対してインデックスを作成し、そこから情報抽出 17
  • 18. 新旧ソフトウェアスタック カラム指向アーキテクチャ層で、検索と推 薦を統合的に扱えるようにした 旧 新 分散クエリ 分散クエリ スコアリング カラム指向アーキテクチャ 推薦 CSA CSA SA 転置ファイル, N-Gram エンジン DRAM DRAM SSD HDD 18
  • 19. カラム指向アーキテクチャ: 推薦との統合 インデックス 定義 検索 推薦 参照 ID Title Content Date タイトル1 内容1 ID123 2009/03/10 (値の参照) (コンテンツ推薦) (タイトル+本文検索) タイトル2 内容2 ID124 2009/03/11 フィルタ タイトル2 内容2 ID125 2009/03/11 ソート, 条件式, ドリルダウン, etc. タイトル2 内容2 ID126 2009/03/11 フィールド定義 ユーザー 19
  • 20. カラム指向アーキテクチャ (検索 & 推薦) スキーマ例 ID: string TITLE: string CONTENT: string DATE: datetime インデックス例 Search_All: 検索用インデックス(TITLE, CONTENT) Recommend_Content: 推薦用インデックス(CONTENT) クエリ例 (Search_All: テスト) (Recommend_Content: ID124) (Recommend_Content: ID124)?DATE>20090401 (Recommend_Content: ID124)&(Search_All: 野球) 20
  • 21. 何が嬉しいか? 検索と推薦で別々のシステム導入をしてい た部分をSedueのみで行える データに対するあらゆる操作を統合できる 圧倒的な柔軟性 データ == テキストデータとは限らない 類似画像・類似動画 画像、動画に対するインデックス作成手法も研究中 21
  • 22. 新バージョンのサポートする 検索インデックス方式 22
  • 23. 新旧ソフトウェアスタック サポートするインデックス方式 転置ファイル, N-Gram, CSA SSD向けインデックス方式 (次セッション) 旧 新 分散クエリ 分散クエリ スコアリング カラム指向アーキテクチャ 推薦 CSA CSA SA 転置ファイル, N-Gram エンジン DRAM DRAM SSD HDD 23
  • 24. 転置ファイル Inverted File Indexing 各単語毎に、どの文書に出現したかを記録 東京 …. 10 15 16 20 21 22 東寺 10 15 文書番号を記録 長所 シンプル、速い、分散処理しやすい 短所 検索漏れが生じる フレーズ検索が苦手 24
  • 25. N-gram方式 長さN(=2,3)の部分文字列を単語とみなし転 置ファイルを構築 東京都 0 102 京都庁 1 東京都庁に今日… 都庁に 2 150 庁に今 3 出現位置を記録 長所 漏れがない、シンプル 短所 索引が大きい 非常に遅くなる場合もある 25
  • 26. 接尾辞配列 Suffix Arrays (SA) 全接尾辞を辞書式順序でソートした結果 例:dabraを検索する 11 $ abracadabra$ 1. 配列 SA の大きさは 11 なので配列インデックスの 中心値 5 から検索 10 a$ 2. SA[5] = 8 、この 8 は “abracadabra” の “bra” の 0 abracadabra$ 7 abra$ 出現位置を指している 3. 検索クエリの quot;dabraquot; と quot;braquot; を比較すると 1 bracadabra$ 0 abracadabra$ quot;dabraquot; の方が辞書式順で大きい 4. よって検索範囲は SA[5] から SA[11] の間に絞り 2 racadabra$ 3 acadabra$ 込まれる 5. SA[5] と SA[11] の間 → SA[8] = 6 3 acadabra$ 5 adabra$ 6. SA[8] = 6 の 6 は “abracadabra” の dabra に 辞書式 8 bra$ 4 cadabra$ 一致。よって dabra の出現位置は 6 と判明 順序 5 adabra$ 1 bracadabra$ ソート 6 dabra$ 4 cadabra$ 7 abra$ dabra = dabra$ 6 dabra$ ・・・ 出現位置(先頭位置からのオフセット) 長所 漏れがない、どんなクエリでも高速 短所 索引が大きい、構築に時間がかかる 26
  • 27. 圧縮接尾辞配列 接尾辞配列の機能はそのままに、コンパクトに保存(テキス トサイズと同程度) 接尾辞配列をさらに変換し圧縮 形態素解析の解析漏れも解決 検索対象テキスト自身の情報も同時に保持 スニペットも索引から復元できる 普通のPC上でヒトゲノムやwikipedia全部(日本語+英語)が 高速に検索できる! 実装は難しい ⇒圧縮接尾辞配列を搭載した初の商用検索エンジン 27
  • 28. サポートしているインデックス方式 漏れの フレーズ 検索 構築 サイズ HDDに ない検 検索 速度 速度 置ける 索 × × ○ ○ △ ○ 転置ファ イル ○ △ ○ ○ △ △ N-gram 接尾辞配 ○ ○ ◎ ○ × × 列 ○ ○ ◎ ○ ○ × CSA 28
  • 29. インデックス方式の選択 求められる要件・デバイスに合わせて選 択を行う必要がある 単位容量あたりの価格はリーズナブル。 また、システムとのインターコネクトの面からもスケーラブル。 一台のサーバーに多数搭載することが可能である (次セッション)。 SA N-gram 圧縮接尾辞 SSD HDD メモリ 検索アルゴリズムは本質的にユーザークエリ集合に 対してランダムなのにかかわらず、ランダムリード の性能が低い。 ランダムアクセス性能は高いものの、システムに搭 載できるモジュール数は制限されている。また、容 量当たりの単価は高価。 29
  • 30. 各ストレージデバイスの特性 速度・容量共に 停滞の感有り ブログ Web検索 社内文書 ~300G 次のセッション! EC 容量 HDD 速度・容量共に 向上中 ~30G SSD DRAM ~ 5 qps ~ 100 qps パフォーマンス 30
  • 31. 実際のシステム構成例 31
  • 32. 例1: ニュースサイト インデックス 定義 内容 更新日時 検索 推薦 参照 記事ID タイトル 水嶋ヒロ 内容1 ID123 2009/04/03 (値の参照) (記事検索) (関連記事推薦) ミサイル 内容2 ID124 2009/04/04 フィルタ イチロー 内容3 ID125 2009/04/05 更新日時でのソート・フィルタリング等 日銀総裁 内容4 ID126 2009/04/05 フィールド定義 ユーザー 32
  • 33. 例2: SNS インデックス 定義 プロフ 検索 推薦 参照 人ID 名前 年齢 西川 内容1 ID123 27 (値の参照) (コンテンツ推薦) (プロフィール検索) 徳永 内容2 ID124 27 フィルタ 岡野原 内容2 ID125 27 年齢でのソート・フィルタリング等 田中 内容2 ID126 27 フィールド定義 ユーザー 33
  • 34. これからの開発ロードマップ 34
  • 35. Sedueの実現する方向性 構造的なデータ 大規模データ処理 Enterprise Search データへの アクセシビリティ リアルタイム性 Sedue データベースとの 統合 Web Search ログ分析 多種多様なデータ フォーマットへの対応 可用性 検索エンジンの概念を汎用化し、RDBMSのような ミドルウェアとして確立させる 35
  • 36. Sedueの最終目標 あらゆるデータからの効率的な情報抽出 情報の蓄積から抽出への流れを加速させるエンジン 情報の抽出 Sedue マルチ ファイル データベース メール ・・・ Web メディア サーバー 統合 システム 36
  • 37. Sedueロードマップ PFIテクノロジの 統合 •データセンタ向け検索 ソリューションの構築 •統計データの可視化 •大規模分散環境向け •管理ウェブアプリケーションの整備 •ユーザーフィードバック・ クラスタウェア クリックログからの情報抽出 •パーソナライゼーション •画像認識の組み込み 多様な分散 管理機能の拡充 アーキテクチャへの対応 37
  • 38. まとめ Sedue新バージョン紹介 柔軟性 カラム指向アーキテクチャ搭載 推薦エンジンの統合 高速性 SSD向け検索インデックス方式の搭載 Sedueに情報抽出技術の全てを集約して行く 画像・動画なども 次のセッションはSSDを使用した検索エンジン の内部アルゴリズム等を紹介します 38