On Mon, Jan 08, 2007 at 01:07:38PM +0100, chefren wrote:
> >(1) You won't see any benefit until *all* applications have been rewritten
> >to use these new semantics instead of traditional ones. That means new
> >versions of oracle, mysql etc.
> 
> Yes and no, the database filesystem should have an own SQL layer. It's 
> "nuts" to let have Oracle or MySQL own caches of data on your disk.

Are you saying that the O/S and filesystem layer should entirely *replace*
the need for a database? If so, I can't believe that will ever happen.

Firstly, it eliminates the choice that we currently have: say mysql versus
Oracle versus BerkeleyDB versus pgsql etc. Each application currently can
choose an appropriate database given constraints of DB size, speed, indexing
algorithms, ease of administration etc. It sounds like you're proposing a
"one size fits all" alternative.

Secondly, there are hundreds of person-years of development in something
like Oracle. Developing a new database for the O/S is very unlikely to catch
up. Not only the database core, but hundreds of tools and admin utilities
would need to be written to get up to the same level as existing offerings
(commercial and free).

Thirdly, SQL is about as "standard" as the Hayes AT command set. Each
database has its own variant. So if you were forced to moved from (say)
Oracle to this new mythical O/S database, all your *applications* would need
changing too. It is probably this more than anything which makes people
stick with one database over another.

Finally, have you seen how big the distribution set is for (say) Oracle? If
your O/S came bundled with that, then you'd need four or five CDs for a
basic install.

It *might* make sense to add some hooks into the O/S; take an existing
database; and modify it to make use of those hooks for improved filesystem
coherence or to integrate with filesystem snapshots. But I don't think it
makes sense to write a new database from scratch in the O/S, nor for the O/S
to force every system to have a database whether it wants it or not.

> If you want a secure data server that's easy to backup and mirror all 
> data should be synced by the OS not by applications.

Well, that's your opinion, but I disagree.

If you have Oracle databases, in the current state-of-the-art you back them
up using Oracle mechanisms (such as taking snapshots and copying transaction
logs). This gives you a mechanism which Oracle can support; that is, they
guarantee your data security if you follow their methods. They only need to
make minimal demands of the underlying O/S filesystem to meet these
requirements. Indeed, the underlying database storage container could be a
raw disk partition, or it could be a file served over NFS (I've seen the
latter with Oracle and NetApp)

Your solution suggests that Oracle should hand over all responsibility for
data backup to the operating system. Now, as good as OpenBSD is, as a user I
would not accept that situation.

> All data should be stored in one basic layer, not multiple.

You can have the database write directly to a raw disk partition. That gives
you a single layer. It leaves the database doing what it's good at, and the
O/S doing what it's good at.

> The basic database filesystem could be open so others might adapt it 
> as a storage layer too.

Have you any proposal as to what the API and semantics of this database
filesystem might be? That is, if not open(), read(), write(), close() then
what else? Would it talk a SQL dialect directly? Without such a proposal,
it's hard to make specific comments.

Disclaimer: I am not a database expert, nor a filesystem expert. However I
have implemented some systems which use databases.

Brian.

Reply via email to