Mais conteúdo relacionado
Mais de Preferred Networks (20)
2009年4月8日セミナー 2.Sedue新機能
- 3. Sedue
全文検索エンジン
最先端の検索インデックス方式を実装
インデックスとは車で言う所の”エンジン”
速度・マシン台数などを決定づける
リニアなスケールアップ
128スレッド @ Sun UltraSparc T2
容易なスケールアウト
文章容量・クエリ数の増加に柔軟に対応
用途
Web検索, サイト内検索, ブログ検索
企業内文書, 文献検索, 特許
テキストマイニング
3
- 6. システム導入事例:はてなブックマークシステム
(http://b.hatena.ne.jp/search)
インデックス
クローラー
マネージャー
文章登録
ブックマーク
登録
Webからページを取得
本文データ
① オンメモリ検索 保存
文章サイズと同程度の総メモリ量のみで
Web
漏れのない高速な検索が可能
③半リアルタイム(2~3分)
サーチャー
検索用インデックス作成
サーチャー
インデクサ
検索
サーチャー
クエリサーバー インデクサ
インデックス
サーチャー 送信
インデクサ
サーチャーに並列に
検索させて結果を取得
サーチャー 更新量が増加した場合
無停止でインデクサの増減が可能
サーチャー
Sedue
② スケーラビリティ
全文検索システム
文章サイズが増加した場合
無停止でサーチャーの増減が可能
6
- 7. 既存のSedueの利点・欠点
利点
オンメモリでの高速な検索
複数マシンを利用した分散検索
分散検索
ノード追加の容易さ
半リアルタイムインデクシング
欠点
データに対する柔軟性に欠く
あるフィールドに対する“検索”しかできない
• タイトルだけで検索、タイトル+本文で検索
データベースとの統合の難しさ
• 様々なテーブル定義からのデータインポート
検索インデックス手法が固定
ハードウェアの進化への対応が遅れてしまう
7
- 10. 新バージョン: 2つの特徴
汎用性
様々なデータに対する柔軟な検索操作
検索方法・精度の柔軟な調整
様々な条件でのソート・フィルタリング
高速性
物理デバイスに合わせた最適化
SSDに最適化された検索インデックス方式の搭載
カスタマイズコスト、HWコストを劇的に削減
10
- 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
- 17. “検索”と”推薦”の類似性
インデックスにクエリを与えると、結果を返す
検索
入力: 検索クエリ
結果: クエリを含む文章群
例: “検索”を渡すと、”検索”を含む文章群
推薦: データのIDを渡すと、類似するデータID列を返す
入力: あるデータID
結果: 与えられたデータに類似するデータのID列
例: ある本のIDを渡すと、それに関連する本のID列
本質的に統合可能ではないか?
データに対してインデックスを作成し、そこから情報抽出
17
- 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
- 23. 新旧ソフトウェアスタック
サポートするインデックス方式
転置ファイル, N-Gram, CSA
SSD向けインデックス方式 (次セッション)
旧 新
分散クエリ 分散クエリ
スコアリング カラム指向アーキテクチャ
推薦
CSA CSA SA 転置ファイル, N-Gram
エンジン
DRAM DRAM SSD HDD
23
- 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
- 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
- 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
- 35. Sedueの実現する方向性
構造的なデータ
大規模データ処理
Enterprise Search
データへの
アクセシビリティ
リアルタイム性
Sedue
データベースとの
統合
Web Search ログ分析
多種多様なデータ
フォーマットへの対応
可用性
検索エンジンの概念を汎用化し、RDBMSのような
ミドルウェアとして確立させる
35
- 37. Sedueロードマップ
PFIテクノロジの
統合
•データセンタ向け検索
ソリューションの構築
•統計データの可視化
•大規模分散環境向け
•管理ウェブアプリケーションの整備 •ユーザーフィードバック・
クラスタウェア
クリックログからの情報抽出
•パーソナライゼーション
•画像認識の組み込み
多様な分散
管理機能の拡充
アーキテクチャへの対応
37
- 38. まとめ
Sedue新バージョン紹介
柔軟性
カラム指向アーキテクチャ搭載
推薦エンジンの統合
高速性
SSD向け検索インデックス方式の搭載
Sedueに情報抽出技術の全てを集約して行く
画像・動画なども
次のセッションはSSDを使用した検索エンジン
の内部アルゴリズム等を紹介します
38