[MUD-Dev] Is database access a bottleneck?

[Amanda Walker]

On 12/13/02 12:05 AM, Dave Rickey <daver at mythicentertainment.com> wrote:

> You don't get faster and lower-overhead than a pre-cached
> flatfile.  I say this as a former DBA and client-server programmer
> of some experience myself.

One of the things I learned while doing work with streaming media
encryption was that sometimes timing is more important that
restartability.  If you're updating a client, and something gets
dropped, you don't roll back and reapply it--you overwrite it,
because the previous state is now irrelevant.

This is one important way in which games, and other media delivery
systems, are unlike traditional database/transaction systems.

Traditional DBMSs, for good reasons, concentrate on restartability
and aggregate throughput, but most (including Oracle) do not provide
real-time response times.  For real-time processing (which a lot of
game data handling must be at any large scale), nothing beats data
that's pre-indexed in RAM.  This could mean a preloaded flat file,
it could mean a hybrid approach (like the new fad of running a
traditional DBMS with the indices on a RAMdisk), whatever.  If you
fail, you roll back to the last checkpoint and players gripe a bit,
but you maintain response time during operation.

The disk/RAM tradeoff is at a very different point than it was even
a year or so ago.  One of the servers in my basement can hold 8GB of
RAM.  Modern servers can hold quite a bit more, and it's darned
affordable these days.  It is entirely reasonable, if your data set
is of such a size, to throw it all into RAM and treat your disk as a
checkpoint/backup medium.  As long as you stage your writes to disk
so that you can recover to a consistent state when you restart from
a checkpoint, life is good.

Amanda Walker


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