From: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
---|---|
To: | Arvind Singh <arvindps(at)hotmail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, PG laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
Subject: | Re: Improve MMO Game Performance |
Date: | 2012-10-14 01:57:39 |
Message-ID: | 507A1C13.1020008@ringerc.id.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 10/13/2012 07:52 PM, Arvind Singh wrote:
> we are all aware of the popular trend of MMO games. where players face
> each other live.
>
> My area of concern, is storage of player moves and game results.
> Using Csharp and PostgreSql
> The game client is browser based ASP.NET and calls Csharp functions
> for all database related processing
>
>
> To understand my query, please consider the following scenario
> /we store game progress in a postgres table./
I suspect that this design will scale quite poorly. As others have noted
it should work OK right now if tuned correctly. If you expect this to
get bigger, though, consider splitting it up a bit.
What I'd want to do is:
- Store data that must remain persistent in the main PostgreSQL DB;
things like the outcomes of games that have ended, overall scores,
etc.
- Use memcached or a similar system to cache any data that doesn't
have to be perfectly up-to-date and/or doesn't change much, like
rankings or player names;
- Use LISTEN / NOTIFY to do cache invalidation of memcached data
if necessary; and
- Store transient data in `UNLOGGED` tables with `async_commit` enabled,
a long `commit_delay`, etc. Possibly on a different DB server. You'll
certainly want to use different transactions to separate your
important data where durability matters from your transient data.
I'd run two different Pg clusters with separate table storage and WAL,
so the transient-data one could run with the quickest-and-dirtiest
settings possible.
I might not even store the transient data in Pg at all, I might well use
a system that offers much weaker consistency, atomicicty and integrity
guarantees.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2012-10-14 02:13:55 | Re: database corruption questions |
Previous Message | Jasen Betts | 2012-10-14 00:13:03 | Re: Postgres DB Migration from 8.3 to 9.1 |