Like many startups, Coursera began its data storage journey with MySQL, a familiar and industry-proven database. As Coursera's user base grew from several thousand to many millions, we found that MySQL provided limited availability and restricted our ability to scale easily. New product initiatives and requirements provided a perfect opportunity to revisit our choice of core workhorse database. After evaluating several NoSQL databases, including MongoDB, DynamoDB and HBase, we elected to transition to Cassandra . Cassandra's relative maturity, masterless architecture (for availability), tunable consistency, and stable low-latency performance made it a clear winner for our needs. Learn more about what it takes to transition from SQL to Cassandra in this talk.

1. Coursera’s Adoption of Cassandra

2. Biography
Daniel Chia
@DanielJHChia
Software Engineer, Infrastructure Team
2© 2015. All Rights Reserved.

3. © 2015. All Rights Reserved.
1 Introduction
2 Want We Want From Our Database
3 MySQL Limitations
4 Cassandra - What and Why
5 Looking Back

4. Coursera
4© 2015. All Rights Reserved.

5. 5© 2015. All Rights Reserved.

6. 6© 2015. All Rights Reserved.
Web
iOS
Android

7. Database Wants
7© 2015. All Rights Reserved.

8. Consistently Fast Latencies
8© 2015. All Rights Reserved.

9. Availability
9© 2015. All Rights Reserved.

10. Scalability
10© 2015. All Rights Reserved.

11. Other Niceties
• Operational ease
• Multi-region capability
11© 2015. All Rights Reserved.

12. Coursera Tech Stack
• 100% AWS
• MySQL + Cassandra
• Service-oriented
12© 2015. All Rights Reserved.

13. RDS Challenges
• Normalized data model Unpredictable query performance
• Scaling by sharding not ideal
• Single master limitation
13© 2015. All Rights Reserved.

14. C*
• Columnar model
• Tunable consistency
• Fast
• Horizontally scalable
• Great community
14© 2015. All Rights Reserved.

15. 15© 2015. All Rights Reserved.
Looking Back

16. Cassandra - Initial Pain Points
• Can’t execute arbitrary queries
• Filtering, sorting, etc.
• Can’t be abused as an OLAP database
• Worries about ‘eventual’ consistency
16© 2015. All Rights Reserved.

17. SQL NoSQL Mindset Shift
• Build in-house Cassandra expertise
• Data modeling still important
• Know your queries
17© 2015. All Rights Reserved.

18. Cassandra ≠ [database XYZ]
“But if you judge a fish by its ability to climb a tree,
it will live its whole life believing that it is stupid.”
-Albert Einstein
18© 2015. All Rights Reserved.

19. Enrollment Example
• Learners enroll into a course
• learner (many-to-many) course
• Need to track this membership
19© 2015. All Rights Reserved.

20. MySQL
CREATE TABLE `courses_learners` (
`id` INT(11) NOT NULL auto_increment,
`course_id` INT(11) NOT NULL,
`learner_id` INT(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `c_l` (`learner_id`, `course_id`),
CONSTRAINT `ref1` FOREIGN KEY (`course_id`)
CONSTRAINT `ref2` FOREIGN KEY (`learner_id`)
)
20© 2015. All Rights Reserved.

21. MySQL
CREATE TABLE `courses_learners` (
`id` INT(11) NOT NULL auto_increment,
`course_id` INT(11) NOT NULL,
`learner_id` INT(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `c_l` (`learner_id`, `course_id`),
CONSTRAINT `ref1` FOREIGN KEY (`course_id`)
CONSTRAINT `ref2` FOREIGN KEY (`learner_id`)
)
21© 2015. All Rights Reserved.

22. MySQL
CREATE TABLE `courses_learners` (
`id` INT(11) NOT NULL auto_increment,
`course_id` INT(11) NOT NULL,
`learner_id` INT(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `c_l` (`learner_id`, `course_id`),
CONSTRAINT `ref1` FOREIGN KEY (`course_id`)
CONSTRAINT `ref2` FOREIGN KEY (`learner_id`)
)
22© 2015. All Rights Reserved.

23. MySQL
CREATE TABLE `courses_learners` (
`id` INT(11) NOT NULL auto_increment,
`course_id` INT(11) NOT NULL,
`learner_id` INT(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `c_l` (`learner_id`, `course_id`),
CONSTRAINT `ref1` FOREIGN KEY (`course_id`)
CONSTRAINT `ref2` FOREIGN KEY (`learner_id`)
)
23© 2015. All Rights Reserved.

24. Cassandra
CREATE TABLE courses_by_learner (
learner_id uuid,
course_id uuid,
PRIMARY KEY (learner_id, course_id)
)
24© 2015. All Rights Reserved.

25. Helpful Things
• Data modeling consulting
• Monitoring
• Data access layer for common use cases
25© 2015. All Rights Reserved.

26. Gotchas
• Lots of truly ad-hoc queries is hard
• Don’t use C* directly to explore your data. (Spark?)
• Sorting, filtering can be hard
• Consider Solr / ElasticSearch
• Or even MySQL depending on load / importance
26© 2015. All Rights Reserved.

27. Thank you