Underlying a repository is one or more storage engines, which store repository content types (schema) and objects (content) and provide create, query, read, update and delete functionality.
Different storage engines can be utilized, mixed and matched to balance their strengths and weaknesses. For example relational databases optimize query speeds. File systems or property-object stores scale-out and lower costs. A file system can simplify implementation and maintenance. All storage engines are integrated into the overall COMAND repository schema.
Files, databases and values can all be retrieved with their corresponding commands, query languages and web services for a transparent view of how the data is stored and for low-level backup and manipulation. However, high-level features, such as cQL and cPath make low-level operations unnecessary and obsolete in typical application development.
The following storage engines are available. Follow the bulleted links to learn about the specific format used by each.
- Relational Databases - MySQL, PostgreSQL, MS SQL, Oracle and other relational databases that process standard SQL queries and have PHP PDO drivers are supported. Relational databases are most commonly used as the primary (and often only) storage engine for a COMAND repository because they are efficient, widely available, well understood and supported.
- File System - A local, network, FTP, SFTP, webDAV (HTTP or HTTPS) file system can be used to store information. File system storage is well-suited for content that is not typically used in a query condition and contains large values, such as video. However, any content can be stored in the File System with SQLite serving as a Relational Database.
- Property-Value Store (aka NoSQL and Cloud Storage) - MongoDB, Amazon , etc.