database vs filesystem performance

[Christopher Browne]

On 8/7/05, Marc Lijour <marc-bbkyySd1vPWsTnJN9+BGXg at public.gmane.org> wrote:
> 
> On August 7, 2005 21:39, Christopher Browne wrote:
> > On 8/7/05, Marc Lijour <marc-bbkyySd1vPWsTnJN9+BGXg at public.gmane.org> wrote:
> > > Does somebody know the compared performance of the filesystem against 
> a
> > > RDBMS?
> >
> > Do you mean for storage of BLOBs? (Binary Large OBjects)
> >
> > There is likely to be somewhat more overhead for BLOBs in a DBMS than 
> there
> > is in storing the data in files in a filesystem as there are likely to 
> be
> > more things that they will be linked to in a DBMS.
> 
> Is it smart then to convert binary as human readable hex strings?
> It is likely to increase storage and what about performance (speed)?


That sort of conversion will *definitely* increase the cost in both storage 
consumption as well as performance.

You can uuencode the data (or something equivalent); that'll be pretty 
expensive for each transition.

It would be seriously tempting to use the DBMS's own BLOB support, whiich 
would eliminate that transition.

> Mind you, filesystems and DBMSes have been converging in how they 
> implement
> > storage of data, as most of the modern systems use blocks and extents
> > whether we're talking about a "database" or a "filesystem."
> >
> > Storing the data in a DBMS is a sword that cuts on both edges; on the
> > useful side, BLOBs can be managed in a transactional fashion, which may 
> be
> > helpful to reliability of your application. (And if that's needful, it 
> may
> > be worth some overhead.) On the "other cutting edge," interfacing tends 
> to
> > be a bit of a pain, as the files won't be transparently available from 
> the
> > shell level.
> 
> I don't need concurrency control.


That cuts out one of the possible benefits of storing as BLOB.

> Informix was trying to push this usage of Version 10 of their database, 
> and
> > doubtless pushed out some benchmarks.
> >
> > You're doubtless better off constructing a benchmark for your own use 
> case,
> > as that's the only way you'll get a useful comparison.
> 
> That is a nice idea. I am just curious -I can not afford to be more than 
> that
> because the design choices in this case come from far above myself :-)


Unfortunately, you can only get a good feel for the tradeoffs by doing at 
least a partial implementation.
-- 
http://www3.sympatico.ca/cbbrowne/linux.html
"The true measure of a man is how he treats someone who can do him
absolutely no good." -- Samuel Johnson, lexicographer (1709-1784)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/legacy/attachments/20050808/e7947005/attachment.html>