OAI-PMHに関する参考資料（カーリル）

OAI-PMHに関する参考資料（カーリル）

1. 1. OAI-PMHに関する参考資料 2016 CALIL Inc CC-BY
2. 2. OAI-PMHの困難 RDBMS 業務 Web-OPAC 長期延滞の書誌は隠して 修理中の書誌は隠して 小学校・中学校のみ所蔵の書誌は隠して 発注中でも予約のために表示したい “火花”は隠す! ICCAP 相互貸借されたくない書誌は隠して exp,郷土資料館、公民館 AV資料は隠して OAI-PMH 同じ書誌IDが何度も再出現 deletedの管理は困難 既にここがかい離 パッケージシステムの テーブル設計は変更困難 OPACの遅さの元凶 OPAC2.0対応で複雑化 exp. 使えないファセット スマホOPAC 館内OPAC
3. 3. 現実的モデル RDBMS 業務 書誌テーブル 所蔵テーブル OAI-PMH 長期延滞の書誌は隠して 修理中の書誌は隠して 小学校・中学校のみ所蔵の書誌は隠して 発注中でも予約のために表示したい “火花”は隠す! deletedの管理 中継＆フィルタ カーリルでは、 Unitrad APIの無料オプションとして提供 （カーリル Farm）
4. 4. OAI-PMHの実装実験（カーリル Farm） identifierをキーに書誌を格納・100GB程度・どれでもいい • Aerospike • Redis • Kyoto Cabinet • Riak 20,000TPS程度…この部分の性能のみでスケールアウト可能 (トランザクション/秒) 更新日別のIdentifierリスト・200MB程度 Redisのセット機能(SUNIONSTORE命令)で From/Until を実装 20,000件 GZIP圧縮で10MB以下 展開サイズ 80MB程度 1秒 100ms 3秒 実測値 ≒100万書誌の同期に150秒 WSGIプロセス インデックス KVS 設計上の制限なし
5. 5. OAI-PMHの実装実験（カーリル Farm） KVS NDL-OAIPMHのXMLを KVS/インデックスにロードする時間 500万件 / 400秒 … ボトルネックはXMLパーサー WSGIプロセス インデックス
6. 6. 検証環境（参考） APIサーバー • AMD FX-8300 / 16GB • Python2.7.11(tornado) インデックスサーバー • AMD FX-8300 / 16GB • Redis 3.2.1 KVSサーバー×3（クラスタ構成） • AMD FX-8300 / 16GB • SSD 500GB • Aerospike 3.7.5
7. 7. 効率化のために・検討課題 24時間いつでも対応（夜やってくれとか言わない） リポジトリ単位でどれぐらいの需要設計が必要か コストのほとんどはネットワーク →お互いのためにGZIP圧縮に対応したハーベスティングを調達仕様レベルでは強制すべき resumptionTokenの扱い →1000万件のストリーム出力も可能だが 現実的には20,000件程度がデータサイズ的に扱いやすい 選択的ハーベスティングは日次更新を念頭に設計（全件でも十分に高速に動け!） →過去45日のみの対応とすることで月次にも十分対応できる システム更新などによる停止期間も1か月を超えることはない それ以上の期間の場合は全件ハーベスティングでよいのではないか expirationDate … 1時間程度 identifier のprefixはカーリルがよいか、各図書館がよいか （図書館のドメインはしばしば変更される→ JP-1123456.iss.ndl.jp / jp1123456.calil.jp / ogori.calil.jp） 所蔵ステータス(貸出状況)をメタデータに含めるべきか XMLのprettyは不要?