Groongaと運用
Groongaで学ぶ全文検索 2016-01-15
2016-01-15（金）20:00 - 22:30
データの消失
データストア先の候補として以下のようなものがある。
- RDB(MySQL, PostgreSQL, SQLite)
- ファイル
壊れるには２種類がある。
- 物理的:
ハードウェア的にデータが失われる。 - 論理的:
データの書き込み途中にプロセスがクラッシュしてデータの不整合な状態が発生。たとえば、"Hello"と書き込んでHで終わるなど。
上記のうちRDBにはトランザクションの機能が用意されているものが多く、論理的に壊れにくい工夫がなされている。
一方、全文検索製品でトランザクションに対応している製品はたぶん少ない。
そのため、全文検索製品は論理的に壊れうる。
対応策
全文検索機能の消失に対する方法として以下の３種類が考えられる。
- マスターデータを死守
- バックアップ
- データの複製
マスターデータを守る
マスターデータさえ死守すれば、全文検索機能を復旧することは可能。
-
メリット
- 空間効率が良い
- Groongaには静的索引構築という素早くインデックスを作る仕組みがある
-
デメリット
- バックアップからの戻しに比べて復旧が遅い
バックアップ
インデックスを含めてバックアップする。
-
メリット
- 復旧が速い（差分更新がなければファイルコピーのみ）
-
デメリット
- 空間効率が悪い
データの複製
RDBにあるレプリケーションの機能を使ってデータを複製する。
- メリット
- サービス継続性向上（１台死んでもしなない
- デメリット
- コスト増
- 運用スキルが必要
- 複製の部分でうまくいかないとデータロストする可能性がある
構成例
- Mroongaの場合
マスター：InnoDB <=> スレーブ：Mroonga
- PGroongaの場合
PostgreSQLのAPIの仕様上、データの同期しか行うことができないため、全文検索も更新も両方マスターとする構成をとるべき。
スレーブが無駄になるが、スレーブも検索に使えるような前提はあまりおすすめできない。
思いつき
最近では(たぶん)信頼できるデータストアとしてクラウドストレージAmazon S3などがある。
クラウドストレージにぶち込んだら自動的に全文検索ができるようなサービスがあったらどうか。
更新apiのイベントをキャッチできるような機能があったら作れそう。
こうすると物理的なマスターデータだけはある程度堅牢に守られるんじゃないだろうか。