mysqlとgroonga による...
TRANSCRIPT
MySQLとgroongaによる 高速日本語全文検索
未来検索ブラジル
講義内容
• 全文検索エンジンとは? – DBMSとの違い – 要件上の特徴 – 実現方式 – トレードオフ
• InnoDB FTSとは? – 実現方式・特徴
• groonga/mroongaとは? – 実現方式・特徴
• まとめ
全文検索エンジンとは?
• 文書集合の中からユーザが指定したキーワードにマッチする文書を見つけ出す
• 対象データは文字・数値情報がメイン
• 高速に検索結果を返すことが求められる
• ⇒ DBのやっていることと大差ない?
DBMSとの違いは何か?
• 大量のデータから検索するという点では同じ
• なぜ専用ソフトウェアを使う場合が多いのか? (DBMSの中だけで完結できたら便利なのに・・・)
• ∵ 要件がやや特殊だから
全文検索エンジンの特徴的な要件
1. 正解が自明でないクエリに応える
2. 多様なパタンのクエリに応える
特徴的でない要件
3. 新鮮な情報も検索できる
1. 正解が自明でない
• 正解 = ユーザが求めている文書
• 正解 ≠ 指定されたキーワードを含む文書
• キーワードを含んでいても正解とは限らない
– 「民主党」 ⇒ 「自由民主党」
• キーワードを含んでいない正解も存在する
– 「自民党」 ⇒ 「自由民主党」
2. クエリのパタンが多様
• クエリ: 自然言語で表されるキーワード
• 自然言語: 単語の数は有限だが、単語の組合せで無限の事象を表現可能(生成性)
• 新たな言葉の組合せにも柔軟に応える必要がある
• 表記や表現のゆらぎに対応し、かつ高速に検索できるデータ構造が必要
検索精度
• 適合率: ノイズの少なさ =
• 再現率: 検索漏れの少なさ =
文書集合
真の正解集合 出力した結果
検索精度
• 100%正解を返すのは不可能という前提に立っている
• 計算コストをかけることで正解に近づけるが、それでも完全な正解は返せない
– DBの発想: 正解を返すことを前提として、いかに計算コストを下げるか
–検索エンジンの発想: 現実的な計算コストの範囲で、いかに精度を高めるか
3. 新鮮な情報も検索できる
• 更新したデータがすぐに検索できるということ
• DBMSの世界では当たり前
• 検索エンジンの世界では当たり前でなかった
• 近年需要が増えてきた“リアルタイムサーチ”
• この要件が、DBMSと検索エンジンの距離を狭める契機となっている
検索エンジンの特徴的な要件
• 1. 正解が自明でないクエリに応える
• 2. 多様なパタンのクエリに応える
• そんなに特殊なことなのか?
• RDBのアプリケーションとして実装できないのか?
検索エンジンの実装
• RDBのAPとしての実装を仮定してみる
• テーブルによって必要なデータ構造を表現
• メリット: RDBのトランザクション機能を享受可
• 一枚岩(monolithic)なアーキテクチャ
方式1: 逐次検索
• 文書をそのまま格納し、like演算子で検索する
• 長所: 更新が高速(リアルタイムサーチ)
• 短所: 全データを走査するため速度が遅い
文書番号 文書内容
1 私はその人を常に先生と呼んでいた。
2 「ではみなさんは、そういうふうに川だと
3 私がウスウスと眼を覚ました時、こうし...
4 私は、その男の写真を三葉、見たことが
方式2: 転置索引
• 単語をkeyとする表を準備する
• 長所: 検索が高速
• 短所: 検索精度が不十分
単語 文書番号
私 1
私 2
私 3
私 4
出現回数
2699
12
1143
43
検索精度の追求
• 複数の単語で検索するとき、それらが離れた位置に現れる文書よりも、近い位置に現れる文書に高いスコアを与えたい
• 複数の単語からなるフレーズや複合名詞で検索するとき、それらが隣接して現れる文書に高いスコアを与えたい
方式3: 完全転置索引
• 出現位置ごとにレコードを作る
• 長所: 高精度な検索が実現可能 • 短所: テーブルのサイズが肥大化する
単語 文書番号
私 1
私 1
私 1
私 1
出現位置
1
77
91
173
さらなる検索精度の追求
• 単語の境界が一意に特定できない場合
– ここではきものをぬいでください
– ここ/では/きもの/を/ぬいで/ください
– ここ/で/はきもの/を/ぬいで/ください
• 誤った単語で索引を作ると検索漏れの原因となる
単語vs文字要素(ngram)
原文: 私はその人を常に先生と呼んでいた。
• 単語単位 私/は/その/人/を/常に/先生/と/呼ん/で/い/た/。 (13)
• 文字(unigram)単位 私/は/そ/の/人/を/常/に/先/生/と/呼/ん/で/い/た/。 (17)
• 文字要素(bigram)単位 私は/はそ/その/の人/人を/を常/常に/に先/先生/生と/と呼/呼ん/んで/でい/いた/た。/。 (17)
• 単語索引: 適合率が高い 民主党 ⇒ 自由民主党 のようなケースを防げる
• 文字要素(ngram)索引: 再現率が高い 単語境界が特定できなくても、 きもの⇒はきもの のようなケースで検索漏れを起こさない
方式4: 完全転置索引(文字要素単位)
• 文字(文字要素)単位にレコードを作る
• 長所: より高精度な検索が実現可能 • 短所: テーブルのサイズがさらに肥大化する
文字要素 文書番号
私は 1
私は 1
私は 1
私は 1
出現位置
1
91
203
270
方式5: 圧縮完全転置索引
• 複数レコードをまとめて圧縮する
• 長所: 高精度な検索が実現可能
• 短所: 更新速度が低下する
単語or文字要素 文書番号と出現位置の圧縮イメージ
私は
私は 1 1 91 203 270
単語or文字要素 文書番号 出現位置 出現位置 出現位置 出現位置
私は 1 1 90 112 67
⊿ ⊿ ⊿
可変長符号化
各方式の比較 検索性能
更新性能 キャパシティ
逐次検索 転置索引 完全転置索引
完全転置索引(文字要素単位) 圧縮完全転置索引
トレードオフ
• 以下の3つを同時に満足するのは難しい
– 検索性能(検索精度および検索速度)
– キャパシティ(検索対象文書の許容量)
– 更新速度性能
• 最近のプロダクトはどのようにこの問題に向き合っているのか
InnoDB FTSとは?
• MySQL5.6.4で追加された全文検索機能
• 検索性能と更新速度の両立を重視
• InnoDBのテーブルを用いて実装 (更新処理の一部を除いてmonolithic)
• バイト単位で圧縮した完全転置索引
• 更新情報は一旦バッファ(index cache)に貯めておいて、一杯になったらフラッシュする
• InnoDB専用
mroongaとは?
• groongaのMySQLインタフェース • groongaとは:
– LGPL2.1で配布される検索エンジン – 独自のカラムストアによって構成 – 検索性能と更新速度の両立を重視
– 更新情報はスキップリストによるバッファに貯めておいて、一杯になったらフラッシュする
– ビット単位で圧縮した完全転置索引
• mroongaは: – ストレージエンジンとして提供 – 全てのストレージエンジンに全文検索機能を提供
mroongaのアーキテクチャ
任意のストレージエンジンに全文検索機能を付加可能
方式面から見た比較
検索性能
更新性能 キャパシティ
InnoDB FTS mroonga
• InnoDB FTS: BER圧縮(圧縮・伸張どちらも高速だが圧縮率は低い)
• mroonga: PForDelta圧縮(伸張が高速。高い圧縮率)
まとめ
• 検索エンジンは通常のDBの検索処理に比べて特殊な要件に対応するため、専用のデータ構造を必要とする。
• エンジンの設計にはトレードオフとなる要因があり、バランスの取り方によってエンジンの特性に差が出る。
• DBと統合された実用的な検索エンジン製品が作られている。InnoDB FTSとmroongaは共に有力な選択肢。