DSpace システム説明書: ストレージ層

DSpaceはリレーショナルデータベースを使って、コンテンツの編成に関するすべての情報、コンテンツに関するメタデータ、e-personと権限に関する情報、現在処理中のワークフローの状態を保管しています。また、DSpaceシステムは、ブラウズ用のインデックスもリレーショナルデータベースで管理しています。

リレーショナルデータベースの構成図

DSpaceが使用する機能のほとんどは、トランザクションをサポートする標準的なSQLデータベースならどれでも提供しているものです。ただし、現在のところ、ブラウズ用インデックスにはPostgreSQLとOracleに固有の機能を使用しています。従って、他のデータベースシステムを使ってDSpaceを完全に機能させるには、プログラムを若干修正する必要があると思われます。

org.dspace.storage.rdbmsパッケージを使用するとJDBCを直接使用するよりいくらか簡単な形でSQLデータベースにアクセスすることができます。主要なクラスは、DatabaseManagerです。これは、SQLクエリを実行して、TableRowオブジェクト、または、TableRowIteratorオブジェクトを返します。 InitializeDatabaseクラスは、たとえばスキーマの設定など、JDBCを介してSQLをデータベースにロードする際に使用します。

DatabaseManagerを呼び出す際には常に DSpaceのContextオブジェクトを必要とします。データベースマネージャAPIの使用例は、org.dspace.storage.rdbmsパッケージのJavadocに紹介されています。

DSpaceが使用する（PostgresSQLのための）データベーススキーマはソースディストリビューションの[dspace-source]/etc/database_schema.sqlにあります。スキーマはSQLの形で配布されていますので、直接DBMSに投入してデータベースを構築することができます。また、このスキーマSQLファイルは、システムを正常に機能させるために必要な2つのe-personグループも直接作成しています。

[dspace-source]/etcには、database_schema_1x_1yという名前の様々なSQLファイルも含まれています。これらのファイルは、既存のDSpaceデータベースをバージョン1.xから1.yにバージンアップするために必要なSQLコマンドが含まれています。システムのバージョンアップ作業はこれだけではないことに注意してください。詳しくは、バージョンアップの方法を参照してください。

DSpaceデータベース操作プログラムは、SQL関数getnextidを使って、新規作成されたレコードに主キーを付与しています。このSQL関数は、複数のJVMがデータベースを同時にアクセスする場合にも安全に使用できなければなりません。たとえば、アイテムのバッチ一括登録と同時にWebユーザインターフェースがデータベースに新規レコードを作成する可能性があるからです。このメソッドのPostgreSQL固有の実装では、各テーブルの新規IDを作成するために「シーケンス」を使用しています。他のデータベースシステムを使用する場合は、そのDBMSで稼働するようにgetnextidの実装を変更することになるでしょう。

ソースディストリビューションのetcディレクトリには、その他に2つのファイルがあります。 clean-database.sqlには、データベースを完全にクリアするために必要なSQLが入っていますので、注意して使用してください。これを実行するには、Antのclean_databaseターゲットを使うことができます。 update-sequences.sqlには、主キー生成シーケンスを適当な値にリセットするためのSQLが入っています。たとえば、バックアップデータベースダンプからデータベースをリストアした結果、定義済の主キーを持つレコードが作成された場合に、これを実行する必要があるでしょう。この場合、既に使用されている主キーをシーケンスが割り当てるかもしれないからです。

Oracle用の*.sql*ファイルは[dspace-source]/etc/oracleにあります。インストールの前に、これらのファイルを[dspace-source]/etcにコピーして、PostgreSQL用のファイルを置き換える必要があります。

メンテナンスとバックアップ

PostgreSQLを使用する場合、パフォーマンスを最適化するために、定期的に "vacuum" を実行することを勧めます。これは、vacuumdbコマンドを "cron" ジョブとして実行することにより実現できます。たとえば、次の行をシステムのcrontabに追加します。

# clean up the database nightly          （訳注: 毎晩データベースを掃除する）
40 2 * * * /usr/local/pgsql/bin/vacuumdb --analyze dspace >/dev/null 2>&1

DSpaceのデータベースは、pg_dumpや psqlを使用して、通常の方法でバックアップとリストアをすることができます。ただし、データベースをリストアする際には、さらに次の処理を行う必要があります。

fresh_installターゲットを実行すると、ダブリンコア・レジストリとビットストリームフォーマット・レジストの初期内容をロードし、epersongroupテーブルに2つのエントリ、anonymous と administrator グループを設定する。バックアップデータからデータベースをリストアする前に、これらを削除する必要がある。これらはバックアップデータ中に、おそらく修正した形で、存在するからである。たとえば、次のSQLを使用する。
```
DELETE FROM dctyperegistry;
DELETE FROM bitstreamformatregistry;
DELETE FROM epersongroup;
```
バックアップデータをリストアした後、主キー生成シーケンスをリセットして、既存の主キーを生成しないようにする必要がある。これを行なうには [dspace-source]/etc/update-sequences.sqlにあるSQLを実行する。たとえば、次のようにする。
psql -U dspace -f [dspace-source]/etc/update-sequences.sql



    DSpaceの将来のバージョンアップではデータベーススキーマに若干の変更がなされるかもしれません。その場合は、既存のデータを生かしたままスキーマを変更する方法が提供されるでしょう。
また、現行スキーマは、現在使用されていないデータベースカラムをいくつか含んでいます。これらは、将来のリリースで提供される追加機能で使用されるものです。
これらの未使用のカラムはバージョンアップに必要な作業をできるだけ少なくするためにあらかじめ追加されています。

    RDBMSコンポーネントの設定

    データベースマネージャは dspace.cfgにある次のプロパティを使って設定します。

    
     
      
        db.url
        データベースにアクセスするために使用するJDBC URL。
DSpaceはすでにコネクションプールを実装しているので、ここでコネクションプールを指定してはならない。
      
      
        db.driver
        JDBCドライバのクラス名。現在のところ、DSpaceは PostgreSQL 固有の機能を使っているので、これは org.postgresql.Driverとする。
      
      
        db.username
        データベースにアクセスする際に使用するユーザ名。
      
      
        db.password
        データベースにアクセスする際に使用するユーザのパスワード。
      
     
    


    ビットストリームの保存

    DSpaceはコンテンツを保存する2つの方法を提供しています。1つはサーバ上のファイルシステムに置く方法です。もう1つはSRB（Storage Resource Broker）を使用しています。両者は、シンプルな軽量APIを使って実現されています。

  SRBの使用はまったく任意ですが、サーバのファイルシステムの代わりに、あるいはファイルシステムと共に使用することができます。 詳しくは説明しませんが、SRBはきわめて堅牢かつ精巧なストレージ管理システムであり、基本的に無限のストレージと、ローカルやリモートにある他のストレージ資源のコンテンツを複製（簡単な言葉で言えば、バックアップ）する簡単な方法を提供します。

  以下で使用される「格納する」、「検索する」、「システムにおける」、「ストレージ」などの用語は、（「従来の」）サーバ上のファイルシステムとSRBの両ストレージに適用することできます。


    BitstreamStorageManagerはシステムに格納されているビットストリームへの低レベルアクセスを提供します。ただし、一般に、これを直接使用すべきではありません。
    代わりに、コンテンツ管理APIで定義されているBitstreamオブジェクトを使用してください。 
なぜなら、このオブジェクトは、BitstreamStorageManagerでは管理されていないビットストリームに関する権限やその他のメタデータをカプセル化しているからです。

    ビットストリーム・ストレージ・マネージャは、ビットストリームを格納、検索、削除する3つのメソッドを提供します。
