gamesNoSQL
Patrick Hueslertwitter: @phueslergithub: phuesler
GamesHow to build
Game backendiOSFlashFacebookAndroid
scale
for Diamond Dash~28,000,000monthly active users15/04/2013
for Diamond Dash~4,600,000daily active users15/04/2013
engineering
DEVOPSYou can call it
You Build itYOU RUN IT
Developerfriendly
Operationsfriendly
of architectureEVOLUTIONWooga’s
PrototypeIt starts with a
AdmininterfaceAdd an
SimpleBackendServices
GamesPast
learning1st
Game backendReportingiOSFlashFacebookAndroid
Game backendiOSFlashFacebookAndroidReporting
GAme 1Game 2ReportingGAme 3Game 4
Kafkahttps://kafka.apache.org/index.html
TIME
LAMPBuilt with
... well, nginx instead ofapacheLAMPBuilt with
learned?what have we
FAST ENOUGHmysql is often
TIME
cloudTo the
load balancermaster shard 1 master shard 2slave shard 1 slave shard 2app server app server app server
load balancerDBappapp app app app appappapp app app app appappapp app app app appDB DB DB DB DBDB DB DB DB DB DB
learned?what have we
use casedifferent
Are NOTarcade gamesfarming games
slow partsMove
repeatRinse and
learned?what have we
helps, but only to a certainextentmachinesAdding more
AutomatedServer Provisioning
RedisPros and cons of
facilitate databasechangesAbstractionsGood code
Testsgive confidence
are easier to reason aboutChangesIncremental
are easier to reason aboutRolloutsIncremental
crucialmonitoring is
TIME
dedicatedBack to
MachinesFaster
networkFaster
load balancerREdis master Redis Slaveapp server app server app server
u1_rooms_R1u1_Pets_P2u1_Pets_P3u1_Pets_P4u1_Pets_P5u2_Pets_P1u2_Pets_P2
u1_rooms_R1u1_Pets_P2u1_Pets_P3u1_Pets_P4u1_Pets_P5u2_Pets_P1u2_Pets_P2
REDISHASH
u1U2U3XPRoomsPatientsXPRoomsPatientsXPRoomsPatientsU4
learned?What have we
placeMagicalShowers are a
a relational databaseNOTRedis is
to move aroundIs easierCompound user data
MemoryLeaks?
work again?BGSAVEHow does
workingno longerDumps are
learned?What have we
AssumptionsValidate your
Restore onDemandFix it with
DiskArchive user to
RedisRestore to
(never really supported)Disk StoreRedis
learned?What have we
less complexityMachinesLess
Archivingkeeps the working setsmall
compounduser data is easier tomove around
Trade offUsing Redis as yourmain data store
TIME
StatefulLet’s go
is faster than no databasedatabaseNO
s3Amazon
http://www.slideshare.net/wooga/from-0-to-1000000-daily-users-with-erlang
http://www.slideshare.net/wooga/from-0-to-1000000-daily-users-with-erlang
learned?What have we
Erlangis a great environmentto build distributedsystems
choice of databasetrumpsArchitecture
Statefulis more complex
lockingDistributed
lockerhttps://github.com/wooga/locker
warlockhttps://github.com/wooga/warlockhttp://uu.diva-portal.org/smash/record.jsf?pid=diva2:615805
TIME
EventMAchine
load balancerRiak Riak Riak Riak Riakappapp app appappapp app app
learned?What have we
RiakLife with
Single Pointof FailureNO!!!!!
DataModellingand Access
RedisRiak ClusterUser DataLevelXPBuildingsScenesMeta DaTaFriend IndexHighScoreS
clusterRiak
App ServerRiak?
BackupRiak
Amazon S3Archive to
questions?http://www.wooga.com/jobspatrick.huesler@wooga.com
Referenced Presentationshttp://www.slideshare.net/woogahttp://www.slideshare.net/wooga/how-to-handle-1000000-daily-users-w...
CreditsPolar bear: http://www.flickr.com/photos/bestrated1/167630455/sizes/o/Family: http://www.flickr.com/photos/adwriter...
Creditschronos: http://www.flickr.com/photos/seeminglee/8581497525clouds: http://www.flickr.com/photos/nirak/644335254dead...
Creditswrenches: http://www.flickr.com/photos/batega/1596898776bike locks: http://www.flickr.com/photos/ibcbulk/256435870l...
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
NoSQL Games_NoSQL Roadshow Berlin
Upcoming SlideShare
Loading in...5
×

