From oracle-l-bounce@freelists.org Fri Aug 12 17:54:55 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j7CMstAd024322 for ; Fri, 12 Aug 2005 17:54:55 -0500 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air891.startdedicated.com (8.12.10/8.12.10) with ESMTP id j7CMsrIP024311 for ; Fri, 12 Aug 2005 17:54:53 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 937841DD4B2; Fri, 12 Aug 2005 17:54:46 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16585-04; Fri, 12 Aug 2005 17:54:46 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id E52121DCB12; Fri, 12 Aug 2005 17:54:45 -0500 (EST) Message-Id: <6.2.1.2.2.20050813084520.051e8ef0@pop.mail.yahoo.com.au> Date: Sat, 13 Aug 2005 08:52:48 +1000 To: Dennis Williams From: Tony Jambu Subject: Re: Anyone with experience with MMOG and databases? Cc: Oracle-L@freelists.org In-Reply-To: References: <6.2.1.2.2.20050812232259.04c24928@mail.labyrinth.net.au> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_80425686==.ALT" X-archive-position: 23915 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: tjambu_freelists@yahoo.com.au Precedence: normal Reply-To: tjambu_freelists@yahoo.com.au X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at avenirtech.net X-mailscan-MailScanner-Information: Please contact the ISP for more information X-mailscan-MailScanner: Found to be clean X-MailScanner-From: oracle-l-bounce@freelists.org X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on air891.startdedicated.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.63 --=====================_80425686==.ALT Content-Type: text/plain; charset="us-ascii" Hi Dennis You are spot on in your proposed approach. I was not involved in the game design. Only the database side of things. You can only influence so much of the code now. As you can see from the discussions, there are very application (MMOG) specific issues that you dont normally come across with high OLTP or OLAP type environments. I am trying to find out what are the common issues with an MMOG data repository. ta tony At 03:36 AM 13/08/2005, Dennis Williams wrote: >Tony, > > >Looking at a system that will be requiring 10,000+ simple writes per sec and 20,000+ semi simple reads per sec. > > >Interesting problem area. Why would you need to write that much to persistent storage (database)? My assumption is that you would just have some shared server processes that have a shared memory area. You only need to persist what must survive a server shutdown (or crash). In either case you'll lose all your active players, and they can start again. If that is not adequate, you might have some savepoints people could restart from. When a player first logs in you'll need some information about them, perhaps their preferences. My point is that slight compromises to the requirements can vastly reduce the database and server requirements. > >Dennis Williams > > --=====================_80425686==.ALT Content-Type: text/html; charset="us-ascii" Hi Dennis


You are spot on in your proposed approach.  I was not involved in the
game design. Only the database side of things.  You can only influence
so much of the code now.

As you can see from the discussions, there are very application (MMOG)
specific issues that you dont normally come across with high OLTP or
OLAP type environments.  I am trying to find out what are the common
issues with an MMOG data repository.

ta
tony


At 03:36 AM 13/08/2005, Dennis Williams wrote:
Tony,


Looking at a system that will be requiring 10,000+ simple writes per sec and 20,000+ semi simple reads per sec.

 
Interesting problem area. Why would you need to write that much to persistent storage (database)? My assumption is that you would just have some shared server processes that have a shared memory area. You only need to persist what must survive a server shutdown (or crash). In either case you'll lose all your active players, and they can start again. If that is not adequate, you might have some savepoints people could restart from. When a player first logs in you'll need some information about them, perhaps their preferences. My point is that slight compromises to the requirements can vastly reduce the database and server requirements.
 
Dennis Williams

 
--=====================_80425686==.ALT-- -- http://www.freelists.org/webpage/oracle-l