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

リブショカ(図書館書架)β版

リブショカ(図書館書架)に関する情報発信

テーブル基本設計

システム開発

今日は,mysqlでのテーブル設計&テスト

 

メインのテーブルは3つ

 bib 書誌テーブル

    hol    所蔵テーブル

 ser    シリーズ(書架)テーブル

 

この3つがあって,それぞれに全文検索するカラムがある。

全文検索にはmysql+mroonga+mecabを使う。

 

結局,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あたりに移行するメリットもないと思われる。これまでは,

ある程度の汎用制の確保にコストをかけていたが,今回はそういった

ことはなしで,極力軽く作っていく予定。