[MUD-Dev] The grass is always greener in the other field

Bruce Bruce
Thu Dec 16 10:41:51 CET 1999


Raph Koster wrote:
>No, it isn't. It's a blessing, in that it means we can tackle the problem
>with a localized solution targeted at house storage. Because the real
>problem is database bloat. It's what has always brought full world-state
>muds to their knees, and UO is no exception, suffering from long backup
>times, huge backup sizes, and lower responsiveness because of gigabytes
>worth of useless crap stored away in houses. Don't underestimate just how
>much people want to keep around that serves no valid game purpose. Being
>able to stash it somewhere where it won't be found isn't going to help you
>the admin any. :)


I think that this problem (storage of objects that are being hoarded or
otherwise stored away, outside of common day-to-day usage) can be solved on
the technology side of things.  This is surely a problem for a system that
attempts to load the entire DB into memory.  A disk-based system wouldn't
have this problem.  However, a disk-based system in the tradition of
Cold/Genesis would still have the problem with large backups due to the
monolithic nature of the database.

A log-structured would appear to be potentially beneficial here as only
changes would need to be saved, making incremental backups much easier.
That introduces a few extra issues: collapsing the logs, etc, but those are
all well researched.  This would may not be a good solution for all of the
database needs as the log files could end up being far larger than the usual
DB files, if the objects were involved in frequent state changes.

Another potential solution might be to use separate databases for varying
types of classes of objects.  In this way, you can store things like homes
in a separate DB which has a set of policies aimed at providing a more
optimal storage strategy.

 - Bruce





_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list