[Coldstuff] SQL...

[Brad Roberts]

While it might be simple to replace the genesis storage layer (of which
gdbm is just a small part, the indexes) with a similar layer that stuffs
the data into a sql server's blobs, that still doesn't give you any sane
mechanism for doing any sort of clustered work.  Genesis caches data until
either a checkpoint or a forced cache eviction to load another object.
This means that in the mean time, data is only visible to the process that
has the cached data.  The only way to get coherence across multiple
genesis processes accessing the same sql back end would be a distributed
lock manager and some very careful cache invalidations.  This enters into
the realm of _highly_non-trivial_ work.

There's a reason high end database servers like Oracle Parallel Server,
Informix Extended Parallel Server and IBM's DB2 cost an arm and a leg.. :)

For HA you want several things, the primary of which is 100% on disk
database consistency.  Genesis doesn't guarantee this except possibly for
the instant at then end of the cache flush before the async backup kicks
in and the regular event loop resumes.  I've put quite a bit of thought
into how to make genesis able to keep the on disk data consistent, but its
a lot of work that I won't likely be doing any time soon without some
serious convincing, probably in the form of a bribe.  That said, on disk
coherency is still orders of magnitude easier than cache coherency across
multiple nodes in a cluster.

SQL servers are good for some things, but they're far from the panacea that
people seem to make them out to be.

Later,
Brad

On Mon, 11 Feb 2002, Jon A. Lambert wrote:

> Date: Mon, 11 Feb 2002 23:37:17 -0500
> From: Jon A. Lambert <jlsysinc@ix.netcom.com>
> Reply-To: coldstuff@cold.org
> To: coldstuff@cold.org
> Subject: RE: [Coldstuff] SQL...
>
> > elh@astroarch.com wrote
> > Subject: Re: [Coldstuff] SQL...
> >
> > Well to be specific, an SQL database so that I can use a form of database clustering
> > without affecting coldcore in any way. This could be for an HA cluster or for a
> >  beowulf cluster, etc.
> >
>
> It's fairly trivial to write an SQL backend for Cold.
> Or I should say to write a trivial backend of this sort:
>
> Cold DB
>   key        data
>   objectid   blob/image
>
> But then GDBMS will outperform it anyways.
> No benefits of relational are realized except possibly distribution.
>
> It is NOT trivial to map the Cold object model to a relational model.
> One reason is Cold objects are runtime dynamic.  Relational database
> schemas are not runtime dynamic... well they are not designed to be
> efficient in changing schemas although most now at least support
> dynamic DDL.
>
> In fact very few ODBMSs will  handle the dynamic nature of the Cold
> model.
>
> Database clustering or distribution should be handled transparent to
> Cold, but the available features and implementation vary quite a bit
> among RDBMSs.
>
> Yes, go to Mud-dev and search the archives.
> Lot's of good mud DB info there. :-)
>
> --
> --* Jon A. Lambert - TychoMUD        Email:jlsysinc@ix.netcom.com *--
> --* Mud Server Developer's Page <http://tychomud.home.netcom.com> *--
> --* If I had known it was harmless, I would have killed it myself.*--
>
> _______________________________________________
> Cold-Coldstuff mailing list
> Cold-Coldstuff@cold.org
> http://web.cold.org/mailman/listinfo/cold-coldstuff
>