図書館でのsolrの使い方
DESCRIPTION
第5回Solr勉強会の資料TRANSCRIPT
図書館での Solr の使い方Next-L Enju と国立国会図書館サーチ
Twitter: @nabeta
自己紹介
● 田辺浩介（たなべこうすけ）– 1978 年 4 月 12 日生まれ
– 慶應義塾大学大学院政策・メディア研究科博士課程– 東洋大学経営学部非常勤講師– 合同会社次世代図書館システム代表社員
– 司書資格持ち– Project Next-L 参加者
Project Next-L
●図書館関係者による図書館管理システム開発プロジェクト
– http://www.next-l.jp/
●2006 年 11 月に慶應義塾大学文学部の原田隆史准教授（当時）によって設立
Next-L Enju
●Project Next-L の成果物となるオープンソース図書館管理システム
●Ruby on Rails + PostgreSQL / MySQL+ Apache Solr で構築
●2008 年より開発開始、 github 上で公開– http://github.com/nabeta/next-l
図書館管理システムとはどのようなシステムか？
●図書館の業務管理のためのシステム– 図書館の本館・分館全体でひとつ
（という場合が多い）– 利用者と司書の両方が使用する
●主に以下のような業務がある– 受入– 貸出・返却– 利用者管理
受入
●ある本を図書館の資料として登録する業務– 書店からの購入、個人・団体からの寄贈– 1 冊ごとに各図書館ごとにローカルな ID
（資料番号）を割り当てる– 同じ本を複数冊購入する場合があるため
ISBN だけでは管理に使えない– 予算管理もシステム内で行う場合がある
貸出・返却
●貸出時に資料番号、利用者番号、貸出期限をシステムに保存
●返却時に返却日を保存– もしくは貸出情報を削除
●予約がかかっている場合の割り当てと通知
利用者管理
●図書館の利用者についての情報– 貸出・返却・予約– 連絡先
● 予約や返却時の督促に使用
どのようなデータがあるか (1)
●書誌データ– 本そのものについてのデータ– タイトル・著者名・出版社名・ ISBN ・
出版日・価格– ISSN ・巻号（雑誌の場合）– 分類記号、件名（キーワード）– 大きさ（高さ・奥行き）
どのようなデータがあるか (2)
●所蔵データ– どの本をどこの図書館が持っているか– 図書館名、個別資料番号、受入日
●貸出データ– どの本を誰がいつまで借りているか
●利用者データ– 氏名・住所・メールアドレス・電話番号・
利用者番号など
どのようなデータがあるか (3)
●定型、多数の検索対象となる項目を有する（書誌データ、利用者データ）
●物流管理システムの側面を持つ– 貸出・返却・予約・予算管理– システムとしてトランザクションや統計（集計）機能が必要
検索対象
●書誌データを基本に、所蔵データ・貸出データの組み合わせ
●たとえば…– 「ドラッカー」を含むタイトルで、「岩崎」さんが書き、2009 年以降に出版され、渋谷区立中央図書館で所蔵しており、現在予約可能な状態になっている本
図書館の検索の特徴
●それなりの即時性が必要– 「現在貸し出されていない本」
●データ自体はそれほど大規模ではない– 大規模館でも蔵書は数百万冊– 比較的小さなデータがほとんど、全文の
入っているものはまだ少数●検索回数もそれほど多くない
– 東京大学附属図書館で年間 550万回、東京都立図書館で年間 400万回
図書館の検索の問題点
●利用者は単純な検索インターフェースを好む– 複数の項目をまとめて（項目指定なしで）検索したい
– Web の検索エンジンに慣れている
●司書は複雑な検索インターフェースを必要とする
– 項目を詳細に指定して検索したい
典型的な検索画面 (1)
典型的な検索画面 (2)
求められる要件
●図書館管理システムとして– 既存の RDBMS を活かしつつ、
全文検索の機能を上手に組み込める仕組みがほしい
– 項目を指定しない検索と、項目を指定した検索を両立させたい
●Enju として（≒個人的な理由として）– できるだけ OS の標準的なパッケージをそのまま使いたい
やってみたこと (1)
●Senna, Ludia– 非正規化したテーブルを用意して、そこに検索対象のデータを保存する
●試してみたが…– ActiveRecord が使えるようになったのに、
また SQL を直接書くのが嫌– トランザクションに対応していない– いまひとつ不安定
やってみたこと (2)
●HyperEstraier– acts_as_searchable を使用– 高速だが、項目指定による検索が弱い– ファセット検索機能がない– 自分で真似をしてみたが非常に遅い
●ファセット検索機能のある海外の図書館システムのソースコードを読むことに
– 初めて Solr の存在を知る
海外の図書館システム
●商用製品に加えて、オープンソース・ソフトウェアとして開発されているものが多数存在
– 開発コミュニティ” code4lib”http://code4lib.org/● 2011 年は Eric Hatcherさんが講演
●多くのプロジェクトで Solr を使用– うちでも使ってみよう！
acts_as_solr
●Ruby on Rails 用のプラグイン– https://github.com/tjackiw/acts_as_solr
●Solrへの接続→文書 ID の取得→ ActiveRecordからの取得を一気にやってくれる
●レコードを保存したときにはインデックスの更新も自動で行う
●複数モデル（テーブル）にまたがる検索も可能
●開発が停滞している点に懸念
Sunspot
●Ruby の Solr接続用ライブラリ– 現在 Next-L Enju で使用– https://github.com/outoftime/sunspot– Solr 1.4.1 を同梱
●rsolr の上に作られており、抽象度が高い– https://github.com/mwmitchell/rsolr
●Rails に依存しないが、 Rails 用の連携機能は標準装備
– sunspot_rails
Sunspot の使用例 (1)
Sunspot の使用例 (2)
Sunspot の使用例 (3)
Rails との連携
●検索はまず全文検索システムに対して行い、そこで得られた ID で RDB を検索して実際のデータを取得する
– acts_as_searchable, acts_as_solr, sunspot_railsともこの方式
– ActiveRecord オブジェクトの配列が返ってくる●ハイライトやスニペットの取得は
もう一手間必要
Enju での利用にあたって (1)
●書誌データ・所蔵データ・利用者データの検索で使用
●DIHは使わず、 1件ずつインデックス作成
●RDB ですむ部分は RDB にやらせる– Solr が止まっても最低限の業務は動かせる
ように作る
Enju での利用にあたって (2)
●インデックス作成には CJKAnalyzer を使用– 検索漏れを防ぐことに重点を置く
●インデックスのサイズは書誌 20万件で約 500MB
– ただし分館なしの設定（所蔵データが少ない）のため、参考程度の値
国内での使用例
●国立国会図書館サーチ– Next-L Enju をコンポーネントとして採用– http://iss.ndl.go.jp/
●九州大学” Cute.Catalog”– http://catalog.lib.kyushu-u.ac.jp/catalog/ja
国立国会図書館サーチ
Cute.Catalog
国外での使用例
●いっぱい– code4lib での発表例多数– 検索業務特化型が多い
●代表例 : VuFind http://vufind.org/– アメリカのヴィラノヴァ大学で開発された
図書館の検索用インターフェース– PHP + Solr 、大学を中心に採用
感想と今後の課題 (1)
●今のふつうの図書館のWeb検索であれば1台で十分やっていけるかもしれない
– ただし commit回数はできるだけ減らさなければならない
– 検索速度よりも更新速度のほうが問題
●インデックスの使い分け– 一般利用者向けにはわかち書き– 司書向けには N-gram
感想と今後の課題 (2)
●異体字の問題– 古典資料を扱う場合は特に重要
●全文データが入ってきたときにどうするか– N-gram でもインデックス作成は間に合う？