SlideShare a Scribd company logo

図書館でのSolrの使い方

•
•
Kosuke Tanabe
Kosuke Tanabe

第5回Solr勉強会の資料

1 of 36
Downloaded 27 times
図書館での Solr の使い方 Next-L Enju と国立国会図書館サーチ 田辺浩介 tanabe@mwr.mediacom.keio.ac.jp 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
Next-L Enju http://enju2.slis.keio.ac.jp/
図書館管理システムとは どのようなシステムか？ ●図書館の業務管理のためのシステム – 図書館の本館・分館全体でひとつ （という場合が多い） – 利用者と司書の両方が使用する ●主に以下のような業務がある – 受入 – 貸出・返却 – 利用者管理
受入 ● ある本を図書館の資料として登録する業務 – 書店からの購入、個人・団体からの寄贈 – 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 、大学を中心に採用
オーストラリア国立図書館 http://catalogue.nla.gov.au/
感想と今後の課題 (1) ● 今のふつうの図書館の Web 検索であれば 1 台で十分やっていけるかもしれない – ただし commit 回数はできるだけ 減らさなければならない – 検索速度よりも更新速度のほうが問題 ● インデックスの使い分け – 一般利用者向けにはわかち書き – 司書向けには N-gram
感想と今後の課題 (2) ● 異体字の問題 – 古典資料を扱う場合は特に重要 ● 全文データが入ってきたときにどうするか – N-gram でもインデックス作成は間に合う？

More Related Content

図書館でのSolrの使い方

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