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.
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 ;-)
With regards,
Martijn Tonies
Upscene Productions
http://www.upscene.com
Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Firebird!
Database questions? Check the forum:
http://www.databasedevelopmentforum.com
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
