[vworld-tech] Database usage

[Brian Crowder]

The real question for game developers, though, is "what is the latency 
of -one- transaction?".  A 200-600ms (and that would be pretty -good- in 
my experience) turnaround time (plus additional time to communicate over 
the network) before I can see the stats of an item in my inventory is 
unacceptable.  The degree to which we cache different types of data for 
the database, though, depends on what that latency demand is.  Some data 
is "cached" on the client, so that it can be interacted with 
near-instantaneously.  Some data is cached on the server, some data is 
cached in memory by a process -near- the server (memcached? or some 
custom service), some data is cached by the DB server itself, and some 
data (can I get an amen?) is actually read from disk by the DB server, 
before being available.

It's largely up to you to decide which is which, and how often each 
"cache" is updated, as well as to decide how authoritative each cache 
is.  Obviously, the client has no authority, and everyone up to the DB 
server itself will have varying amounts of authority.  Often, in fact, 
the DB (oracle or whatever) is probably wrong about what the state of 
the world is.  The less wrong it is, the better, since it will probably 
be the authority again if your game crashes.

The reason a lot of the discussion on this thread, thusfar, has perhaps 
led you to think we're calling DBs ineffecient or slow is because, for 
the real-time demands of a guy who needs to use his rocket-launcher to 
kill a baddie or die if he's too late, a DB query to find out if he HAS 
a rocket-launcher and enough ammo to use it, is unacceptably slow. 
(That's an exaggeration, especially for less-twitchy RPG games, but the 
parellels exist).

-- Brian

Arcus wrote:
> Having worked with many commercial database management systems, I can assure
> you that they are quite capable of handling information efficiently and
> quickly. To back this up, here is a link to some transaction counts for some
> of the major commercial players:
> 
> http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
> 
> Now, those are commercial systems and probably aren't going to be used by
> someone developing a hobby game or free MUD, but it does indicate how viable
> DB systems are for real time transaction processing. Most if not all major
> commercial MMORPGs rely heavily on DB transactions and are typically running
> off higher end databases and servers. Even scaling these numbers back will
> provide very good transaction numbers for some of the cheaper DBs such as
> Sql Server.
> 
> But as with all things, your mileage may vary. It is all going to come down
> to the tasks you are trying to accomplish and the architecture you are
> striving for. I think that the number of good solutions to the problem are
> great and quite varied. But even the best solution is no good if you don't
> have the resources to implement it. Anyway, I hope this has proven useful.
> 
> Regards,
> 
> Arcus
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> vworld-tech mailing list
> vworld-tech at cubik.org
> http://lists.cubik.org/cgi-bin/mailman/listinfo/vworld-tech