The document provides an overview of the speaker's experience with MongoDB and how it has evolved over time to meet growing data and usage demands. It discusses (1) how data storage needs changed from efficiency to throughput, (2) the proliferation of programming languages and object-relational mappers, and (3) MongoDB's features for sharding, clustering, and storing data as JSON documents to address these challenges. The speaker emphasizes leaving behind the 3NF data model and that atomicity is at the document level with MongoDB.

1. My Life With
MongoDB
Mitch Pirtle, Miami MongoDB User Group
February 2015

2. Before we get started.

3. Your MongoDB Fu?
Happy to show you how WiredTiger can be optimized
I got multiple apps in production with it
Currently using it in active development/projects
Hey I downloaded it at least, might even install it
Got donuts?

4. All righty then!
Now a little about me.

5. Recovering Joomla! founder
Starting companies since 1995
Big on PHP, Node, Go, cloud tools, virtualization, containers
Big on developer workflow
Coach youth sports
Proud husband, dad
Don’t even THINK about touching my BBQ

6. Hey Ed, how much time do I got?

7. In the beginning…

8. We needed to store data
Data needed to be kept clean
Disk space was at a premium
Same for CPU and RAM
Efficiency was the most important factor

9. Life was good.

10. - Al Gore, supposedly
“Hey boys, check it out, the
Internets!”

11. Number of concurrent users grew
Amount of data grew
Programming languages proliferated
Applications accessing our data proliferated
We all switched to Oracle or DB2

12. Hey what was that sound?

13. Arrival of the World Wide Web

14. Concurrent users jumped from 2 to 2,000,000
1,200 daily accesses turned into 20MM daily views
Throughput became the only critical element for your
apps, and therefore your data
That smoking crater in the datacenter? Yeah, that was
your DATABASE SERVER.

15. Something else was
happening, too.

16. Programming languages
Perl, Python, Ruby, Java, PHP, and more
All used objects to represent structures
All were connected to relational databases
Which required…

17. The Object Relational Mapper (ORM)

18. Models represented “things”
Each model could be linked to other models
Has many, belongs to, is a member of…

19. It’s ok, we got this.

20. Fixes for rapid data growth
Stored procedures
Foreign keys
Triggers

21. Here comes the World Wide Web!

22. No, really, we got this.

23. Fixes for super mega whack-
daddy growth
Sharding
Clustering
Multi-master
Read-only slaves
Replication
Flux Capacitors
Dilithium Crystals

25. Ok, we don’t got this.

26. Enter…

27. –Johnny Developer
“But it’s not ACID compliant!
ZOMGWTFROFLBBQ!!1!”

28. “Somebody wanted acid?”

29. – Some Sucker On The Internet
“But somebody on YouTube said it
would lose my data!”

30. You’re not losing me. I’m a fan favorite.

31. Main MongoDB goodness
Stores data as JSON documents
Sharding is built in
Clustering is built in
Slaves/replication is built in
Atomic writes, supports verified commits to disk
No JOINs

32. But how am I going to manage these queries that
reach across umpteen different collections?

33. Denormalizing your data
Simple top-level schema
Logically driven
Atomic data

34. Your relational data looked like this.

35. Your document model looks like this.

36. Once again, with
feeling.

37. Relational data.

38. Document data.

39. Relational data.

40. Document data.

41. Enough already!

42. User table, relational style
first_name: varchar(128)
last_name: varchar(128)
email: varchar(128)
password: varchar(128)

43. Seems simple enough.
Right?

44. Not done yet.
address_id: int (refers to address.id)
gender_id: int (refers to gender.id)
account_type_id: int (refers to account types)

45. See? I got this all figured out.

46. I have two addresses.

48. create_user(user)
Ok first insert the users table

49. create_user(user)
Ok first insert the users table
No wait, first insert the address and get address.id

50. create_user(user)
Ok first insert the users table
No wait, first insert the address and get address.id
No, insert users record first, then the address, then
update the users.address_id with the last_insert_id

52. EXAMPLE: User document
{
_id: “35b3d656-4e4b-41c0-85ab-23a9867a3e00”,
first_name: “Mitch”,
last_name: “Pirtle”,
addresses: [
address_1: “123 Tondup Glacier”,
address_2: “Second Yurt On The Left”,
region: “Lhasa”,
country: “Tibet”
]
}

53. Yep, that’s all JSON.

55. Stumbling into MongoDB
Leave your 3NF data model behind
Atomicity is at the DOCUMENT LEVEL
There are different ways of doing things (e.g.
findAndReplace)

56. “Scuse me while I whip this out.”

57. [CONSOLE]

58. Questions?

59. Thanks!
@mitchitized
http://about.me/mitchitized
http://www.slideshare.net/spacemonkeylabs
https://www.github.com/spacemonkey