NoSQL Games_NoSQL Roadshow Berlin

1,918

Published on

Learn how we use NoSQL and SQL databases to build games at Wooga. From prototypes to production systems that deal with the data of millions of players, this talk covers hands on use cases and learnings.

Published in: Technology, Business
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,918
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
34
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

NoSQL Games_NoSQL Roadshow Berlin

  1. 1. gamesNoSQL
  2. 2. Patrick Hueslertwitter: @phueslergithub: phuesler
  3. 3. GamesHow to build
  4. 4. Game backendiOSFlashFacebookAndroid
  5. 5. scale
  6. 6. for Diamond Dash~28,000,000monthly active users15/04/2013
  7. 7. for Diamond Dash~4,600,000daily active users15/04/2013
  8. 8. engineering
  9. 9. DEVOPSYou can call it
  10. 10. You Build itYOU RUN IT
  11. 11. Developerfriendly
  12. 12. Operationsfriendly
  13. 13. of architectureEVOLUTIONWooga’s
  14. 14. PrototypeIt starts with a
  15. 15. AdmininterfaceAdd an
  16. 16. SimpleBackendServices
  17. 17. GamesPast
  18. 18. learning1st
  19. 19. Game backendReportingiOSFlashFacebookAndroid
  20. 20. Game backendiOSFlashFacebookAndroidReporting
  21. 21. GAme 1Game 2ReportingGAme 3Game 4
  22. 22. Kafkahttps://kafka.apache.org/index.html
  23. 23. TIME
  24. 24. LAMPBuilt with
  25. 25. ... well, nginx instead ofapacheLAMPBuilt with
  26. 26. learned?what have we
  27. 27. FAST ENOUGHmysql is often
  28. 28. TIME
  29. 29. cloudTo the
  30. 30. load balancermaster shard 1 master shard 2slave shard 1 slave shard 2app server app server app server
  31. 31. load balancerDBappapp app app app appappapp app app app appappapp app app app appDB DB DB DB DBDB DB DB DB DB DB
  32. 32. learned?what have we
  33. 33. use casedifferent
  34. 34. Are NOTarcade gamesfarming games
  35. 35. slow partsMove
  36. 36. repeatRinse and
  37. 37. learned?what have we
  38. 38. helps, but only to a certainextentmachinesAdding more
  39. 39. AutomatedServer Provisioning
  40. 40. RedisPros and cons of
  41. 41. facilitate databasechangesAbstractionsGood code
  42. 42. Testsgive confidence
  43. 43. are easier to reason aboutChangesIncremental
  44. 44. are easier to reason aboutRolloutsIncremental
  45. 45. crucialmonitoring is
  46. 46. TIME
  47. 47. dedicatedBack to
  48. 48. MachinesFaster
  49. 49. networkFaster
  50. 50. load balancerREdis master Redis Slaveapp server app server app server
  51. 51. u1_rooms_R1u1_Pets_P2u1_Pets_P3u1_Pets_P4u1_Pets_P5u2_Pets_P1u2_Pets_P2
  52. 52. u1_rooms_R1u1_Pets_P2u1_Pets_P3u1_Pets_P4u1_Pets_P5u2_Pets_P1u2_Pets_P2
  53. 53. REDISHASH
  54. 54. u1U2U3XPRoomsPatientsXPRoomsPatientsXPRoomsPatientsU4
  55. 55. learned?What have we
  56. 56. placeMagicalShowers are a
  57. 57. a relational databaseNOTRedis is
  58. 58. to move aroundIs easierCompound user data
  59. 59. MemoryLeaks?
  60. 60. work again?BGSAVEHow does
  61. 61. workingno longerDumps are
  62. 62. learned?What have we
  63. 63. AssumptionsValidate your
  64. 64. Restore onDemandFix it with
  65. 65. DiskArchive user to
  66. 66. RedisRestore to
  67. 67. (never really supported)Disk StoreRedis
  68. 68. learned?What have we
  69. 69. less complexityMachinesLess
  70. 70. Archivingkeeps the working setsmall
  71. 71. compounduser data is easier tomove around
  72. 72. Trade offUsing Redis as yourmain data store
  73. 73. TIME
  74. 74. StatefulLet’s go
  75. 75. is faster than no databasedatabaseNO
  76. 76. s3Amazon
  77. 77. http://www.slideshare.net/wooga/from-0-to-1000000-daily-users-with-erlang
  78. 78. http://www.slideshare.net/wooga/from-0-to-1000000-daily-users-with-erlang
  79. 79. learned?What have we
  80. 80. Erlangis a great environmentto build distributedsystems
  81. 81. choice of databasetrumpsArchitecture
  82. 82. Statefulis more complex
  83. 83. lockingDistributed
  84. 84. lockerhttps://github.com/wooga/locker
  85. 85. warlockhttps://github.com/wooga/warlockhttp://uu.diva-portal.org/smash/record.jsf?pid=diva2:615805
  86. 86. TIME
  87. 87. EventMAchine
  88. 88. load balancerRiak Riak Riak Riak Riakappapp app appappapp app app
  89. 89. learned?What have we
  90. 90. RiakLife with
  91. 91. Single Pointof FailureNO!!!!!
  92. 92. DataModellingand Access
  93. 93. RedisRiak ClusterUser DataLevelXPBuildingsScenesMeta DaTaFriend IndexHighScoreS
  94. 94. clusterRiak
  95. 95. App ServerRiak?
  96. 96. BackupRiak
  97. 97. Amazon S3Archive to
  98. 98. questions?http://www.wooga.com/jobspatrick.huesler@wooga.com
  99. 99. Referenced Presentationshttp://www.slideshare.net/woogahttp://www.slideshare.net/wooga/how-to-handle-1000000-daily-users-without-using-a-cache-railswaycon-2012http://www.slideshare.net/wooga/event-stream-processing-with-kafka-berlin-buzzwords-2012http://www.slideshare.net/wooga/from-0-to-1000000-daily-users-with-erlang
  100. 100. CreditsPolar bear: http://www.flickr.com/photos/bestrated1/167630455/sizes/o/Family: http://www.flickr.com/photos/adwriter/212098009/sizes/o/cart: http://www.flickr.com/photos/41304880@N05/6187541490/cow closeup: http://www.flickr.com/photos/sovietuk/227465632/sizes/o/sparta: http://www.flickr.com/photos/legofenris/5008721616/sizes/l/tank: http://www.flickr.com/photos/markkelley/1581559810/sizes/l/bomb: http://www.flickr.com/photos/7969902@N07/511234695/scale: http://www.flickr.com/photos/31818720@N00/3273587681/engineering: http://www.flickr.com/photos/31704690@N05/8253753576/duck: http://www.flickr.com/photos/12836528@N00/2785398344/gear: http://www.flickr.com/photos/neurolysis/3335080917/cat: http://www.flickr.com/photos/55753993@N00/2898378081/
  101. 101. Creditschronos: http://www.flickr.com/photos/seeminglee/8581497525clouds: http://www.flickr.com/photos/nirak/644335254dead end: http://www.flickr.com/photos/ableman/298520443sloth: http://www.flickr.com/photos/matthijs/461893969stairs: http://www.flickr.com/photos/the_pale_side_of_insomnia/3010459970server rack: http://www.flickr.com/photos/jamisonjudd/2433102356gauge: http://www.flickr.com/photos/thatguyfromcchs08/2300190277pipe: http://www.flickr.com/photos/autowitch/102513226shower: http://www.flickr.com/photos/pagedooley/2047183582archive: http://www.flickr.com/photos/kasaa/2693784352water tap: http://www.flickr.com/photos/nachett/7852629550
  102. 102. Creditswrenches: http://www.flickr.com/photos/batega/1596898776bike locks: http://www.flickr.com/photos/ibcbulk/256435870lock master: http://www.flickr.com/photos/darwinbelllock : http://www.flickr.com/photos/dzarro72water wheel: http://www.flickr.com/photos/30649191@N00/8686135236starwars family: http://www.flickr.com/photos/kalexanderson/6312014327playdo: http://www.flickr.com/photos/manueb/1674681674microphone: http://www.flickr.com/photos/auralasia/4381121155cluster: http://www.flickr.com/photos/rogersmith/280267119backup: http://www.flickr.com/photos/dippy_duck/4562866718architecture: http://www.flickr.com/photos/bzyla/1331648993library: http://www.flickr.com/photos/fahdad/1718853829
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×