今日は,mysqlでのテーブル設計&テスト
メインのテーブルは3つ
bib 書誌テーブル
hol 所蔵テーブル
ser シリーズ(書架)テーブル
この3つがあって,それぞれに全文検索するカラムがある。
結局,apache solrを使うにしても,全文検索の性能を出すためには
1つのテーブル,1つのファイルにするのがベスト。viewで連結しても
結局は,SQLを書く手間が省略されるだけで,スピードが向上する
わけではない。mysqlで全文検索するメリットの一つは,即時更新である。
apache solrだとどうしても,DB更新→インデックス更新となり,登録
したレコードが全文検索でヒットするまでにはタイムラグがでてしまう。
これらの処理をバッチで行うことも運用的にはコストがかかる。
そのため,mysql上ですべてを処理して,インデックス即時更新と
することにした。この処理のために犠牲になるのは,DBレコード
登録時のレスポンスであるが,書誌60万件,所蔵100万件,書架30万件で
テストしたところ,ミニマムなサーバでも問題なく運用できる結果と
なった。
実際には,
1)bib,hol,serのカラム構成を踏襲したindex用のテーブル作成(holx)
2)1)と同じカラム構成となるようにbib,hol,serでView(holv)を作成する。
3)holの要素を基にして,holxを更新するプロシージャ作成
→ 基本,holに対するアクションは,holxの削除→新規登録で処理する
4)メインとなるholテーブルにトリガー(ins,update,del)をセットする。
トリガーは,3)で作成したプロシージャのキックのみ
こうすると,記録用のテーブルからオンタイムでインデックスを作成
できる(メンテナンスできる)。万が一,holxがクラッシュした場合でも
insert into holx select * from holv;
で復元できる。これであれば,障害時の対応もコストが安くすむ。
全文検索用のテーブルのメンテナンスもservlet側で意識する必要がなくなる。
とりあえず,テストは問題なかったので,本番DBでの実装はこの方針で。
mysqlのトリガーはほとんど使ったことがなかった。トリガーはもっぱら
Oracel PL/SQLだったので,戸惑う部分も多かった。
機能的な切り分けはいつも悩ましい。アプリ側での処理はできればユーザー
へのレスポンスに特化させて,データ周りはDB機能に依存させたい。
汎用的なアプリにする場合は,DB機能依存は問題があるだろうが,
今回のサービスは,mysqlを簡単に捨てるつもりはないし,そもそも
postgreあたりに移行するメリットもないと思われる。これまでは,
ある程度の汎用制の確保にコストをかけていたが,今回はそういった
ことはなしで,極力軽く作っていく予定。