NoSQL Games_NoSQL Roadshow Berlin
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

NoSQL Games_NoSQL Roadshow Berlin

  • 1,922 views
Uploaded 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......

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.

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,922
On Slideshare
1,326
From Embeds
596
Number of Embeds
6

Actions

Shares
Downloads
34
Comments
0
Likes
7

Embeds 596

http://www.huesler-informatik.ch 263
http://hyperdev.de 242
https://twitter.com 32
http://localhost 29
http://huesler-informatik.ch 25
http://dschool.co 5

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. gamesNoSQL
  • 2. Patrick Hueslertwitter: @phueslergithub: phuesler
  • 3. GamesHow to build
  • 4. Game backendiOSFlashFacebookAndroid
  • 5. scale
  • 6. for Diamond Dash~28,000,000monthly active users15/04/2013
  • 7. for Diamond Dash~4,600,000daily active users15/04/2013
  • 8. engineering
  • 9. DEVOPSYou can call it
  • 10. You Build itYOU RUN IT
  • 11. Developerfriendly
  • 12. Operationsfriendly
  • 13. of architectureEVOLUTIONWooga’s
  • 14. PrototypeIt starts with a
  • 15. AdmininterfaceAdd an
  • 16. SimpleBackendServices
  • 17. GamesPast
  • 18. learning1st
  • 19. Game backendReportingiOSFlashFacebookAndroid
  • 20. Game backendiOSFlashFacebookAndroidReporting
  • 21. GAme 1Game 2ReportingGAme 3Game 4
  • 22. Kafkahttps://kafka.apache.org/index.html
  • 23. TIME
  • 24. LAMPBuilt with
  • 25. ... well, nginx instead ofapacheLAMPBuilt with
  • 26. learned?what have we
  • 27. FAST ENOUGHmysql is often
  • 28. TIME
  • 29. cloudTo the
  • 30. load balancermaster shard 1 master shard 2slave shard 1 slave shard 2app server app server app server
  • 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. learned?what have we
  • 33. use casedifferent
  • 34. Are NOTarcade gamesfarming games
  • 35. slow partsMove
  • 36. repeatRinse and
  • 37. learned?what have we
  • 38. helps, but only to a certainextentmachinesAdding more
  • 39. AutomatedServer Provisioning
  • 40. RedisPros and cons of
  • 41. facilitate databasechangesAbstractionsGood code
  • 42. Testsgive confidence
  • 43. are easier to reason aboutChangesIncremental
  • 44. are easier to reason aboutRolloutsIncremental
  • 45. crucialmonitoring is
  • 46. TIME
  • 47. dedicatedBack to
  • 48. MachinesFaster
  • 49. networkFaster
  • 50. load balancerREdis master Redis Slaveapp server app server app server
  • 51. u1_rooms_R1u1_Pets_P2u1_Pets_P3u1_Pets_P4u1_Pets_P5u2_Pets_P1u2_Pets_P2
  • 52. u1_rooms_R1u1_Pets_P2u1_Pets_P3u1_Pets_P4u1_Pets_P5u2_Pets_P1u2_Pets_P2
  • 53. REDISHASH
  • 54. u1U2U3XPRoomsPatientsXPRoomsPatientsXPRoomsPatientsU4
  • 55. learned?What have we
  • 56. placeMagicalShowers are a
  • 57. a relational databaseNOTRedis is
  • 58. to move aroundIs easierCompound user data
  • 59. MemoryLeaks?
  • 60. work again?BGSAVEHow does
  • 61. workingno longerDumps are
  • 62. learned?What have we
  • 63. AssumptionsValidate your
  • 64. Restore onDemandFix it with
  • 65. DiskArchive user to
  • 66. RedisRestore to
  • 67. (never really supported)Disk StoreRedis
  • 68. learned?What have we
  • 69. less complexityMachinesLess
  • 70. Archivingkeeps the working setsmall
  • 71. compounduser data is easier tomove around
  • 72. Trade offUsing Redis as yourmain data store
  • 73. TIME
  • 74. StatefulLet’s go
  • 75. is faster than no databasedatabaseNO
  • 76. s3Amazon
  • 77. http://www.slideshare.net/wooga/from-0-to-1000000-daily-users-with-erlang
  • 78. http://www.slideshare.net/wooga/from-0-to-1000000-daily-users-with-erlang
  • 79. learned?What have we
  • 80. Erlangis a great environmentto build distributedsystems
  • 81. choice of databasetrumpsArchitecture
  • 82. Statefulis more complex
  • 83. lockingDistributed
  • 84. lockerhttps://github.com/wooga/locker
  • 85. warlockhttps://github.com/wooga/warlockhttp://uu.diva-portal.org/smash/record.jsf?pid=diva2:615805
  • 86. TIME
  • 87. EventMAchine
  • 88. load balancerRiak Riak Riak Riak Riakappapp app appappapp app app
  • 89. learned?What have we
  • 90. RiakLife with
  • 91. Single Pointof FailureNO!!!!!
  • 92. DataModellingand Access
  • 93. RedisRiak ClusterUser DataLevelXPBuildingsScenesMeta DaTaFriend IndexHighScoreS
  • 94. clusterRiak
  • 95. App ServerRiak?
  • 96. BackupRiak
  • 97. Amazon S3Archive to
  • 98. questions?http://www.wooga.com/jobspatrick.huesler@wooga.com
  • 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. 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. 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. 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