> From: Tim Walberg [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 30, 1999 9:58 AM
>
> On 07/30/1999 09:34 -0700, Roeland M.J. Meyer wrote:
> >> how the RDBMS is implemented. However, I don't think
> anyone does RAW
>
> Don't know about under Linux, but I know of a number of sites
> still using
> raw for databases (granted, I don't think any of them are on
> Oracle, they're
> all either Sybase or Informix).
I'll bet you a small amount of change that they are either legacy sites,
or designed by legacy designers <grin>. There is no cost/benefit to
using RAW anymore. Not enough benefit to make it worth the trouble.
> >> anymore. Image archives, for anyone doing a production
> implementation,
> >> isuslaly served up as BLOBs, under an RDBMS (back to
> the RDBMS case).
>
> I wasn't thinking of images only in the graphical sense -
> we've got a server
> where we keep large images of databases (kind of a fast
> rollback/recovery
> solution - don't ask).
Okay, I won't <yuck>
> >> This gives us case 1 and 2 as special/rare-use cases
> and drops RDBMS and
> >> FTP servers into case 3.
> >>
> >> What do you think?
>
> Another way of looking at it is:
> 1) constant (or near constant, anyway) medium IO block
> size mostly
> sequential access (corresponds to 1 above)
> 2) small random access (corresponds to 2 above)
> 3) large sequential access (3 above)
> 4) random size random access (4 above)
>
> I guess I might concur that 1 may have features in common
> with any of 2-4,
> depending on what exactly the DBMS is doing - small vs large tables,
> small vs large updates, etc. Where 1 tends to be different, is in the
> fact that the kernel buffer cache is usually bypassed in this case, so
> the characteristic I/O patterns may be significantly different because
> of the use of different caching and write gathering
> algorithms. I don't
> know if there's a big enough difference to worry about, but I
> don't know
> there isn't either. That's why I always recommend benchmarking several
> different configs.
I'd rather say the folks using RAW had better know what they're doing.
The problem with documenting RAW is that it is always
implementation-dependent and/or custom work. Every RDBMS vendor does it
different. It's like hand optimizing assembler code. The optimizers are
good enough that no one does it anymore becasue the maintenance cost is
higher than any percieved gain, beyond what the optimizers will give
you. The same is true for modern file systems. RAW doesn't buy you very
much, anymore.
> I still think 2-4 are sufficiently different, though - 2 and
> 3 are very
> optimized for particular purposes, and 4 is less optimized,
> just designed
> so that everything works as well as can be expected.
