MongoDB Case Study at NoSQL Now 2012
•Download as KEY, PDF•
4 likes•2,288 views
StudyBlue provides an online service for students to store, study, and share course materials. They implemented MongoDB to address scaling issues with their PostgreSQL database as usage and data grew rapidly. MongoDB allowed for horizontal scaling across shards for improved write performance and high availability. Key challenges included adjusting to the document model versus relational, sharding and rebalancing data, and managing replication lag in an eventually consistent system.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (10)
Similar to MongoDB Case Study at NoSQL Now 2012
Similar to MongoDB Case Study at NoSQL Now 2012 (20)
Recently uploaded
Recently uploaded (20)
MongoDB Case Study at NoSQL Now 2012
- 1. StudyBlue Databases at Scale: A MongoDB Case Study August 23, 2012 StudyBlue, Inc.
- 2. Overview • About Me • About StudyBlue • Why MongoDB? • Leveraging MongoDB • Key Issues • Q&A StudyBlue, Inc.
- 3. Who am I? • Sean Laurent • sean@studyblue.com • Head of Operations at StudyBlue, Inc. StudyBlue, Inc.
- 5. About StudyBlue • Online service for storing, studying, sharing and ultimately mastering course material • Digital backpack for students StudyBlue, Inc.
- 6. StudyBlue Usage • Many simultaneous users • Rapid growth • Cyclical usage StudyBlue, Inc.
- 7. Initial Use Case StudyBlue, Inc.
- 8. Flashcard Scoring • Track flashcard scoring over time • Every single card • Every single user • Forever • Provide aggregate statistics • Flashcard deck • Folder • Overall • Focus on content mastery StudyBlue, Inc.
- 10. The Problem • Reasonably large number of cards • Large number of users • Users base increasing rapidly • Shift in usage - increasing faster than users • Time on site • Decks per user • Average deck size • Study sessions per user StudyBlue, Inc.
- 11. StudyBlue Database Problems • Amazon EC2 • Large number of simultaneous users • High write volume • Single PostgreSQL database • Large tables StudyBlue, Inc.
- 13. Alternatives • Amazon Simple DB • Far too simple • Cassandra • Difficult to add nodes and rebalance • Column families cannot be modified w/out restart • CouchDB • Difficult to add nodes and rebalance • Redis • No native support for sharding/partitioning • Master/slave only - no automatic failover StudyBlue, Inc.
- 14. MongoDB for the Win • Highly available • Replica sets • Automatic failover • Horizontal scaling across shards • Improved write performance • Improved availability during failures • Easy to add additional shards • Easier maintenance StudyBlue, Inc.
- 16. Development • 100% Java • Existing PostgreSQL database • System of record • Synchronization issues StudyBlue, Inc.
- 17. SQL Integration & Synchronization • PostgreSQL considered system of record • Asynchronous event driven • Web servers queue change events • Scoring servers process events • Query PostgreSQL • Update MongoDB StudyBlue, Inc.
- 19. MongoDB Schema • Many shallow collections vs monolithic deep collection • Leverage existing SQL knowledge • Simplify SQL integration StudyBlue, Inc.
- 21. DevOps • Amazon EC2 • Separate dev, test and production environments • Scripting & automation • Creation • Cloning • Configuration management with Chef StudyBlue, Inc.
- 22. Even More Data • Moved existing tables from PostgreSQL to MongoDB • Four PostgreSQL tables with millions of rows combined into single collection • New development uses MongoDB: • Analytics data with 300+ million documents StudyBlue, Inc.
- 23. SQL Integration Part 2 • MongoDB considered system of record • Web servers interact with MongoDB directly • More complex structures, fewer shallow collections StudyBlue, Inc.
- 25. Summary • NoSQL vs SQL • Design challenges • Amazon EC2/EBS • Partitioning & sharding • Replication Lag StudyBlue, Inc.
- 26. NoSQL vs SQL • NoSQL != SQL • Document database != RDBMS • No joins • Requires new mindset • Store related data together • Duplicate data as necessary StudyBlue, Inc.
- 27. Design Challenges • Multiple tables to single collections with complex objects • Avoid growing objects • Padding • In-place update vs move • Challenges with array elements StudyBlue, Inc.
- 28. Amazon EC2 & EBS • Plan for failure • “When” not “if” • EBS performance • Inconsistent • Limited by bandwidth • 100 IOPS / volume • RAID-0 StudyBlue, Inc.
- 29. Instance Sizing • Memory is king • Keep working set in RAM • Indexes • Working data • Spread horizontally instead of vertically • Increased write performance StudyBlue, Inc.
- 30. Data Routing with Shards StudyBlue, Inc.
- 31. Partitioning in the Cloud • Operations perspective • Dynamic changes in machines • Config servers track machines • Each node in replica set knows other nodes • Avoids restarting applications when Mongo servers change • Easy scaling • Local shard servers • Config servers store redundant copies • Two-phase commit StudyBlue, Inc.
- 32. Picking a shard key • Shard key selection critical for proper distribution • Spread writes across cluster • Depends on usage • Single document vs aggregation • Examples all time-series data • Cannot be changed StudyBlue, Inc.
- 33. Sharding - Gritty Details • Chunks • 64 MB blocks of data • Splits • 1 chunk turns into 2 chunks • Rebalance • Move chunks to different nodes • Maintain even distribution of chunks StudyBlue, Inc.
- 34. Rebalancing Challenges • Splits have to find mid point of chunk • Very I/O expensive for collections with small documents • Decreased chunk size • Made documents larger & more complex • Can be a drain on system • Needs to run frequently StudyBlue, Inc.
- 35. Replication Lag • Eventual consistency • No guarantees about lag • Replica safe writes • Data committed to at least 2 nodes • Can cause problems with high replication lag • Security vs time StudyBlue, Inc.
- 37. Contact us Web: http://www.studyblue.com Twitter: @StudyBlue Email: sean@studyblue.com StudyBlue, Inc.
Editor's Notes
- \n
- \n
- - Developer at heart\n- 15 years experience\n- Responsible for selecting Mongo\n\n
- \n
- - 15 person startup\n- Bottom-up attempt to improve student outcomes through disruptive change outside of the education system. \n- Allows students to create and store lecture notes and flashcards and access them online and via mobile apps (iOS and Android)\n
- - No public numbers (low millions)\n- 4000 simultaneous users (peak)\n- 120+ countries\n- Daily cycle slowly flattening\n
- \n
- \n
- \n
- - 20 million cards at the time\n- Over 60 million cards now\n- Expect 100 million cards in next 6 months\n
- - EC2 limits vertical scaling\n- Postgres tuning extremely beneficial\n- Tables > 70 million rows\n
- \n
- Cassandra & Redis have since improved \nAmazon Dynamo didn’t exist\n\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- Launch replacement Mongo server in < 10 mins\nClone entire production Mongo cluster in < 60 mins\n
- - Not huge by BigData standards - Couple terabytes\n- Big by startup standards\n
- \n
- \n
- \n
- \n
- \n
- Provisioned IOPS\n
- - Working set is ~20% for SB, mostly recently created data\n
- \n
- \n
- http://www.snailinaturtleneck.com/blog/2011/01/04/how-to-choose-a-shard-key-the-card-game/\n
- \n
- Ran nightly - backlog causes really high load\n
- \n
- \n
- \n