>>On Fri, Feb 12, 2010 at 8:05 AM, Martijn Tonies <m.tonies@stripped>
>>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
>>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
>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
Sounds logical, what's also nice to see, is that even though people here
tend to say "don't put binaries in the database", apparently Facebook
thought it would be nice to do so (for all sorts of reasons) and even took
the time to write their own blob storage mechanism ;-)
Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Firebird!
Database questions? Check the forum: