RE: Storing blobs in database vs filesystem

> So, I'd take this into account very carefully when you decide to
go for the FS solution. Restoring millions of files to a FS is pretty mujch akin re-inserting row by row in the database. The filesystem backup is a 'logical' backup, like exportfile, and 'logical' recovery resembles import, without array processing features to speed things up. Filesystems are not very efficient in creating tons of files, they're mainly build for efficient I/O to the contents of the files (Kevin, correct me if I got it wrong). So, unless you can 'dd' the disks as a backup, the recovery secenario is a serious threat to your solution, if not a showstopper, even when you have a complete flat directory structure or
can backup 'physical'.

I wouldn't say that filesystems are built for efficient I/O to the contents of files. Actually, once
a file is open, most of the hard work of a filesystem is over. Depending on how files are
allocated (maps, extents, whatever), the positioning and read/write calls are really no big deal. It is
the manipulation of file attributes that is tough for files. I'd say there are not many (if any)
filesystems that can readily handle millions of files in a directory. Video rendering farms
do often times need such structure, so we are working on optimizations for such here, but
that is not our bread and butter either.

--
http://www.freelists.org/webpage/oracle-l