On Mon, Jun 13, 2016 at 06:30:46PM +1000, Andrew McN wrote:
I find that article unconvincing, but my concerns are
performance. If performance is of no concern at all, then the
atomicity/maintenance argument might be significant (though not the
stuff about storing as a text data type).
I'm not convinced either. Same as I'm never convinced by the recurring
idea of using an SQL database as a mail-storage backend.
IMO the best option is to use a database to store information about the
image (path and filename or URI, size, width, height, geo-location,
description, and whatever other details are required. Maybe even a
small thumbnail image), whilst storing the actual image in either:
- a filesystem, with a hashed directory structure to avoid having too
many files in one directory. e.g.
If you're worried about the image pathname getting out of sync with
the database, you could write your own FUSE fs layered on top of the
actual fs to automatically update the database if a file is renamed
BTW, there are FUSE modules for perl and python to make this easier
if you don't want to use C.
- An object store like Amazon S3, Openstack's swift, or ceph.
BTW, there are existing FUSE modules for these that could be modified
to update a database if an object is changed.
For a very large number of images, an object store is the best
option...you get hugely scalable performance, redundancy, and storage
craig sanders <cas(a)taz.net.au>
BOFH excuse #302:
microelectronic Riemannian curved-space fault in write-only file system