On Fri, Feb 12, 2010 at 8:05 AM, Martijn Tonies <m.tonies@stripped>wrote:
> Firebird uses 1 or multiple files per database, not per table, this file
> a special "blob area", so to speak, and the records include a "blob ID".
> When a client/stored routine selects a blob that isn't available in the
> data (stored "in between"), it then goes to the area where blobs are stored
> and gets it from there. Works quite well.
> As I said, a DBMS can do anything it likes with it's data as long as it
> it correctly.
As a matter of interest, FaceBook has basically written their own blob
engine for the storage of userpics. They basically append every new picture
to the end of a huge binary file (probably a raw device, really), and simply
put the start and end byte of the picture in an index.
Every webserver (you can imagine they have a few) that hasn't got a
requested image in it's local cache yet, then simply does a seek() to the
start byte and reads the necessary number of bytes to fetch the image.
Highly efficient, and very simple.
Also of interest is that they never actually clear images from the binary
storage - it would be too slow to reclaim the free space, and it's faster
and cheaper for them to just keep adding storage.
The main performance benefit of this over files-on-disk might well be that
you don't have the overhead of a filesystem, and thus no constant open/close
operations - the image serving daemon keeps the file open at all times.
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel