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

[Greg Munt]

On Sat, 21 Mar 1998, Ben Greear wrote:

> The game will need to update it's persistant storage very often
> to make this feasible. 
> 
> In my current game, I use ascii based flat files.  I don't think
> this will work so well for the space game.

In the TinyMUD that I ran, the database was saved as an ASCII flat file, 
with objects delimited by ^H. The database was dumped at regular intervals.
There was a noticable drop in performance when a large database was 
dumped. Various methods were tried to overcome this problem, ranging from 
running the DB dump as a child process, to the use of dumping cycles 
(saving n kilobytes, pausing for a few seconds, then saving a bit more, etc)

The only real solution was to install more physical memory. The database 
was reasonably persistent, seeing as the most recent dump available was 
no more than 30 minutes old (if the database was dumped every 30 minutes).
 
> The two things I'm pondering now are binary flat files (one per object,
> a collection of objects?? I dunno) or a database.

I'm not sure of the advantages of binary flat files over ASCII ones. I 
would certainly advise the use of a cache, however. (Something which that 
TinyMUD never used.)

> 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...

Not all databases use SQL. Some are even 'fast' - I believe that dbm 
falls into this category, although there are issues with database 
corruption that may need to be considered. Take a look at the FreeDB 
list. Personally, I may take a look at a few, and design my own. This is 
really only for the 'fun' value, though :) I probably won't save the 
entire DB, but only objects which have changed since the last save.

I would most definitely be interested in discussions of various database 
models, as used by various list members. The format of the physical DB 
file is of most interest right now, although retrieval speed, algorithms 
and cache handling would also be of relevance - as would 'standards', and 
standard DB models, none of which I can remember the names of right now.

> I'd be interested to hear any suggestions you might have.. > 
> Also, as a java server, I don't think I can do a select on incomming
> data.  I think a thread for every player is a bit much...any suggestions
> here?

I do not know Java (yet) - but I would agree that a thread for every 
socket is not the way to go.

> Ben Greear (greear at cyberhighway.net)  http://www.primenet.com/~greear 
> Author of ScryMUD:  mud.primenet.com 4444
> http://www.primenet.com/~greear/ScryMUD/scry.html

[Bored of ScryMUD already?;)]

--
Greg Munt, greg at uni-corn.demon.co.uk; http://www.uni-corn.demon.co.uk/ubiquity/
"Deliver yesterday, code today, think tomorrow."