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は共に有力な選択肢。