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.