[MUD-Dev] Unique items vs. item references

[Daniel.Harman at barclayscapital.com]

From: Brian Hook [mailto:brianhook at pyrogon.com]
 
> I've been dabbling with our little space adventure RPG in my spare
> time, and I'm now beginning to address the issue of inventory.
> I've got MySQL installed, but I'm torn as to whether it's overkill
> or not.  Part of me knows that having a database system that is
> indexed and allows for fast queries is important, but another part
> of me knows that it's a royal pain in the ass to have a machine
> with mysqld running, not to mention database table construction
> and editing.  Free text doesn't scale, but damn, it's handy.
 
> Anyway, one of the fundamental decisions we're going to face is
> whether to store item references to templates, along with some
> minor ancillary information (damage, charges, flags for "stolen",
> etc.), or whether to have fully unique items.  Obviously the
> latter requires a crap load more storage, but it's also more
> flexible in the long run.
 
> But since I don't have direct experience in this arena, I'd like
> to hear how others have addressed this.  I believe that this was
> apparently one of the defining differences between EQ and UO?

Well I obviously haven't worked on EQ or UO, but I have worked on
trading systems for banks where instrument lookups seem to fit into
a similar problem domain. In these instances we've used databases as
they facilitate clustering and reliability in a way that a flat file
can't. Not to mention referential consistency & backups.

Its pretty much a given that your server will need to build up a
cache of objects as whilst databases are pretty quick, we've found
the latency to be unacceptable for certain real time stuff. I
suspect that in most cases its unnecessary to be too smart with the
cache and its purging techniques, the ones I've seen only ever
support amendment of individual records & complete emptying. RAM is
just so cheap these days and the amount of data hasn't yet been a
problem.

One of the interesting things you may run into is database hotspots,
where certain areas of the disks end up seeing huge amounts of
action due to the way the queries and tables have been
structured. This can lead to contention issues and have a
detrimental affect on performance. Of course the beauty of having
this problem in a database rather than a flat file is that you can
see it happening, and restructure to fix it. Putting in metrics to
spot this kind of thing in a flat file system could be interesting.

Personally I like using base objects which individual instances can
override the properties of (ideally using deltas and not absolute
values (arguably the deltas should be multiplicative and not
absolute too ;) )). At least with this approach if you realise that
you need to change an item, you can just change the base and not
every instance. This is just my preference, but using the caching
described above performance shouldn't be an issue. As with all these
things though, you are going to have to benchmark it and see if its
fast enough. I could quote some database benchmarks at you that I've
observed, but I'm not sure how useful it would be as they are mostly
MSSql Server and Oracle with a grunty disk array. One thing of note
is that databases seem to like lots of concurrent requests which may
force you to multithread or use some form of async request. You
could also investigate batch queries if your RDBMS supports it and
you really need to improve things.

As an aside, the one flat file trading system I have observed scaled
really beautifully to 10 people. It then comprehensively failed to
support any more.

Dan




_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev