株式会社クリアコード > ククログ

ククログ

«Firefoxの技術書「Firefox Hacks Rebooted」 最新 ApacheとPhusion PassengerでデプロイしたWebアプリケーションが不調になる問題と解決»
タグ:

すべてのMySQLユーザーに高速な全文検索機能を! - OSC2011.DB用資料

オープンソースカンファレンス2011 DBOSSDB MySQLセッションでgroongaストレージエンジンについて紹介してきました。

すべてのMySQLユーザーに高速な全文検索を!

内容はgroongaストレージエンジンが得意なシチュエーションについてベンチマークデータを紹介するというものです。どういうときにgroongaストレージエンジンが高速に動作するかがわかります。

groongaストレージエンジンが得意なシチュエーション

groongaストレージエンジンは以下のような処理が得意です。

  • 全文検索
  • 位置情報検索
  • リアルタイム更新

groongaストレージエンジンの性能特性を紹介するためにベンチマークデータを紹介しました。ベンチマークはこれらの得意な処理を実行するシチュエーション向けに複数のパターンで行いました。

高速な全文検索

groongaの全文検索処理の性能を示すためにtwitterから取得したデータを利用しました。測定する処理はフレーズ検索です。約100万件のtweetに対して「"facebook saved"」というような2単語でフレーズ検索します。このようなフレーズ検索を1万回(1万パターン)実行するためにかかった時間が縦軸になっており、グラフが短いほど高速に全文検索が実行されていることを示しています。

約100万件のtweetに対して1万回のフレーズ検索にかかった時間

groongaストレージエンジンの方がMySQLの開発版5.6.3-labs-innodb-ftsに含まれるInnoDBの全文検索機能よりも10倍程度高速で、MyISAMよりは2倍程度高速でした。

高速な位置情報検索

groongaの位置情報検索処理の性能を示すために国土交通相の位置参照情報ダウンロードサービスの2010年版のデータを利用しました。測定する処理は「MBRContains(GeomFromText('LineString(139.850124 38.718204, 140.447158 37.817489)'), location)」というように位置情報でレコードを絞り込み、「ORDER BY name」というように住所でソートする検索です。このような検索を千回(千パターン)実行するためにかかった時間が縦軸になっており、グラフが短いほど高速に位置情報検索が実行されていることを示しています。

約1100万件の番地データに対して千回のMBRContains + ORDER BY検索にかかった時間

groongaストレージエンジンのほうがMyISAMよりも40倍程度高速でした。

リアルタイム更新

groongaはリアルタイム更新が得意です。リアルタイムで更新するために以下の2点を重視しています。

  • 高速に更新できること。
  • 検索負荷が高いときでも更新性能が落ちないこと。

まず、更新性能が高いことを確認し、次に検索負荷が高いときの更新性能を確認します。

高速な更新

高速に更新できることを示すために、98万件のtweetが登録されたデータベースを用意します。このデータベースに対して、2万件のtweetを登録します。このとき1秒あたりに追加したレコード数が縦軸になっており、グラフが長いほど高速に登録されていることを示しています。

98万件のtweetが保存されている状態で2万件のtweetを追加したときの更新スループット

groongaストレージエンジンのほうがInnoDBよりも3倍程度高速、MyISAMよりも2倍程度高速、Sphinxよりも3倍程度高速でした。

参照ロックフリーな更新

検索負荷が高いときでも更新性能が落ちないことを示すために、98万件のtweetが登録されたデータベースを用意します。このデータベースに対して、検索負荷(クエリ数/秒)を変えながら2万件のtweetを登録します。このグラフはそれぞれのストレージエンジン毎に見ます。横軸が検索負荷を表していて、左側になるほど検索負荷が小さく、右側になるほど検索負荷が高いことを示しています。グラフが水平になっているほど検索負荷が高くなっても更新性能が落ちていないことを示しています。

98万件のtweetが保存されている状態で検索負荷を変えながら2万件のtweetを追加したときの更新スループット

groongaストレージエンジンとInnoDBは検索負荷が高くなっても更新性能はそれほど落ちておらず、MyISAMとSphinxは更新性能が落ちていました。

groongaストレージエンジンの機能制限

このように、高速に動作するgroongaストレージエンジンですが、以下のように機能制限があります。

  • トランザクションをサポートしていない。
  • 位置情報はPOINTしかサポートしていない。

