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 Register.com, 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
like.
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.
Matt
________________________________
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:
