On 1/8/07 4:27 PM, Brian Candler wrote:
On Mon, Jan 08, 2007 at 01:07:38PM +0100, chefren wrote:
Are you saying that the O/S and filesystem layer should entirely *replace*
the need for a database?
Yes.
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.
And why do you forget the single OpenBSD choice named: FFS?
> 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.
Yep, because you definitely want to be able to interchange data
between everything.
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).
The web replaces large parts of thousands of development years in
Windows applications and that's possible in a few years.
More integration cannot be reached by more glue, sometimes you have to
replace a part that's too old. For example FFS.
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.
Do you still use the Hayes AT command set? It's replaced by better
ways of doing things. Why should we perpetually stick data cluelessly
in files that are in directories and so on.
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.
The database file system I'm after is elegant and can be distributed
with OpenBSD.
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.
To get it started we should add some hooks of course, and when it's
working FFS should be dumped. Of course the database file system can
still save "blobs", being Oracle database or whatever.
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).
Yep. And that's on top of the OS&filesystem that makes the server
itself run...
> 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.
I want to eliminate the need for Oracle or whatever other databases...
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.
That could also be a starter, take PostgreSQL or another database and
boot from it. However, in practice it's far less work to start from
scratch.
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.
We believe in a new handy language (Pyton like?) commands for the new
features, SQL like commands and things like open(), read(), write(),
close() for compatibility mode.
Disclaimer: I am not a database expert, nor a filesystem expert. However I
have implemented some systems which use databases.
No problem you seriously mention sensible things and that's what
counts for me.
Although a little off topic it's good to think about a better way to
do the things we do. Computers are still in there infancy and more or
less like carriages with a horse eating ASCII in front.
+++chefren