そのため、どのようなケースにでも利用できるわけではありません。しかし、groongaストレージエンジンは他のストレージエンジンと組み合わせて使うことができるため、上記の機能制限の一部を解消することができます。

groongaストレージエンジンを他のストレージエンジンと使う場合は全文検索処理・位置情報検索処理のみをgroongaストレージエンジンが行い、それ以外の処理は連携した他のストレージエンジンが行います。そのため、groongaストレージエンジンとInnoDBを一緒に使うと、トランザクションはInnoDBの機能を用いて、全文検索はgroongaストレージエンジンを用いる、ということができます。この仕組みを使うと「トランザクションをサポートしていない」というgroongaストレージエンジンの機能制限を解消することができます。

groongaストレージエンジンと他のストレージエンジンを組み合わせて使う方法

ただし、更新性能は組み合わせて使うストレージエンジンの性能に依存するため、groongaストレージエンジンの得意な処理である「リアルタイム更新」性能は発揮できません。「高速な全文検索機能」と「高速な位置情報検索機能」のみ利用できます。

InnoDBと組み合わせて利用した場合のベンチマークデータを以下に示します。

まず、全文検索の性能です。

約100万件のtweetに対して1万回のフレーズ検索にかかった時間(InnoDBと組み合わせた場合のデータ付き)

groongaストレージエンジン単体で使った場合とほとんど同じ性能がでています。

次に、位置情報検索の性能です。

約1100万件の番地データに対して千回のMBRContains + ORDER BY検索にかかった時間(InnoDBと組み合わせた場合のデータ付き)

こちらもgroongaストレージエンジン単体で使った場合とほとんど同じ性能がでています。

次に、更新性能です。

98万件のtweetが保存されている状態で2万件のtweetを追加したときの更新スループット(InnoDBと組み合わせた場合のデータ付き)

groongaストレージエンジン単体で使った場合よりも大きく性能が落ちて、組み合わせて使っているInnoDBと同じ程度の性能になっています。

最後に検索負荷が高いときの更新性能です。

98万件のtweetが保存されている状態で検索負荷を変えながら2万件のtweetを追加したときの更新スループット(InnoDBと組み合わせた場合のデータ付き)

InnoDBが検索負荷が高くても更新性能がほとんど落ちないため、groongaストレージエンジンとInnoDBを組み合わせて使った場合でも更新性能がほとんど落ちていません。

まとめ

OSC2011.DBでgroongaストレージエンジンが得意なシチュエーションのベンチマーク結果を紹介してきました。もちろん、groongaストレージエンジンが得意ではないシチュエーションもあり、そのようなケースでは他のストレージエンジンの方が性能がよくなります。groongaストレージエンジンが苦手なケースについては今月末(2011/11/29)開催の全文検索エンジンgroongaを囲む夕べ 2で紹介する予定です。興味のある方はこちらに参加してみてください。すでに定員を超えていますが、前回の全文検索エンジンgroongaを囲む夕べ #1では最終的に35名のキャンセルになっていましたので、今からでもギリギリ参加できるのではないでしょうか。

groongaストレージエンジンのより詳しい情報についてはgroongaストレージエンジンのサイトも参照してください。

タグ: Groonga
2011-11-07

«Firefoxの技術書「Firefox Hacks Rebooted」 最新 ApacheとPhusion PassengerでデプロイしたWebアプリケーションが不調になる問題と解決»
2008|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|
タグ:
RubyKaigi 2015 sponsor RubyKaigi 2015 speaker RubyKaigi 2015 committer RubyKaigi 2014 official-sponsor RubyKaigi 2014 speaker RubyKaigi 2014 committer RubyKaigi 2013 OfficialSponsor RubyKaigi 2013 Speaker RubyKaigi 2013 Committer SapporoRubyKaigi 2012 OfficialSponsor SapporoRubyKaigi 2012 Speaker RubyKaigi2010 Sponsor RubyKaigi2010 Speaker RubyKaigi2010 Committer badge_speaker.gif RubyKaigi2010 Sponsor RubyKaigi2010 Speaker RubyKaigi2010 Committer
SapporoRubyKaigi02Sponsor
SapporoRubyKaigi02Speaker
RubyKaigi2009Sponsor
RubyKaigi2009Speaker
RubyKaigi2008Speaker