RE: Anyone with experience with MMOG and databases?
- From: Tony Jambu <tjambu_freelists@xxxxxxxxxxxx>
- To: "Billy Verreynne (JW)" <VerreyB@xxxxxxxxxxxx>
- Date: Mon, 15 Aug 2005 02:57:29 +1000
Hi Billy
At 02:16 AM 14/08/2005, Billy Verreynne \(JW\) wrote:
>A database is a database is a database. The fundementals of proper
>design, proper implementation, not only grasping Oracle concepts but
>adhering to it, applies - irrespective of the type of database.
I beg to differ here and my reasons are explained below.
>> Looking at a system that will be requiring 10,000+ simple writes per
>sec and
>> 20,000+ semi simple reads per sec.
>
>Interested in how you can determine the I/O rates up front. That one
>usually can only do after the fact as it is highly hardware dependant
>and implementation specific. Unless one uses rather old analysis &
>design techniques like Tetrach which is a bit antiquated wrt today's
>technology.
>
>There are also numerous ways to address the I/O issue. I often use the
>real word example of a billing system that ran on a database platform
>I DBA'ed. Month-end processing was 20+ hours. When I pulled I/O stats
>I saw it processed in excess of 1TB of data - the pysical database
>size (of *entire* db) was less than 80GB.
>
>Which is why fundementals are so important. One approaches something
>like Oracle as a file-based row-by-row processing bit bucket.. no
>wonder it takes 1TB of I/O for HUAODs (Head Up Ass Oracle Developers)
>to process 20Gb worth of data that needs to be billed.
I have also worked on a Telco/Billing system before and do know about
the high amount of I/Os required for billing and call rating.
My guess why you were seeing such high I/Os from a mere 80GB database is
because it is 'processing'the data and cross referencing the data. It
could also mean that the developers have an inefficient algorithm to
process the data. Will leave that up to you.
Now that is why I want to discuss it with someone who has worked with
MMOG. MMOG application normally makes small little writes (size wise).
Reads can be from one simple table or sometime 2 or 3 table join. But
they are normally simple. Now it is the rate of request I am more concern
about.
There are lots of different techniques to reduce I/O volume (not talking
about I/O rates here). Using Bit data to represent information etc and these
are being implemented to reduce the volume of data being processed.
SO my quest to find someone that has done this before.
tony
--
//www.freelists.org/webpage/oracle-l
Other related posts:
