GridFS Binary Storage

Cloud CMS supports MongoDB GridFS by allowing it to serve as a backend provider for the storage of binary files within Cloud CMS.

When files are uploaded to Cloud CMS, they are parsed and worked with and then eventually sent over to Amazon S3 for persistence. When users seek to download those binary files, they are streamed back from S3.

Depending on how you elect to configure your binary storage providers, Cloud CMS may employ an TTL cache in between to avoid going back to the binary storage provider on repeated invocations.

Configuring

Adjusting the Binary Storage Provider used by Cloud CMS is a system-wide change and will therefore require that you run Cloud CMS on-premise. SaaS subscribers do not have the ability to adjust the Binary Storage provider.

For information on how to adjust the Binary Storage Provider within an On-Premise or Docker installation, please see our documentation on Configuring the GridFS Binary Storage Provider.

Notes and Recommendations

It is important to understand that the GridFS binary storage provider saves its binary files into the MongoDB database. As you add binary files to Cloud CMS, the size of your MongoDB investment will grow. This means your backups will grow larger and your volume/storage requirements for MongoDB will grow as well.

For production systems, we recommend that you separate the storage of binary files from the database. An optimal system, in our view, is one in which the database is kept down to a minimal size. This helps reduce costs for database storage and backup and it also reduces I/O overhead over time. Fewer file handles, fewer IOPS and so on.

GridFS is configured as the default binary storage provider and is perfectly suitable for development and test installations of Cloud CMS. For production, we recommend using a separate binary store such as Amazon S3, IBM Cloud Object Storage, Microsoft Azure Blob Storage or even a shared file system mount.