Firstly, I’m not talking about a full-blown database that’s serving
files, but a lightweight front to the files (as PBMS is). PBMS is just
an HTTP front to a storage engine for MySQL, and doesn’t deal with SQL
or anything like that. It’s really like serving the content directly
out of a large file, in a pretty similar way to many caches do.
Ordinarily, the filesystem will be much faster than even the lightest of
fronts to a db, but if you have milllions of files, then each file will
have metadata associated with it (which takes up space - usually at
least 4KB) and the filesystem has to cope with all the files, and many
filesystems struggle when you start getting to large numbers of files,
and it slows things down.
If you have billions of files, then you couldn’t even serve them off a
normal 32-bit fs, because you’d run out of inodes (I believe).
For thousands of files, or tens of thousands, you’d be fine, though, and
the filesystem will definitely be quicker than PBMS.
When I did my tests with PBMS, I created 2M objects, and put them in the
database with MySQL, then served them using PBMS. My benchmarks showed
that the number of req/s I could serve was similar to Apache 2 at best,
and about 20% slower at worst (it depended on the index of the file).
That might not seem great, but that was serving from 1 file vs 2M. I
tried creating files in a hierarchical structure, and after I got to
around 400k (? I can’t quite remember), my system almost completely
stalled, so I stopped trying to add files.
In most scenarios, the filesystem will be quicker, but not always.