The goals of VCS (Visible Content Store) are to:
- Store information in standard SQL databases,
- Use "natural" object mapping to tables,
- Be fast,
- Support full-text searches on databases having that capability,
- Have some flexibility in the storage model to optimize certain cases at configuration time.
This section's sub-pages describe the architecture of VCS.
"Visible SQL" Structures
When using VCS, you can directly access all your data in pure SQL: the schema of the database is a mapping of the XSD schemas you defined in the Nuxeo configuration.
Easy Reporting
Because SQL data can be accessed directly, you may use any SQL reporting tool (Business Object, BIRT, Crystal Reports...) to build custom business reports on your documents data.
Easy Data Injection
For big data migration you can use direct SQL injection. Although we provide importer tools that will work on both JCR and VCS, it will never be as fast as bulk inserts can. Furthermore, in some cases, you don't want the people dealing with data migration to be Nuxeo developers: in this case, using plain SQL is an advantage.
Simple Debugging
Because data are transparently stored in SQL tables, it's very easy to have a look at them and understand exactly what data has been stored.
Easy Schema Migration
With VCS, schema changes in Nuxeo are automatically propagated to the SQL level (columns are added as needed, and you are warned about extra unused columns). If you change a field type, you can just do ALTER TABLE to change the column type.
Easy and Safe Hot Backup
You can hot backup your DB and then (i.e., after) hot backup the VCS binary store, data will be consistent:
- You have no risk of having a file being in process of update,
- You have no risk of having a file referenced by the DB that has been removed from the filesystem.
Some additional explanations on why VCS ensures safe hot backups.
Blob Storage
By default VCS stores all blobs on the filesystem in a lock-free, cluster-aware manner, based on the "Content-addressable storage" paradigm. Instead of the filesystem, you can also elect to store the blobs in Amazon S3 using the appropriate plugin.
You can also choose to store blobs in the database but we don't recommend it. In our experience storing blobs in the database leads to a lot of problems:
- Performances really drops,
- Some JDBC drivers load blobs in the JVM memory,
- Database backup/restore is very slow,
- Database sync (Master/Slave) is very very slow too.
If despite those recommendation you still want to take this architectural option, you can use the dedicated plugin available at https://github.com/nuxeo/nuxeo-core-binarymanager-sql/.