RE: Storing blobs in database vs filesystem

  • From: "Matthew Zito" <mzito@xxxxxxxxxxx>
  • To: <oracledba.williams@xxxxxxxxx>, "Jared Still" <jkstill@xxxxxxxxx>
  • Date: Fri, 29 Sep 2006 16:02:22 -0400

This is how we did things at, back in the day.  We had ~14m
blob objects that represented domain name information for things like
DNS, WHOIS, etc. and instead of pulling that data in and out of the
database constantly, we used UTL_FILE to dump the zonefiles out to a
Netapp filer upon create/modify/delete, and then had the piles of
servers pull the content directly off the filer.  Reduced load on the
databases, kept one path for information, and the only downside was
managing the deletion of objects, which required some batch jobs and the
I'm a big believer in "cheap" vs. "expensive" processing.  Oracle is
almost always expensive processing, while other options may or may not
be cheap processing.  


        From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Dennis Williams
        Sent: Friday, September 29, 2006 3:43 PM
        To: Jared Still
        Cc: dubey.sandeep@xxxxxxxxx; ORACLE-L
        Subject: Re: Storing blobs in database vs filesystem
        Jared Said: Reduce licensing costs?  How is that?
        Obviously depends on the architecture, so that is why I said
"opportunity". If the blobs are stored in Oracle, then you must license
Oracle on a server large enough to serve the entire application. If the
Java application executes on the application server and the database
only stores the path to the graphic object and other information about
the object, then you have the opportunity to put the big files on a
separate fileserver, and tune it for serving the files. I haven't tried
this, but it seems like it should work. 
        Dennis Williams

Other related posts: