RE: Storing blobs in database vs filesystem
- From: "Kevin Closson" <kevinc@xxxxxxxxxxxxx>
- To: "ORACLE-L" <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 3 Oct 2006 11:50:40 -0700
> 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.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
