読者です 読者をやめる 読者になる 読者になる

CreateField Blog

オープンソースを使って個人でWebサービスを開発・運営していたブログ

数百GiBの全文検索用データベースをMroongaのストレージモードにしてはまったこと

前回は、全文検索Webサービスを作ったときにはまったことの第2回として、 Mroongaのラッパーモードからストレージモードに変えた理由という記事を書きました。

今回は、Mroongaのストレージモードにしたことによってはまったことについて書きたいと思います。

Spiderストレージエンジンを使ったMroongaの分散構成の検討

当初、データベースを複数に分割し、Spiderストレージエンジンを使ってデータベースシャーディングする予定でした。

Spiderストレージエンジンは、ストレージエンジンの種類を問わずデータベースを水平分散させることができるMySQL/Mariadbのストレージエンジンです。 Spiderストレージエンジンは、国産で個人の方が開発されたストレージエンジンでMariaDB10.0系にすでにバンドルされています。 Spiderストレージエンジンの開発者の方は、全文検索Mroongaストレージエンジンの開発にも携わられています。

Spiderストレージエンジンは、非常に簡単にデータベースシャーディングすることができ、既存のSQLをそのまま使うことができます。

前回説明したように、ドリルダウン検索*1が非常に便利でWebアプリの機能として組み込みたいと考え、Mroongaをラッパーモードからストレージモードに変更し、全文検索はGroongaのコマンドを使うことにしました。

しかし、SpiderストレージエンジンはSQLベースで分散するため、Groongaのデータベースに直接コマンドを発行することはできません。 当時のGroongaには、分散機能がありませんでした*2

そこで、約400GiBのデータベースを分散させずに良好なパフォーマンスが得られるかという無謀な挑戦がはじまります。

データベースの統合によるカラムサイズ制限

Groongaには、いくつかの制限事項が設けられています。

当時のドキュメントには記載がありませんでしたが、Groongaには1カラムに格納可能なデータサイズの上限値が設けられており上限値は256GiBです。

したがって、約400GiBのデータベースを1カラムに格納することができませんでした。

そこで、苦肉の策として1カラムを3カラムに分割させます。 テーブルには、年度を示すカラムがあったため、1999年以前、2000年~2009年、2010年以降の3つのカラムを作成し、 年度に応じてアプリケーション側で切り替えるようにしました*3

なお、次期GroongaであるGrnxxでは、上記の制限が撤廃できるように設計が検討されているようです。

https://docs.google.com/presentation/d/1R5YqedpDyI9NVNn6f_EkCBZ8miQAldrAxu5-AwjmPas/edit#slide=id.p

データベースの統合によるインデックス構築失敗再び

上記のようにカラムを分割することにより、カラムの上限による制限は回避することができました。

しかしながら、今度はまたインデックス構築に失敗するようになります。

第1回に書いたインデックス構築の失敗とは、また別の原因によるものです。

この事象は、データベースサイズが100GiBぐらいにならないと再現せず、簡単な再現セットを作るのが困難でした。

メーリングリストで相談すると、デバッグ手法を一から教えていただいたり、バックトレースログから推測されるバグの修正パッチなどきめ細やかな対応をしていただきました。

http://sourceforge.jp/projects/groonga/lists/archive/dev/2013-August/001718.html
http://sourceforge.jp/projects/groonga/lists/archive/dev/2013-August/001725.html

しかし、再現に半日かかることもありバックトレースログから原因をなかなか突き止めることができませんでした。

そうしていると、わざわざテストマシンを用意していただけることとなり、当方の100GiB以上の再現可能なデータベースを直接提供して解析していただけることになりました。

http://sourceforge.jp/projects/groonga/lists/archive/dev/2013-September/001739.html

これによりオーバーフローしている箇所を突き止め、バグを修正していただけました。こうして、数百GiBのデータベースでも正常にインデックス構築ができるようになりました。

http://sourceforge.jp/projects/groonga/lists/archive/dev/2013-October/001866.html

以上のようなきめ細やかな対応を全て無償で行っていただきました。

個別環境による検証等は、有償のサポートサービスを契約すべきなのかもしれません。無償にも関わらず、ここまできめ細やかなご対応どうもありがとうございました。

おわりに

以上のようにして、Mroongaのストレージモードで400GiB超のデータベースのインデックス構築ができるようになりました。

しかし、この後の検証によりデフォルトのトークナイザのTokenBigramでは、全文検索のパフォーマンスがあまり芳しくないことが判明します。サイズがでかすぎるので当然といえば当然です。

そこで、400GiB超のデータベースの全文検索のパフォーマンスをできるだけ改善できないかを試行錯誤することになります。

次回は、全文検索のパフォーマンスをできるだけ良くするために試行錯誤したことについて書こうと思っています。投稿まで少し時間が空くと思います。

6/26 記事を追加しました。
Groongaがあまり得意でない類似文書検索に連想検索エンジンGETAssocを使った話

2014-11-29(土)13:30 - 17:30
年に1度のGroongaに関するイベントがあります。Groongaを使っている人、興味がある人は参加してみてはいかがでしょうか。

全文検索エンジンGroongaを囲む夕べ5 - Groonga | Doorkeeper

*1:他の全文検索エンジンやDroongaではファセット検索と呼ばれています。

*2:2014年2月には、Droongaと呼ばれるGroongaの分散システムがメジャーリリースされています。

*3:非常に不格好なのでお勧めしません。