GridFS is a convention for storing & retrieving large files in MongoDB. The default document size limit of 16MB is not applicable to GridFS and thus making it possible to store larger files.
The files are stored in chunks. The default chunk size is 255kb. A media streaming server can be implemented with the help of GridFS. Since the files are stored in chunks, seeking the media player to desired time frame is possible without much efforts.
We've used GridFS to store documents & images. GridFS coupled with java web services has made it easier for us to maintain secure access to these documents & images.
While these were a few brief advantages of using GridFS, we'll discuss the pros & cons associated with GridFS in detail :
Since the files are stored in chunks, retrieving the file is a bit resource intensive as each chunk has to be assessed & merged to form the whole file. This also makes the update operation non-atomic due to lack of transactions in MongoDB.
To overcome this atomicity issue, one solution would be to store the updated file as a new file in GridFS and once the operation is complete update the reference from the old file to the new one. If the files to be stored have a size restriction which is less than 16 MB then instead of going with GridFS, one can store the file as a binary blob directly into the MongoDB document so that atomicity can be ensured during update operations (Single document operations are atomic).
For optimal performance, deploy a dedicated instance of GridFS in your infrastructure configured with optimal chunk size depending on the nature of files to be stored.
MongoDB and thus GridFS have in-built support for indexing, sharding & replication. Thus a carefully configured GridFS deployment would lower the overhead of configuring & maintaining the stored files across various geo-locations.
The files are stored in chunks. The default chunk size is 255kb. A media streaming server can be implemented with the help of GridFS. Since the files are stored in chunks, seeking the media player to desired time frame is possible without much efforts.
We've used GridFS to store documents & images. GridFS coupled with java web services has made it easier for us to maintain secure access to these documents & images.
While these were a few brief advantages of using GridFS, we'll discuss the pros & cons associated with GridFS in detail :
Since the files are stored in chunks, retrieving the file is a bit resource intensive as each chunk has to be assessed & merged to form the whole file. This also makes the update operation non-atomic due to lack of transactions in MongoDB.
To overcome this atomicity issue, one solution would be to store the updated file as a new file in GridFS and once the operation is complete update the reference from the old file to the new one. If the files to be stored have a size restriction which is less than 16 MB then instead of going with GridFS, one can store the file as a binary blob directly into the MongoDB document so that atomicity can be ensured during update operations (Single document operations are atomic).
For optimal performance, deploy a dedicated instance of GridFS in your infrastructure configured with optimal chunk size depending on the nature of files to be stored.
MongoDB and thus GridFS have in-built support for indexing, sharding & replication. Thus a carefully configured GridFS deployment would lower the overhead of configuring & maintaining the stored files across various geo-locations.
