Ogdc 2013 choosing the right database for social mobile game
Upcoming SlideShare
Loading in...5
×
 

Ogdc 2013 choosing the right database for social mobile game

on

  • 359 views

 

Statistics

Views

Total Views
359
Views on SlideShare
359
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Ogdc 2013 choosing the right database for social mobile game Ogdc 2013 choosing the right database for social mobile game Presentation Transcript

  • Nguyen Thanh Quan Lead System Engineer SO6 - G6 Division
  • Talk Overview Part II. Decision principles Part III. Choosing the right database Part I. Our story
  • • G6’s typical social game • Game architecture • Problems • Evolution Part I. Our story
  • G6’s typical social game
  • Game architecture • High production quality game • Game logic in client • Can keep a socket Flash Client Side Server Side • Base on a LAMP stack • Game logic in PHP • HTTP connection Web stack
  • Client Web server #1 Web server #n Web server #2 Game architecture
  • Game architecture - 50,000 100,000 150,000 200,000 DAUs DAUs
  • Problems • Memory, hardware has limitation • Not easy for scaling out • 4,000 operation per second • 1,000 write per second • Parsing, locking, loggin g, threads …
  • Evolution Data is growing rapidly Hardware is not merging as that of data growth Hard to scale using traditional way
  • Part II. Decision principles High performance High availability High scalability Low in cost Outage stories: zynga, wooga
  • Part III. Choosing the right database
  • Pick the right tool for the job
  • Why NoSQL? High Performance High Scalability Always On Flexible Data Model
  • NoSQL – Disadvantage • Can’t be use for analytics, reporting … • Lack of relation from one key to another • Packing and un-packing of each key • Need whole value from the key; to read/write any partial information
  • Comparison • Fast enough • Disk based • 4,000 OPS • 1,000 write/s MySQL • Super fast • RAM based • 50,000 OPS • Writes are fast as reads NoSQL
  • Game architecture Client Web #1 Web #n Web #2 NoSQL DB Real-time data Analytics data
  • Our result We reached 1 million DAUs - 500,000 1,000,000 1,500,000 2,000,000 DAUs DAUs
  • Next stories … and our journey continues…
  • - 50,000 100,000 150,000 200,000 DAUs DAUs Summarize Evolution everyday
  • Revolution if necessary Summarize
  • OPEN GAME DEVELOPMENT CONFERENCE 2013 Nguyen Thanh Quan Lead System Engineer SO6 - G6 Division