全文検索エンジンMroonga_エンジニア勉強会20140418

2,237 views
2,062 views

Published on

4月18日のエスキュービズム社内勉強会で使用した資料になります。

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,237
On SlideShare
0
From Embeds
0
Number of Embeds
80
Actions
Shares
0
Downloads
14
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

全文検索エンジンMroonga_エンジニア勉強会20140418

  1. 1. 全文検索エンジン mroonga 1
  2. 2. そもそも全文検索とは? 全文検索(ぜんぶんけんさく、Full text search)と は、コンピュータにおいて、複数の文書(ファイル) から特定の文字列を検索すること。「ファイル名検索」 や「単一ファイル内の文字列検索」と異なり、「複数 文書にまたがって、文書に含まれる全文を対象とした 検索」という意味で使用される。 Wikipedia「全文検索」より 2
  3. 3. 全文検索の型式いろいろ grep型 UNIXコマンドのgrepに代表される、逐次実行型。 事前にindexを作成する必要がないが、大量のドキュメントの検索は遅い WindowsのXPの検索(index生成なしの場合) 遅い… 3
  4. 4. 全文検索の型式いろいろ 索引(index)型 事前に索引データ(index)を生成し、高速な検索を実現 4 文字列 | ファイルの場所 | ファイルの更新日 | 出現頻度…
  5. 5. 日本語等の解析は難しい The worst is not, So long as we can say,… 英語の場合 ] ] ] ] ] ] ] ] ] 単語区切りが分かりやすくわかち書きしやすい。 MySQL5.6で登場したInnoDB Full Text Searchもスペース区切りで投入したデータを前提としている 日本語、韓国語、中国語等 隣の客はよく柿食う客だ 形態素解析を使用したわかち書きやN-gramによる文字分解を行う必要がある 5
  6. 6. 日本語解析の方法その1 形態素解析 形態素解析器と辞書を使用しわかち書きを行う 隣の客はよく柿食う客だ 適切な辞書を使用してやれば適切にパースされる。 IPA辞書→新聞記事等をコーパスに使用しているので堅めの文章は得意 # mecab 隣の客はよく柿食う客だ 隣 名詞,一般,*,*,*,*,隣,トナリ,トナリ の 助詞,連体化,*,*,*,*,の,ノ,ノ 客 名詞,一般,*,*,*,*,客,キャク,キャク は 助詞,係助詞,*,*,*,*,は,ハ,ワ よく 副詞,一般,*,*,*,*,よく,ヨク,ヨク 柿 名詞,一般,*,*,*,*,柿,カキ,カキ 食う 動詞,自立,*,*,五段・ワ行促音便,基本形,食う,クウ,クウ 客 名詞,一般,*,*,*,*,客,キャク,キャク だ 助動詞,*,*,*,特殊・ダ,基本形,だ,ダ,ダ EOS 6
  7. 7. mecab+IPADicでティーン語を解析すると… # mecab 安カワ前線キテるぅ的な! 安 接頭詞,名詞接続,*,*,*,*,安,ヤス,ヤス カワ 名詞,一般,*,*,*,*,* 前線 名詞,一般,*,*,*,*,前線,ゼンセン,ゼンセン キテ 名詞,一般,*,*,*,*,* る 助動詞,*,*,*,文語・リ,体言接続,り,ル,ル ぅ 名詞,一般,*,*,*,*,* 的 名詞,接尾,形容動詞語幹,*,*,*,的,テキ,テキ な 助動詞,*,*,*,特殊・ダ,体言接続,だ,ナ,ナ ! 記号,一般,*,*,*,*,!,!,! EOS 安カワ前線キテるぅ的な!  (ピチレモン2009年5月号 見出し) 残念!! 7
  8. 8. 日本語解析の方法その2 N-gram 検索対象を単語単位ではなく文字単位で分解 隣の客はよく柿食う客だ N=1 uni-gram N=2 bi-gram N=3 tri-gram ・検索ノイズ ・形態素解析よりインデックスサイズ大きくなる 隣の の客 客は はよ よく く柿 柿食 食う う客 客だ N=2 bi-gramの場合 8
  9. 9. 最近よく聞く全文検索エンジン レスポンスがXMLやJSON ・Elasticsearch ・Apache Solr ・AWS CloudSearch ・InnoDB FTS (Full Text Search) ・mroonga MySQLベースなもの ■メリット ・スケールしやすい ・プラグイン開発が活発 ! ■デメリット ・RDBMSバックエンドなシステムでは  組み込み大変 ■メリット ・RDBMSバックエンドなシステムに  組み込みやすい ! ■デメリット ・MySQL以外で使えない ・スケールしにくい9
  10. 10. MySQLのLIKE検索じゃダメな理由 LIKE検索でインデックスが使えるのは前方一致のみ 検索対象カラム LIKE 検索キーワード% 検索対象カラム LIKE %検索キーワード% 検索対象カラム LIKE %検索キーワード 前方一致 中間一致 後方一致 OK NG NG MyISAM(5.5以前)かInnoDB FTS(5.6以降)を使わない限り text型のカラムにインデックス貼れない 10
  11. 11. MySQLベースの全文検索を使用するに当たって MySQLのメジャーバージョンの注意 ストレージエンジン ■InnoDB トランザクション使える ■MyISAM ・トランザクション使えない ・更新時にテーブルロックがかかる  =更新中はSELECTが待ちになる 5.0 5.1 5.5 5.6 5.7(次期バージョン) メジャーバージョンの推移が分かりにくい InnoDBがデファクトかつ殆どの場合必須 11
  12. 12. 各種全文検索エンジンの特徴 12 InnoDB FTS(Full Text Search) Tritonn mroonga MySQL-ftppc MySQL 5.0 MySQL 5.1 MySQL 5.6 MySQL 5.5 (My ISAMのみ) (My ISAMのみ)
  13. 13. MySQLで使える各種全文検索エンジン 13 Tritonn mroonga MySQL-ftppc InnoDB FTS InnoDB ○ ○ MyISAM ○ ○ ○ MeCab ○ ○ ○ N-gram ○ ○ ○ MySQL5.0 ○ MySQL5.1 ○ ○ MySQL5.5 ○ ○ MySQL5.6 ○ ○ ○ 第6回 [実録] MySQL向け全文検索エンジン「Tritonn」から「mroonga」への移行ガイド(1) http://gihyo.jp/dev/clip/01/groonga/0006?page=1
  14. 14. というわけで ・MySQL5.0のみに対応しているTritonnは除外 ・MyISAMのみの対応となるMySQL-ftppc、Tritonnは除外 (弊社パッケージはMySQL5.1以降対応のため) ・トランザクションが使えない ・更新時にテーブルロックが掛かり参照不可 14
  15. 15. mroongaの概要 ・groongaのMySQLバインディング版 ・最新版のMySQL 5.6に対応 ! ・ストレージエンジンとしてInnoDBが利用可能  トランザクションが利用可能  更新時はテーブルロックではなく行ロック ! ・Ngramもuni-gram(n=1)、bigram(n=2)、tri-gram(n=3)等が  利用可能 ! ・ラッパーモードとストレージモード  ラッパーモード   既存のストレージエンジンをラップする形で動作する  ストレージモード   トランザクション使えない 15
  16. 16. mroongaの概要 実運用としてはデータ登録時に分かち書き等する必要なし CREATE TABLE dtb_products ( id INT PRIMARY KEY AUTO_INCREMENT, keyword VARCHAR(255), FULLTEXT INDEX (keyword) COMMENT 'parser "TokenUnigram"' ) ENGINE=mroonga comment = 'engine "innodb"'; INSERT INTO dtb_products VALUES(0, 今日はいい天気です ) ! SELECT * FROM dtb_products MATCH(keyword) AGAINST( +天気 IN BOOLEAN MODE) 16
  17. 17. 商品(mroonga用) ・ストレージエンジンをmroongaに ・キーワードカラムに対して  FULL TEXT INDEXを追加 商品(InnoDB FTS用) ・ストレージエンジンをInnoDBに ・キーワードカラムに対して  FULL TEXT INDEXを追加 商品(LIKE 検索用) ・ストレージエンジンをInnoDBに ・キーワードカラムに対して  通常のインデックスを追加 100万件(5000商品 200店舗) 4万件(200カテゴリー 200店舗) 100万件(5000商品 200店舗) 100万件(5000商品 200店舗) 100万件(5000商品 200店舗) 以下のテーブルに対してSELECT、UPDATE文を 各1万回実行してベンチマークを実施 今回使用したテーブル 17
  18. 18. 今回使用した環境 サーバ ミドルウェア AWSのm1.mediumを使用。 ・CPU Intel(R) Xeon(R) CPU E5430 @ 2.66GHz コア数1 ・メモリ3.75GB ! CentOS 6.4 x86_64 ・MySQL5.6.12 ・mroonga4.0.0 18
  19. 19. SELECT 商品名 ,価格 … FROM カテゴリー LEFT JOIN 商品カテゴリー(紐付け) ON カテゴリー.カテゴリーID=商品カテゴリー.カテゴリーID LEFT JOIN 商品 USING(商品ID) WHERE 商品.削除フラグ=0 AND 商品.ステータス=1 AND 商品.キーワード LIKE %検索語句 … LIMIT 15 OFFSET 0 SELECT文(LIKE検索) 検索語句はクエリ毎にユニークな語句を使用 19
  20. 20. SELECT 商品名 ,価格 … FROM カテゴリー LEFT JOIN 商品カテゴリー(紐付け) ON カテゴリー.カテゴリーID=商品カテゴリー.カテゴリーID LEFT JOIN 商品 USING(商品ID) WHERE 商品.削除フラグ=0 AND 商品.ステータス=1 AND MATCH(商品.キーワード) AGAINST( 検索語句 ) … LIMIT 15 OFFSET 0 SELECT文(mroonga/InnoDB FTS) 検索語句はクエリ毎にユニークな語句を使用 20
  21. 21. LIKE中間一致 InnoDB FTS mroonga(mecab) mroonga(Unigram) mroonga(Bigram) mroonga(Trigram) 10 100 5 16 27 9 19 3,000 14 21 39 17 31 2,000 平均値 中央値 SELECT実行時間 ∼∼ mroonga、InnoDB FTSはLIKEの中間一致検索に比べ100倍前後高速。 mroongaのNgramの場合、Nの値が大きいほど高速 ミリ秒 100万件のデータを投入したテーブルに1万回SELECTを実行 21
  22. 22. UPDATE 商品 SET keyword= 任意の文字列 WHERE 商品.商品ID=ランダムなID UPDATE文 商品IDはクエリ毎にユニークなIDを使用 22
  23. 23. LIKE中間一致 InnoDB FTS mroonga(mecab) mroonga(Unigram) mroonga(Bigram) mroonga(Trigram) 0 2.5 5 7.5 10 7 7 8 7 6 6 7 7 9 8 7 7 平均値 中央値 UPDATE実行時間 ミリ秒 どれを使用してもそれほど差異無し 100万件のデータを投入したテーブルに1万回UPDATEを実行 23
  24. 24. LIKE中間一致 InnoDB FTS mroonga(mecab) mroonga(Unigram) mroonga(Bigram) mroonga(Trigram) 10 100 1000 10000 291.45 210.82 208.69 201.01 6,106.13 75.8 100万件データのindex更新時間 ∼ 秒 InnoDB FTSが著しく遅い。 mroongaのNgramの場合Nの値が大きいほど更新に時間が掛かる 24
  25. 25. 気になっている点 テーブルには以下の制限があります。この制限はgroongaに由来します。 1つのキーの最大サイズ: 4096Bytes キーのサイズを合計した上限値: 4GBytes ! 実際には他の諸条件の制約により上記の値まで到達しない場合もあります。 25 5. 制限事項 ̶ Mroonga v4.01 documentation http://mroonga.org/ja/docs/reference/limitations.html
  26. 26.

×