RE: Storing blobs in database vs filesystem

From: Matthew Zito <mzito_at_gridapp.com>
Date: Fri, 29 Sep 2006 16:02:22 -0400
Message-ID: <C0A5E31718FC064A91E9FD7BE2F081B178B75A@exchange.gridapp.com>

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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Dennis Williams

	Sent: Friday, September 29, 2006 3:43 PM
	To: Jared Still
	Cc: dubey.sandeep_at_gmail.com; 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

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

Received on Fri Sep 29 2006 - 15:02:22 CDT