ビットストリームは「ID」で参照されます。このIDは、データベースにある対応するレコードの主キーbitstream_idカラムの値です。

  DSpaceバージョン1.1から、複数のビットストリーム格納場所を持つことができるようになりました。これらのビットストリーム格納場所は従来のストレージ、あるいは、SRBストレージのいずれにも置くことができます。これは、DSpaceシステムで使用可能なストレージが、1つのディスクやファイルシステムの最大サイズによる制約をうけないこと、および、従来のストレージとSRBストレージを1つのDSpaceシステムで組み合わせて使用できることを意味します。両ストレージは設定パラメタで指定することができます。以下のビットストリーム格納場所の設定も参照してください。

    格納場所は番号付けされており、0から1ずつカウントアップします。データベース上の各ビットストリームエントリは格納番号を持っており、要求されたビットストリームを検索する際に使用されます。

    現在のところ、新規のビットストリームを置く格納場所は、設定パラメタを使って決定されており、格納場所間でビットストリームを移動する方法は用意されていません。
ビットストリームと格納場所を操作する管理ツールは将来のバージョンで提供する予定です。
現在でも格納場所全体を移動することはできます。（たとえば、格納番号1を/localdisk/storeから/fs/anotherdisk/storeへ移動することができます。ただし、移動後も格納番号は1であり、また、まったく同じ内容を持たなければなりません。）

    ビットストリームは、ビットストリームテーブルレコードの主キーIDとは別に、38桁の内部IDを持ちます。
これはビットストリーム・ストレージ・マネージャ以外では見ることも使用されることもありません。
従来のストレージあるいはSRBストレージにおいてビットストリームが実際に格納される場所（対応する格納ディレクトリからの相対位置）を決めるために使用されます。
最初の3組の2桁の数字はビットストリームが格納されるディレクトリパスです。
ビットストリームは内部IDをファイル名とするファイルに格納されます。

    たとえば、内部IDが 12345678901234567890123456789012345678であるビットストリームの格納場所は、次のとおりです。

    （格納ディレクトリ）/12/34/56/12345678901234567890123456789012345678

    この方法でファイルを格納する理由は以下のとおりです。

    
      ランダムに生成した38桁の数字を使用すると、順番に割り当てられ互いに隣接する主キーを単純に使用する場合に比べて「番号空間」があまり固まらない。
これは、ビットストリームが格納場所のディレクトリにばらばらに分布することになり、アクセス効率が改善されることを意味する。

      内部IDをファイル名として使用する理由は、1つは、ビットストリームのファイル名を改めて検索する手間を省くためであり、1つは、ビットストリームを様々なオペレーティングシステムから受け取る可能性があるためです。この場合、ビットストリームのオリジナルファイル名はUNIXのファイル名としては不正になる可能性があります。
    

     ビットストリームを格納する際、BitstreamStorageManagerは、対応するデータベーステーブルレコードの以下のフィールドを設定します。

    
      bitstream_id
      size
      checksum
      checksum_algorithm
      internal_id
      deleted
      store_number
    

    その他のフィールドは Bitstreamコンテンツ管理APIクラスの責任です。

    ビットストリーム・ストレージ・マネージャは完全にトランザクションセーフです。
    トランザクションセーフを実装するために、次のアルゴリズムを使ってビットストリームを格納しています。

    
      現在のDSpaceコンテクストにおけるアクティブなコネクションとは別に、新規にデータベースコネクションを作成する。.
      ユニークな内部識別子を（データベースの主キーとは別に）生成する。
      （1）で作成した新規コネクションを使って、ビットストリームテーブルのレコードを作成し、deletedカラムに trueを設定する。
      新規コネクションを commitして、「削除済の」ビットストリームレコードをデータベースに書き込む。
      「情報資産格納ディレクトリ」として設定したディレクトリの下に、ビットストリームそのものを、内部IDから得たディレクトリパスとファイル名で格納する。
      ビットストリームレコードの deletedフラグを falseに設定する。すると、このレコードは現在のDSpace Contextの一部となる。
    

    これは、ビットストリーム格納の前、最中、後で何らかの失敗があった場合、次のうちどれか1つだけが正しいことを意味します。

    
      ビットストリームテーブルレコードは作成されず、ファイルも格納されなかった。
      deleted=trueであるビットストリームテーブルレコードが作成されたが、ファイルは格納されなかった。
      deleted=trueであるビットストリームテーブルレコードが作成され、ファイルも格納された。
    

    これらはいずれもデータベースやビットストリームに格納されているデータの完全性に影響を与えません。

    同様に、何らかの理由でビットストリームが削除される場合、トランザクションの一環としてdeletedフラグがtrueに設定されますが、対応するストレージ上のファイルは削除されません。

    以上の技法は、ビットストリーム・ストレージ・マネージャがトランザクションセーフであることを意味します。
