Page History
...
System
...
Architecture: Storage Layer
In this section, we explain the storage layer: the database structure, maintenance, and the bistream store and configurations.
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
RDBMS / Database Structure
DSpace uses a relational database to store all information about the organization of content, metadata about the content, information about e-people and authorization, and the state of currently-running workflows. The DSpace system also uses the relational database in order to maintain indices that users can browse.
...
| Wiki Markup |
|---|
Versions of the *_.sql{_}* files for Oracle are stored in _\[dspace-source\]/dspace/etc/oracle_. These need to be copied over their PostgreSQL counterparts in _\[dspace-source\]/dspace/etc_ prior to installation. |
Maintenance and Backup
When using PostgreSQL, it's a good idea to perform regular 'vacuuming' of the database to optimize performance. This is performed by the vacuumdb command which can be executed via a 'cron' job, for example by putting this in the system crontab:
...
- The fresh_install target loads up the initial contents of the Dublin Core type and bitstream format registries, as well as two entries in the epersongroup table for the system anonymous and administrator groups. Before you restore a raw backup of your database you will need to remove these, since they will already exist in your backup, possibly having been modified. For example, use:
Code Block DELETE FROM dctyperegistry; DELETE FROM bitstreamformatregistry; DELETE FROM epersongroup;
Wiki Markup After restoring a backup, you will need to reset the primary key generation sequences so that they do not produce already-used primary keys. Do this by executing the SQL in _\[dspace-source\]/dspace/etc/update-sequences.sql_, for example with:
Future updates of DSpace may involve minor changes to the database schema. Specific instructions on how to update the schema whilst keeping live data will be included. The current schema also contains a few currently unused database columns, to be used for extra functionality in future releases. These unused columns have been added in advance to minimize the effort required to upgrade.Code Block psql -U dspace -f [dspace-source]/dspace/etc/update-sequences.sql
Configuring the RDBMS Component
The database manager is configured with the following properties in dspace.cfg:
db.url | The JDBC URL to use for accessing the database. This should not point to a connection pool, since DSpace already implements a connection pool. |
db.driver | JDBC driver class name. Since presently, DSpace uses PostgreSQL-specific features, this should be org.postgresql.Driver. |
db.username | Username to use when accessing the database. |
db.password | Corresponding password ot use when accessing the database. |
Bitstream Store
DSpace offers two means for storing content. The first is in the file system on the server. The second is using SRB (Storage Resource Broker). Both are achieved using a simple, lightweight API.
...
This cleanup can be invoked from the command line via the Cleanup class, which can in turn be easily executed from a shell on the server machine using /dspace/bin/cleanup. You might like to have this run regularly by cron, though since DSpace is read-lots, write-not-so-much it doesn't need to be run very often.
Backup
The bitstreams (files) in traditional storage may be backed up very easily by simply 'tarring' or 'zipping' the assetstore directory (or whichever directory is configured in dspace.cfg). Restoring is as simple as extracting the backed-up compressed file in the appropriate location.
...
With DSpace 1.7 and above, there is also the option to backup both files and metadata via the AIP Backup and Restore feature.
Configuring the Bitstream Store
Both traditional and SRB bitstream stores are configured in dspace.cfg.
Configuring Traditonal Storage
Bitstream stores in the file system on the server are configured like this:
...
Then restart DSpace (Tomcat). New bitstreams will be written to the asset store specified by assetstore.dir.1, which is /mnt/other_filesystem/assetstore_1 in the above example.
Configuring SRB Storage
The same framework is used to configure SRB storage. That is, the asset store number (0..n) can reference a file system directory as above or it can reference a set of SRB account parameters. But any particular asset store number can reference one or the other but not both. This way traditional and SRB storage can both be used but with different asset store numbers. The same cautions mentioned above apply to SRB asset stores as well: The particular asset store a bitstream is stored in is held in the database, so don't move bitstreams between asset stores, and don't renumber them.
...
Overview
Content Tools