Making Relational Databases Work
Database storage is ideal, but in practice not easy to do correctly.
Most relational Databases (like MySQL) are not well suited to storing binary files. In fact, many don't work well even with 64KB blobs. Normalisation of a schema reduces the size of rows (and increases the amount of tables to spread out locking) so that scanning of records is faster. Large blobs slow this down.
For this reason, any file storage within a relational database should be normalised to an additional table separate to all of the other fields. For example:
- UserVideos - ID, UserVideoFileID, UserID, VideoTitle, VideoDescription, Tags, etc...
- UserVideoFiles - ID, UserVideoFileBlobID, UploadedFileName, FileSize, MIME, Extension, VideoCodec, AudioCodec
- UserVideoFileBlobs - ID, Blob
With the right database system, you should be able to store the UserVideoFileBlobs table in a separate Database File, with a specialised backup regimin. You can also partition. MySQL might have a suitable file storage engine (I don't think so).
Instead of UserVideoFileBlobs, you might instead of File Storage or Cloud Blob storage (like S3). File storage is quite ideal, because you can also make it directly downloadable via HTTP alleviating load on your database.
Sqlite seems to brag about being better at storing files than a file system. But backups are probably still challenging. You might use multiple sqlite files as you might normally use file folders
Recommendation - S3.