時間がたつと、ビットストリームデータベーステーブルとファイル格納場所は多くの「削除済みの」ビットストリームを持つことになるかもしれません。
BitstreamStorageManagerのcleanupメソッドを実行すると、削除済みのレコードを捜して、これらのレコードとストレージに残っている該当するビットストリームファイルを実際に削除します。
ただし、格納作業中にcleanupが実行されるといけないので、削除されるのは1時間以上古い「削除済み」ビットストリームだけです。

    このファイルの掃除は、コマンドラインでCleanupクラスを実行しても行うことができますが、/dspace/bin/cleanupを使ってサーバマシンのシェルから容易に実行することもできます。
cronを使ってこれを定期的に実行することもできますが、DSpaceは読み込みに比べて書き込みはそれほど多くないので、それほど頻繁に実行する必要はないでしょう。

    バックアップ

    従来のストレージに格納されたビットストリーム（ファイル）は、assetstoreディレクトリ（dspace.cfgで設定したディレクトリ）を単にtarコマンドあるいはzipコマンドで圧縮するだけで簡単にバックアップすることができます。
リストアはバックアップした圧縮ファイルを適当な場所で解凍するだけで簡単です。

  同じ方法をSRBでも使用することができますが、SRBはバックアップ処理に関するもっと多くの選択肢を提供しています。


    ビットストリーム・ストレージ・マネージャは、ビットストリームはストレージに、ビットストリームに関する情報はデータベース上に保持しているので、データベースのバックアップとビットストリームファイルのバックアップは同時に行う必要があることに注意することが重要です。
データベース上のビットストリームデータは格納されたファイルと一致する必要があるからです。

    もちろん、データベースとファイルの一致を保証するためにバックアップの間システムを「フリーズ」することが望ましいわけがありません。
DSpaceは、データベースにあるビットストリームデータを信頼すべき記録として使用するので、データベースをファイルより先にバックアップするべきです。
これは、ストレージ上にビットストリームはあるがデータベース上にはない（DSpaceにとっては事実上存在しない）という状況の方が、データベース上にビットストリームレコードはあるがストレージ上にビットストリームがないという状況より望ましいからです。なぜなら、後者の場合、ビットストリームを見つけることはできてもコンテンツを実際に入手することができないことを意味するからです。


    ビットストリーム格納場所の設定

    従来のビットストリーム格納場所およびSRBビットストリーム格納場所の両者は、dspace.cfgで設定します。

    従来のストレージの設定

    サーバ上のファイルシステムにおけるビットストリーム格納場所（「情報資産格納場所」とも呼ぶ）は次のように設定します。

  assetstore.dir = [dspace]/assetstore


  （[dspace]は、DSpaceをインストールした実際のディレクトリ名で置き換えることを思い出してください。）

    上の例では、1つの情報資産格納場所を指定しています。

    assetstore.dir = [dspace]/assetstore_0
