On Fri, Feb 12, 2010 at 8:05 AM, Martijn Tonies <m.ton...@upscene.com>wrote:
> Firebird uses 1 or multiple files per database, not per table, this file > has > 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 > record > 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 > returns > 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
