[MUD-Dev] World Persistence, flat files v/s DB v/s ??

[Adam Wiggins]

[Matt Chatterley:]
> On Sat, 21 Mar 1998, Ben Greear wrote:
> > The game will need to update it's persistant storage very often
> > to make this feasible. 
> > I'm a little concerned about the performance hit on a DB, as I expect
> > this game server to bring a machine to it's knees anyway...
> 
> A point to remember: Have the game *constantly* saving *small* amounts of
> data. Don't attempt to do what bases like PennMUSH do and dump a large
> amount of data at a regular interval - this causes quite a few problems
> (or rather, will if you are saving more than a few megabytes).

I never got around to trying that idea that came up here (I can't remember
who thought of it - maybe it was me) a while back, about having a parallel
process running which did nothing but take a snapshot of the DB every n
units of time and then dump them to disk in a leisurely manner.  This process
would not crash when your regular server would; instead it would just sit
there holding its latest snapshot.  When the server resurrected itself it
would request the DB snapshot back from the secondary process, and then
continue as normal.  Your disk writes could be as infrequent as you like;
I'd probably pass them to yet another process running at the lowest possible
priority, maybe even sending the data in chunked out spurts of like 500k.
But really, it shouldn't matter - short of the janitor tripping over the power
cord, the secondary process (which should, of course, never crash - a piece of
code that small should be easy to make bullet-proof) will just retain an
in-memory copy.  In theory you could update it as often as every ten seconds.

Naturally the only downside to this is that you essentially need double
the RAM, but I see this as a pretty small concession, considering the price
of memory these days.

Adam