4 ms·
There are a lot of things your FS is not going to give you (eg. transactions), and if you're going to have to query it anyway to get that, you might as well hav
by thezilch 11y ago
There are a lot of things your FS is not going to give you (eg. transactions), and if you're going to have to query it anyway to get that, you might as well have your blob there too.
For "small" blobs, say <256K, your database is probably faster too. I can only recall one such study (and of only NTFS vs MSSQL), and NTFS was only advantageous at >1MB blobs: http://research.microsoft.com/pubs/64525/tr-2006-45.pdf http://research.microsoft.com/pubs/64525/tr-2006-45.pdf
- taf2 11y agoalso operationally it's easier... you can rely on replication to backup those files instead of separate scripts that would need to work in-conjunction with the database replication. If say you have the database with blobs - you can restore the db and everything is back up and running. If instead, you need to also restore the individual files... well - not only do you have lots of individual disk writes, you also have to make sure you still have all the files...
- rakoo 11y agoEven better from the SQLite page (https://www.sqlite.org/intern-v-extern-blob.html https://www.sqlite.org/intern-v-extern-blob.html), comparing storing content in SQLite versus storing content in files and filenames in SQLite. The bonus of mixing both is that you get all niceties from a SQL store (transactions, using SQL to query...). The takeaway is that for content < 20K you should use SQLite, and for content < 100K you should also use it with possibly some tuning to do.