My life with MongoDB
1 like984 views
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.
![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”
]
}](https://image.slidesharecdn.com/mylifewithmongodb-150217191539-conversion-gate01/85/My-life-with-MongoDB-52-320.jpg)
![[CONSOLE]](https://image.slidesharecdn.com/mylifewithmongodb-150217191539-conversion-gate01/85/My-life-with-MongoDB-57-320.jpg)
My life 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?
- 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
- 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!”
- 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.
- 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)
- 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?