assetstore.dir.1 = /mnt/other_filesystem/assetstore_1


    この例では、2つの情報資産格納場所を指定しています。assetstore.dir は情報資産格納番号 0（ゼロ）を指定します。その後は、assetstore.dir.1、assetstore.dir.2 などを使用します。
ビットストリームが格納されている情報資産格納場所はデータベースで管理されているので、ビットストリームを別の情報資産格納場所に移動したり、番号を付け換えたりしてはいけません。

    デフォルトでは、新規に作成されたビットストリームは情報資産格納場所0（すなわち、assetstore.dirプロパティで指定した場所）に置かれます。
これは、DSpace 1.1より前の版への後方互換性を持たせるためです。
情報資産格納場所0が満杯になった場合などで、これを変更するには、dspace.cfgに次のような1行を追加します。

    assetstore.incoming = 1

    そして、DSpace（Tomcat）をリスタートします。すると、新規ビットストリームは、assetstore.dir.1で指定した情報資産格納場所に、上の例では、/mnt/other_filesystem/assetstore_1に置かれるようになります。

  SRBストレージの設定

  SRBストレージの設定にも同じフレームワークが使用されます。すなわち、情報資産格納番号（0..n）は、上記のとおりファイルシステム上のあるディレクトリを参照したり、一組のSRBアカウントパラメタを参照したりすることができます。ただし、どの情報資産格納番号もどちらか1つを参照することができるだけで、両方を参照することはできません。この方法により、従来のストレージとSRBストレージを同時に使用することはできますが、異なる情報資産番号を持つことになります。上で述べた次の注意事項はSRB情報資産格納場所にも同じく適用されます: あるビットストリームが格納される情報資産格納場所はデータベースに管理されているので、別の場所に移動したり、格納番号を付け替えたりしてはいけません。

  たとえば、情報資産格納番号1がSRBを参照するとします。この場合、次のような一組のSRBアカウントパラメタを設定することになります。
  srb.host.1 = mysrbmcathost.myu.edu
srb.port.1 = 5544
srb.mcatzone.1 = mysrbzone
srb.mdasdomainname.1 = mysrbdomain
srb.defaultstorageresource.1 = mydefaultsrbresource
srb.username.1 = mysrbuser
srb.password.1 = mysrbpassword
srb.homedirectory.1 = /mysrbzone/home/mysrbuser.mysrbdomain
srb.parentdir.1 = mysrbdspaceassetstore


  mcatzoneのようないくつかの用語はSRBの文脈でのみ意味を持つもので、SRBのユーザにはおなじみでしょう。最後のsrb.parentdir.nは、SRBアカウント内で追加の（SRB）上位ディレクトリ構造を使用する場合に使用します。このプロパティの値は空白でもかまいません。

  （情報資産格納場所0がSRBを参照する場合は、上で述べた従来のストレージの設定と合わせるために、srb.host = ..., srb.port = ..., など、（.0を取って）指定します。）

  情報資産格納番号0（デフォルト）あるいは1..n（明示的プロパティ）を参照するために同じassetstore.incomingを使用することは、新規のビットストリームが従来のストレージに置かれるか、SRBストレージに置かれるかが、サーバ上のファイルシステムのディレクトリが参照されるか、一組のSRBアカウントパラメタが参照されるかにより決まることを意味しています。

  従来のストレージとSRBストレージの設定についてのより詳しい説明が、dspace.cfgにコメントとして書かれています。


    

    
 	 Copyright © 2002-2005 MIT and Hewlett Packard

`db.url`	データベースにアクセスするために使用するJDBC URL。 DSpaceはすでにコネクションプールを実装しているので、ここでコネクションプールを指定してはならない。
`db.driver`	JDBCドライバのクラス名。現在のところ、DSpaceは PostgreSQL 固有の機能を使っているので、これは `org.postgresql.Driver`とする。
`db.username`	データベースにアクセスする際に使用するユーザ名。
`db.password`	データベースにアクセスする際に使用するユーザのパスワード。