Mongodb, Node.js and You: PART I
3 likes1,651 views
This document summarizes Mitch Pirtle's talk about MongoDB at the jsDay 2014 conference in Verona, Italy. The talk included: an introduction to MongoDB and how it addresses the limitations of relational databases for modern web applications; a demonstration of the MongoDB console; stories about how a company successfully used MongoDB, including increased performance and faster development; and warnings about potential issues like not updating data when changing schemas and not planning for operational impacts like backups.
Mongodb, Node.js and You: PART I
- 1. Node.js, MongoDB and You: Part I Mitch Pirtle jsDay 2014, Verona Italy - @jsdayit
- 2. First, tell me about yourselves.
- 3. New to Node?
- 4. Come on, be honest!
- 5. New to Node?
- 7. Does your Javascript totally suck?
- 8. Ok my Javascript totally sucks.
- 10. Mitch Pirtle • Recovering Joomla! founder • Mongo Master • Starting companies since 1995 • Musician, skate punk, football coach • American idiot living in Turin
- 11. Important Mitch Facts • I am not cool. However I have been called perky. • I am not Rich. My name is Mitch. Such is life. • I am internet famous. Just to be clear: Internet Famous + $1.50 = $1.50
- 12. About this talk.
- 13. Ok, technically there are three talks today.
- 14. • Session 1: All about MongoDB (this one)! • Session 2: All about Node.js (that’s next) • Session 3: The coolness of both together
- 15. That’s a lotta lotta stuff to cover STAY ALERT
- 16. All About MongoDB • Brief introduction to MongoDB • CONSOLE! • Really cool discoveries and surprises • Shameful admissions and painful stories
- 17. In The Beginning • We had relational databases. Back then they were called “databases” and that’s where you stored your data. • Primary focus: atomicity, consistency, reliability. • Was normal to spend 6 hours. ON ONE QUERY. • I love vacuum tubes, keep you warm in winter. • Life was good.
- 18. What Happened • Hello, Internet! • Databases became immediate source of pain for scale, performance • Traffic grew, along with it came bigger expectations, infinitely more complexity, a slew of new platforms, and Big Data™
- 19. That sure looks like a nail to me.
- 20. Troubled Relations • Web languages gravitated toward objects, not 3NF entites/relations • Size of data needed to live on more than one physical machine • Performance requirements needed to be far better
- 21. Along came sharding • Can split your data across multiple machines • Also splits your query load across multiple machines • Like RAID for your data, right?
- 22. What sharding brought along for the ride • How do you back this stuff up? • How do you spread a group query across N machines again? • How do you run a join query that spans a sharded table?
- 23. All those hours, spent mastering 3NF and procedural programming
- 25. It is REALLY hard to scale a relational database engine.
- 26. The common approach pushed logic out of the database back into the application tier.
- 27. Then why use a relational database in the first place?
- 28. Then there was…
- 29. The Promises of MongoDB • Speed - crazy whack-daddy fast • Simplicity - JSON documents FTW • Embedded documents • 16MB limit • Scale - sharding, multimaster out of the box • Yes, I said whack-daddy.
- 30. ENOUGH TALK BRING ON THE CONSOLE
- 31. Wait, there’s more • Fulltext: Allows for compound indexes, supports many languages • Sharding: You can scale collections across N machines • GridFS: Simple interface to store files in your database (CONSOLE!) • Multimaster: Replica Sets make it possible for read slaves, failover, redundancy
- 32. Now some cool stories
- 33. Mini Case Study: Totsy • First ecommerce site to rely on MongoDB for all data. Everything. Even product images and associated media. • I suspected it would be fast. • I suspected we could develop quickly. (This was important, as they only let me hire one guy.)
- 34. So how fast was it?
- 35. Launch story • Went live with MongoDB on a quad-core consumer grade el-cheapo machine, only 2GB RAM. • I was terrified. • Over a million moms waiting for the launch. • Upon launch, load was 0.05. Highest it ever got was around 0.5.
- 37. Development impact • Simple models make for less code. There were no sixteen-table joins, no ORM, one result had all the data needed from a single query.! • Less code makes for less bugs. No more six- hour query debugging marathons. No more learning why UNION was faster than JOIN… • Less bugs leaves time for more code. Did I mention they only let me hire one guy?
- 38. Even moar impact • Used GridFS for all media storage. • Allowed free MD5 checking for duplicates. • Allowed storage of metadata per file (views, comments, rates, whatever else we wanted). • No need for NFS, clumsy rsync cronjobs, high costs of NAS or iSCSI.
- 39. Now some sad stories.
- 40. The perils of schemaless • Started prototyping quickly enough • Made a couple changes to user model • Made some more changes… • WHUPS WHY FIFTEEN KINDS OF USER?!?!
- 41. Remember: Always update existing data when changing models.
- 42. Everything in the database! • Backups were brutal • Forgot to separate GridFS data from main database • Totally unprepared for the operational impact
- 43. Remember: Operational impact BEFORE you launch.
- 44. Stump the Geek™
- 45. Thanks! • AboutMe • @mitchitized - Twitter • spacemonkey - GitHub • LinkedIn - I’M AVAILABLE!