On Mon, Jun 13, 2016 at 06:30:46PM +1000, Andrew McN wrote:
> On 13/06/16 17:21, James Harper wrote:
> > https://wiki.postgresql.org/wiki/BinaryFilesInDB

> I find that article unconvincing, but my concerns are mostly around
> 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.

   .../images/{00-ff}/{00-ff}/{00-ff}/imagefile.png

   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
   or moved.

   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
capacity.

craig

--
craig sanders <cas@taz.net.au>

BOFH excuse #302:

microelectronic Riemannian curved-space fault in write-only file system

_______________________________________________
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main