have a look at OMERO then. that's what it does - it's a metadata manager. (fundamentally though, any DB is a front end to a filesystem anyway...- even if it is it's own "special" FS)
On Tue, Jun 14, 2016 at 4:12 PM, Craig Sanders via luv-main < [email protected]> wrote: > 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 <[email protected]> > > BOFH excuse #302: > > microelectronic Riemannian curved-space fault in write-only file system > _______________________________________________ > luv-main mailing list > [email protected] > https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main > -- Dr Paul van den Bergen
_______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
