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

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

テーブル基本設計

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

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

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

クラウドサーバ検討

どこでサーバを立てようか検討中

 

現在は,GMOクラウドを使っているが,特に不満はない。

半年に1回ぐらいは,サーバ停止での移行があるが,それほど気にならない。

図書館関係のサイトはクリティカルではないので。

www.gmocloud.com

今回のサービスは,極力スモールスタートで行きたい。ニーズも読めないし,

機能要件も不確定だ。

 

最低限のWEBサーバ+DBサーバの2台が必要となるが,スペックは最低でも

いい。mysqlのテストではmroongaはリソースが少なくても,十分な検索

スペックを出してくれそうだ。(書誌60万件,所蔵100万件でテスト)

 

いろいろと調査していても,やはりGMOクラウドがよさそうではある。

導入時のサポートも悪くなかった。

 

次の候補は,

調べてみると,結構よい。価格もGMOよりは低い。通信が無制限ではないが

スモールスタートに大量のトラフィックは必要ない。

時間ができたら,契約して使い勝手を検証することにする。

 

書誌検索について

もうすでに,現役を離れて久しい。あくまでもこれは今回のシステムからの

視点であって,図書館システムがあるべき姿を見据えている訳ではない。

 

書誌検索の最大のポイントは,いかにノイズを少なく的確に利用者が

イメージした資料ニーズを充足できるかにある。これは何も,機械化された

書誌検索の仕組みに特化したものではない。カード目録も同じコンセプトで

件名をつけ,アクセスポイントを切りだし,マニュアルとカードでできる限り

の理想を追い求めた。そこにあったのは,データベース全盛の現在からは全く

評価されないが,合理的な検索手法の集大成であったと思う。カード目録

時代とDB検索を共に経験した技術者は,カード目録の理想に引っ張られて

いる部分があると思う。当然,自身を含めてだ。いまでも検索ノイズは

ある種の必要悪とはわかりながら,どうもしっくりこない。これがn-gram

使わない理由の一つだ。mecabによる辞書切りだしは面倒である。ここを

諦めればマネージドのmysqlを使うことも可能かもしれない。どこかの業者が

mysql+mroongaをサポートするのは時間の問題だと思っている。しかし,

mecabをサポートしてくれるとは思えない。なぜなら,ほとんどのユーザー

にとって,n-grammecabの違いなどどうでもよいからだ。ユーザーにとって

必要なことは,表示ページでの順位であり1ページ目に表示された書誌が

いかに自分のニーズを満たしてくれるかである。入力語に対する正確性など

殆ど気にも留めていないだろう。

 

結局,今回の開発でも,mecabを使うことにした。mysql+mroonga+mecab

である。そもそも書誌情報は文字数が少ないことから,全文検索に向かない。

だからこそ,ヒットノイズは可能な限り削りおとしていくべきだ。そのためには

優れた辞書と絶え間ないメンテナンスが必要になる。さて,現在の図書館システム

は,どのような検索手法を取っているのだろうか。n-gramだろうか,

辞書インデックスだろうか。ノイズを許容してn-gramを使うのであれば,

ページランク的な機能が必要ではないだろうか。辞書インデックスであれば,

ユーザーが集まって辞書の育成に力をいれているのだろうか。

 

仕組みよりも,ニーズの充足。現役を離れてあまり制約がないからこそ,

いろいろと試してみたいこともある。

 

 

grails3.2 を使う(2)

既存のGrails2.X系のAppを3.Xに移行するために試行錯誤している。

 

3 Upgrading from Grails 2.x 3.0.0 参考ははやりオリジナルの移行ガイド

ファイルレベルで統廃合があり,なかなか難しそう。

 

www.slideshare.netこれも参考。最初の一歩としては十分

まずは,config関係の作り直しからスタート

 

grails-app/conf/BuildConfig.groovy build.gradle Build time configuration is now defined in a Gradle build file
grails-app/conf/Config.groovy grails-app/conf/application.groovy Renamed for consistency with Spring Boot
grails-app/conf/UrlMappings.groovy grails-app/controllers/UrlMappings.groovy Moved since grails-app/conf is not a source directory anymore
grails-app/conf/BootStrap.groovy grails-app/init/BootStrap.groovy Moved since grails-app/conf is not a source directory anymore
scripts src/main/scripts Moved for consistency with Gradle
src/groovy src/main/groovy Moved for consistency with Gradle
src/java src/main/groovy Moved for consistency with Gradle
test/unit src/test/groovy Moved for consistency with Gradle
test/integration src/integration-test/groovy Moved for consistency with Gradle
web-app src/main/webapp Moved for consistency with Gradle
*GrailsPlugin.groovy src/main/groovy The plugin descriptor moved to a source directory

 ってことらしいが,2.x系で使っていた設定系は,Config.groovyとBootStrap.groovyのみ。property系は,application.ymlに入った。ここで各種設定して,applicationGrailsクラスを使って参照すればOKとなる。BootStrap部分でもコントローラーでも同じ手法で

OK.

 

ログ関係は,全く別ファイルになって,logbackへと変更。

設定自体は,大きな変更はなし。

思ったより,容易に移行できた。.groovy系の設定ファイルは,ymlに移行すれば

ほぼOK.これからは,独自のymlファイルの取り扱いについてテストしてみる。

 

環境整備はできたので,今後は仕様検討に入る予定。特に日本語全文検索系の

処理をどうするか。

 

 

MariaDB&MySQL全機能バイブル

MariaDB&MySQL全機能バイブル

 

 

 

[改訂新版] Apache Solr入門 ~オープンソース全文検索エンジン (Software Design plus)

[改訂新版] Apache Solr入門 ~オープンソース全文検索エンジン (Software Design plus)

 

 

 

 

grails3.2 を使う

grails3.0を使う

qiita.com

動かすだけなら,いつもどおり。create系のコマンドでOK。

だが,grails2.0系とはこれは全く別物であることに気付いた。

もう少し詳しく調べる必要がありそう。grails2系からgrails3系へ移行するための手順書でもあれば,過去に開発したクラス等を使っていける。日本語の資料はほとんどない。

やはり本家のドキュメントを読み込むことにする。

3 Upgrading from Grails 2.x 3.0.0

 

3.x系に移行するメリットはまだわからないが,とりあえず,2.xは卒業にする。

ななめ読みした感じでは,3.X系は,spring.bootのラッパー的な扱いになっている

ような感じだが,本当だろうか。そもそもgrailsフレームワークとして選択して

理由は,springだとシステム開発要件に対して,過剰だったから。アジャイル的な

開発をしたくて,grailsをした(それだけはないが)のだけど,おそらくライトウェイト的な手法は変わらないと思うので,当面はこのまま進行。

 

 

Grails徹底入門

Grails徹底入門

  • 作者: 山田正樹,山本剛,上原潤二,永井昌子,杉山清美,杉浦孝博,笠原史郎,香月孝太,福岡竜一,伊堂寺北斗
  • 出版社/メーカー: 翔泳社
  • 発売日: 2008/08/26
  • メディア: 大型本
  • 購入: 3人 クリック: 42回
  • この商品を含むブログ (28件) を見る
 

 

 

 

 

 

システム基本事項

これから,Webシステム開発について,記録していきます。

まずは,現時点の基本仕様

  • UbuntuServer 14.04 →リリース時には16系まで上げる
  • mariaDB + mroonga + mecab
  • grails 3.2系
  • bootstrap 3系

現時点の仕様なので,変更は十分にあります。フレームワークは,grails

確定予定ですが,3.0系はまだ全く未知なので,別のフレームワークへの変更は

あるかもしれない。