Storage Engines

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. 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.

Relational Databases - MySQL/MariaDB, PostgreSQL, MS SQL, Oracle, SQLite and other relational databases that process standard SQL queries and have PHP PDO drivers will eventually be supported. For now, just MySQL/MariaDB is supported though. 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 or webDAV (HTTP or HTTPS) file system or S3 bucket 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. Eventually it will be possible to store any content in the File System with SQLite serving as a Relational Database.
Property-Value Store (aka NoSQL or Document Storage) - MongoDB, Amazon DynamoDB, etc.