DSpaceはリレーショナルデータベースを使って、コンテンツの構造に関するすべての情報、コンテンツに関するメタデータ、e-パーソンと権限に関する情報、現在処理中のワークフローの状態を保管しています。 また、DSpaceシステムは、ブラウズ用の索引をメンテナンスするためにもリレーショナルデータベースを使用しています。
DSpaceが使用する機能のほとんどは、トランザクションをサポートする標準的なSQLデータベースならどれでも提供しているものです。 ただし、現在のところ、十分実用的となったオープンソースのリレーショナルデータベースシテムであるPostgreSQLに固有の機能をブラウズ用索引で使用しています。 従って、他のデータベースバックエンドを使ってDSpaceを完全に機能させるには、プログラムを若干修正する必要があると思われます。
org.dspace.storage.rdbmsパッケージを使用するとJDBCを直接使用するよりいくらか簡単な形でSQLデータベースにアクセスすることができます。
主要なクラスは、DatabaseManagerです。これは、SQLクエリを実行して、TableRowオブジェクト、または、TableRowIteratorオブジェクトを返します。
InitializeDatabaseクラスは、たとえばスキーマの設定など、JDBCを使ってSQLをデータベースにロードする際に使用します。
DatabaseManagerの呼び出しの際には常に DSpaceのContextオブジェクトを必要とします。
データベースマネージャAPIの使用例は、org.dspace.storage.rdbmsパッケージのJavadocに紹介されています。
DSpaceが使用するデータベーススキーマはソースディストリビューションのetc/database_schema.sqlにあります。
スキーマはSQLの形で配布されていますので、直接DBMSに投入してデータベースを構築することができます。
また、スキーマSQLファイルでは、システムを正常に機能させるために2つのe-パーソングループを直接作成しています。
データベーススキーマを示す図のPDFファイルもこの説明書に含まれています。
DSpaceデータベース操作プログラムは、SQL関数getnextidを使って、新規作成されたレコードに主キーを付与しています。
このSQL関数は、複数のJVMがデータベースを同時にアクセスしている場合にも安全に使用できなければなりません。たとえば、アイテムの一括登録を実行中に、ウェブユーザインターフェースでデータベースに新規レコードを作成する場合などが考えられます。
このメソッドのPostgreSQL固有の実装では、各テーブルの新規IDを作成するために「シーケンス」を使用しています。
他のデータベースバックエンドを使用する場合は、使用するDBMSで稼働するようにgetnextidの実装を修正することになるでしょう。
ソースディストリビューションのetcディレクトリには、その他に2つのファイルがあります。
clean-database.sqlには、データベースを完全にクリアするために必要なSQLが入っていますので、使用には注意してください。Antのclean_databaseターゲットを使ってこれを実行することができます。
update-sequences.sqlには、主キー生成シーケンスを適当な値にリセットするためのSQLが入っています。
これは、たとえば、バックアップしたデータベースダンプデータをリストアして定義済の主キーを持つレコードを作成する場合などに実行する必要があるでしょう。この場合、既に使用されている主キーをシーケンスが割り当てるかもしれないからです。
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 グループを追加する。
バックアップデータからデータベースをリストアする前に、これらを削除する必要がある。
なぜなら、これらはバックアップデータ中に、おそらく修正した形で、存在するからである。
たとえば、次のようにする。
DELETE FROM dctyperegistry; DELETE FROM bitstreamformatregistry; DELETE FROM epersongroup;
バックアップデータをリストアした後、主キー生成シーケンスをリセットして、既存の主キーを生成しないようにする必要がある。
これを行なうには etc/update-sequences.sqlにあるSQLを実行する。たとえば、次のようにする。
psql -U dspace -f etc/update-sequences.sql
DSpaceの将来のバージョンではデータベーススキーマを若干変更する予定です。 既存のデータを生かしたままスキーマを変更する方法については、別に手順書を提供する予定です。 また、現行のスキーマには現在使用されていないデータベースカラムをいくつか含んでいます。これは、将来のリリースで提供される追加機能で使用する予定です。 これらの未使用のカラムはバージョンアップに必要な作業をできるだけ少なくするためにあらかじめ追加してあります。
データベースマネージャは dspace.cfgにある次のプロパティを使って設定します。
db.url |
データベースにアクセスするために使用するJDBC URL。 DSpaceはすでにコネクションプールを実装しているので、ここでコネクションプールを指定してはならない。 |
db.driver |
JDBC ドライバのクラス名。現在のところ、DSpaceは PostgreSQL 固有の機能を使っているので、これは org.postgresql.Driverとする。 |
db.username |
データベースにアクセスする際に使用するユーザ名。 |
db.password |
データベースにアクセスする際に使用する対応するパスワード。 |
DSpaceは現在のところコンテンツを単にサーバ上のファイルシステムに保存しているだけです。これは、簡単で軽量なAPIを使って実現しています。
BitstreamStorageManagerはシステムに保存されたビットストリームへの低レベルアクセスを提供しています。
一般に、これを直接使用するべきではなく、代わりに、コンテンツ管理APIで定義されているBitstreamオブジェクトを使用します。
なぜなら、オブジェクトにカプセル化されているビットストリームに関する権限やその他のメタデータがBitstreamStorageManagerでは管理されていないからです。
ビットストリーム保存マネージャは、ビットストリームを保存、検索、削除する3つのメソッドを提供します。
ビットストリームは「ID」で参照されます。このIDは、データベースにある対応するレコードの主キーbitstream_idカラムの値です。
DSpaceバージョン1.1から、複数のビットストリーム格納場所を持つことができるようになりました。 これは、DSpaceシステムで使用可能なストレージが、1つのディスクやファイルシステムの最大サイズによる制約をうけなくなったことを意味します。
格納場所は番号付けされており、0から1ずつカウントアップします。データベース上の各ビットストリームエントリは、格納番号を持っており、要求されたビットストリームを検索する際に使用されます。
現在のところ、新規のビットストリームを置く格納場所は、設定パラメタを使って決定されており、格納場所間でビットストリームを移動する方法は用意されていません。
ビットストリームと格納場所を操作する管理ツールは将来のバージョンで提供する予定です。
現在のところ、格納場所全体を移動することができます。（たとえば、格納番号1を/localdisk/storeから/fs/anotherdisk/storeへ移動することができます。ただし、移動後も格納番号は1であり、また、まったく同じ内容を持たなければなりません。）
ビットストリームは、ビットストリームテーブルレコードの主キーIDとは別に、38桁の内部IDを持ちます。 これはビットストリーム保存マネージャ以外では見ることも使用されることもありません。 ファイルシステムにおいてビットストリームが実際に格納される場所（対応する格納ディレクトリからの相対位置）を決めるために使用されます。 最初の3組の2桁の数字はビットストリームが格納されるディレクトリパスです。 ビットストリームは内部IDをファイル名とするファイルに格納されます。
たとえば、内部IDが 12345678901234567890123456789012345678であるビットストリームの格納場所は、次のとおりです。
（格納ディレクトリ）/12/34/56/12345678901234567890123456789012345678
ファイルをこの方法で格納する理由は以下のとおりです。
ランダムに生成した38桁の数字を使用すると、順番に割り当てられるので互いに隣接する主キーを単に使用する場合に比べて「番号空間」があまり固まらない。 これは、格納場所におけるビットストリームがディレクトリ構造に分散されて分布することにより、アクセス効率が改善されることを意味する。
内部IDをファイル名として使用するのは、1つは、ビットストリーム名をあらためて検索する手間を省くためであり、1つは、ビットストリームはさまざまなオペレーティングシステムから受け取るが、ビットストリームのオリジナル名がUNIXのファイル名としては不正な場合があるからである。
ビットストリームを格納する際、BitstreamStorageManagerは、以下のフィールドを対応するデータベーステーブルレコードに設定します。
bitstream_idsizechecksumchecksum_algorithminternal_iddeletedstore_numberその他のフィールドは Bitstreamコンテンツ管理APIクラスの責任です。
ビットストリーム保存マネージャは完全にトランザクションセーフです。 トランザクションセーフを実装するために、ビットストリームの格納には次のアルゴリズムが使用されています。
deletedカラムに trueを設定する。commitして、「削除済の」ビットストリームレコードをデータベースに書き込む。deletedフラグを falseに設定する。すると、このレコードは現在のDSpace Contextの一部となる。これは、ビットストリーム保存の前、最中、後で何らかの失敗があったとしたら、次のうちのどれか1つになることを意味しています。
deleted=trueであるビットストリームテーブルレコードが作成されたが、ファイルは格納されなかった。deleted=trueであるビットストリームテーブルレコードが作成され、ファイルも格納された。これらはいずれもデータベースやビットストリームに格納されるデータの完全性に影響を与えません。
同様に、何らかの理由でビットストリームが削除される場合は、トランザクションの一環としてdeletedフラグが設定されますが、対応するファイルシステム上のファイルは削除されません。
以上の技法は、ビットストリーム保存マネージャがトランザクションセーフであることを意味します。
時間がたつと、ビットストリームデータベーステーブルとファイル格納場所は多くの「削除済み」ビットストリームを持つことになるかもしれません。
BitstreamStorageManagerのcleanupメソッドを実行すると、削除済みのレコードを捜して実際に削除すると同時に、ファイルシステム上に残っている対応するビットストリームファイルも削除します。
ただし、格納作業中にcleanupが実行されるといけないので、1時間以上古い「削除済み」ビットストリームだけを削除します。
このファイルの掃除は、コマンドラインでCleanupクラスを実行してもできますが、/dspace/bin/cleanupを使ってサーバマシンのシェルから容易に実行することもできます。
cronを使って定期的にこれを実行することもできますが、DSpaceは読み込みに比べて書き込みはそれほど多くないので、それほど頻繁に実行する必要はないでしょう。
ビットストリーム格納場所のビットストリーム（ファイル）は、単に、assetstoreディレクトリ（dspace.cfgで設定したディレクトリ）をtarコマンドあるいはzipコマンドで圧縮するだけで簡単にバックアップすることができます。
リストアは単にバックアップした圧縮ファイルを適当な場所で解凍するだけです。
ビットストリーム保存マネージャは、ビットストリームはファイルシステム上に、ビットストリームに関する情報はデータベース上に保持しているので、データベースのバックアップとビットストリームファイルのバックアップは同時に行う必要があることに注意することが重要です。 データベース上のビットストリームデータは格納されたファイルと一致する必要があるからです。
もちろん、データベースとファイルの一致を保証するためにバックアップの間、システムを「凍結」することは実際には望ましくありません。 DSpaceは、データベースにあるビットストリームデータを信頼できる記録として使用しますので、ファイルより先にデータベースをバックアップするべきです。 これは、ファイルシステム上にビットストリームはあるがデータベース上にはない（DSpaceにとっては事実上存在しない）という状況の方が、データベース上にビットストリームレコードはあるがファイルシステム上にはないという状況より望ましいからです。なぜなら、後者の場合、ビットストリームを見つけることはできてもコンテンツを実際に入手することができないことを意味するからです。
ビットストリーム格納場所（「情報資産格納場所」とも言う）は、dspace.cfgで設定できます。たとえば、
assetstore.dir = /dspace/assetstore
この例では、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に出力されるようになります。