ichii mysql-osc2011tokyofall

MySQL で全文検索とか

2011/11/20 (sun) at OSC2011 Tokyo/Fallいちいたかし / @ichii386

Sunday, November 20, 11

自己紹介• いちいたかし / @ichii386

• 興味があるもの• MySQL, Solaris, ZFS, Debian, php, awk, rsync, InfiniBand, etc.

• ニガテなもの• perl, 魚介類

• グリー株式会社で働いてます• ふだんはログ屋さん


はじめに

• MySQL つかっていますか?

• 全文検索つかっていますか?


MySQL について• オープンソースの RDBMS

• 最近は公式にも ‘‘NoSQL に対応します’’

• 汎用的な「データを保存する場所」

• 膨大な運用ノウハウの蓄積

• replication, backup, etc.


余談: RDBMS vs NoSQL• そんな戦いはほんとうに存在するの?

• どちらもデータを保存する場所

• RDBMS

• JOIN できる

• (比較すると) 遅い

• NoSQL

• Primary Key もしくは Hash くらいしかインデックスがない

• チョー速い


データベースのおしごと

• データを保存します

• インデックスを作ります

• 条件に応じて必要なデータを探してきます


インデックスとは

• 検索を速くするためのもの

• B-tree とか hash とか suffix array とか

• 見出し。索引。

• 本の最後についてるやつですね


検索とは• 「情報検索」

• ユーザの情報要求を満たすためのなんたらかんたら

• 図書館の時代から長い歴史がある

• MySQL みたいなデータベースが対象とする検索

• 必要なデータがあることがわかっていて、それを探してくる

• SELECT blog_text FROM blog_data WHERE blog_ id = 1

• もしかしたら無いかもしれないけど、「あるとすればこうだろ」という条件を渡す

• SELECT blog_text FROM blog_data WHERE user_id = 1


データがあるに決まっている検索

• アプリケーションの設計がバグってなければ、あるはず。

• Primary Key による検索や NoSQL 的な使い方にむいてる


データがあるかわからない検索

• ユーザが自由に入力するような場合

• たとえば、全文検索


何を探したいのかよくわかってない検索

• いちばん大変。

• 「もしかして」

• 関連検索

• あまり MySQL とかのレイヤが目指すところではない


ちかくのスタバどこ?


さまざまなやりかた• ‘‘ナイーブ’’ な方針

• 見つかるまで歩き続ける

• 前計算機世代

• そのへんの人に聞く

• 前 Web 世代

• 電話帳を探す

• 最近の若者

• ググるでしょJK

当たり外れが多い司書の時代

永遠に時間をかければ「絶対に見つかる」

閉店してたらどうする?

ディレクトリ型

GOOD!


「検索が速い」は本質的に重要

• いや、だって、遅くていいなら、毎回

grep すりゃいいじゃん！

• LIKE ‘%hoge%’ でよくね?


全文検索とは• full-text search

• すべての文から検索すること

• 一般には

• ある文の集合から、検索語を部分文字列として含む文の部分集合を求める


全文じゃない検索とは• 例えば、本の索引• えらい編集者さんがうまいこと作ってくれる

• ブログ

• 著者や読者が決めたタグで検索できる

• えらい人が考えた語句に一致しないと探せない• 表記ゆれ: 仮名/漢字、活用

• 本文に書いてあるとは限らない場合: 「これはひどい」


高速に、全文から、好きな語句で検索するために

• 文を検索語句に分割する• n-gram, 形態素解析 (mecab)

• 分割した語句を文書IDと位置情報とセットで保存

• 転置インデックス (inverted index), suffix array

• 検索するとき• 検索語を必要に応じて分割し、インデックスから一致するところを探す


インデックスが持つ情報• じつは、元の文章を復元できるくらいの情報を持っています

• 元の文章の全ての部分文字列を含む• スニペットが表示できる

• インデックス自体がデータ保存領域になっている• データベースの容量も削減できる• 一見よさそうに思えるんだけど...


RDBMSと全文検索の関係• 「検索したい！」という意図では似ている• 同じように SQL 使いたいし、JOIN もしたい

• しかし、実際はかなり仕組みが違っている

• いわゆる「データベース製品」と「全文検索ソリューション」が別ラインになりがちな理由のひとつ。

• データの2重化、整合性の問題

• 運用ノウハウの分散、コスト


MySQL での全文検索• MyISAM ストレージエンジン (昔から)

• 日本語非対応

• Tritonn (MySQL-5.0)

• 全文検索エンジン Senna による MyISAM の拡張

• MySQL-5.0 しばり, まだ使っている人多そう

• mroonga (MySQL-5.1 以降, MariaDB)

• 全文検索対応の groonga をつかった MySQL のストレージエンジン

• Tritonn の後継として開発されている

• InnoDB FTS (MySQL-5.6)

• MySQL Labs で公開中


MySQL のストレージエンジン

• (RDBMS としての) MySQL の特徴のひとつ。

• テーブルごとに、プラグインでデータ保存領域の実装を変えられる

• MyISAM, InnoDB, Memory, Blackhole など

• MySQL デーモンは SQL を理解してストレージエンジンに処理を橋渡し

• ストレージエンジンがどうやってデータを保存するか、どういうインデックスを内部で持つかは自由

• テーブル間の JOIN もストレージエンジンによらず可能

• ...のは理想だけど、実用的に動かすのはけっこう大変


けっきょく、MySQL なら• ストレージエンジンが自由に選べる (作れる)

• なので、仕組みがちょっと複雑な全文検索だって、作ればふつうに使える

• 使い方は今までの MySQL と同じで楽ちん

• Replication だっておなじ


今後の展望• 10月にいろいろイベント行って来ました

• Oracle Open World 2011 @SF

• MySQL 自体の発展のいきおい

• Percona Live 2011 @London

• Oracle をやめてしまった元 MySQL の開発者たち

• ストレージエンジンビジネスが盛り上がるかも?

• Hadoop とか MongoDB とか「データを置く場所」はいろいろありますが、 MySQL はあいかわらずがんばっています


今後の展望 (2)• 全文検索じたいの必要性はそう変わらないでしょう• MySQL の仕組みとして全文検索も対応しやすい

• 海外でどんなに盛り上がっても、日本語対応は日本発のほうが強いです

• とくに形態素解析など、日本語固有の問題に関連しがち

• なので、日本が頑張れる分野だと思います


個人な本命• じつのところ、まだ Tritonn から脱出できていません

• 某G社の一部システムでの話

• mroonga がんばってください

• 現状では、まだある程度の量のデータを入れるには、運用に特殊能力が必要です

• OSC.DB でも発表があったそうです


• ありがとうございました

• 謝辞

• 本発表は groonga の開発者でもある森大二郎氏の『検索エンジンはなぜ見つけるのか』（日経BP社）にインスパイアされました。


ichii mysql-osc2011tokyofall

Technology