Hi,
Georgi Chulkov wrote:
> Please allow me to ask then:
> 1. In your opinion, would the above scenario indeed benefit from a raw-device
> interface for large objects?
No, because file systems also try to do what you outline above. They
certainly don't split sequential data up into blocks and distribute them
randomly over the device, at least not without having a pretty good
reason to do so (with which you'd also have to fight).
The possible gain achievable is pretty minimal, especially in
conjunction with a (hopefully battery backed) write cache.
> 2. How feasible it is to decouple general table storage from large object
> storage?
I think that would be the easiest part. I would go for a pluggable
storage implementation, selectable per tablespace. But then again, I
wouldn't do it at all. After all, this is what MySQL is doing. And we
certainly don't want to repeat their mistakes! Or do you know anybody
who goes like: "Yepee, multiple storages engines to choose from for my
(un)valuable data, lets put some here and others there...".
Let's optimize the *one* storage engine we have and try to make that
work well together with the various filesystems it uses. Because
filesystems are already very good in what they are used for. (And we are
glad we can use a filesystem and don't need to implement one ourselves).
Regards
Markus