Mongodb, Node.js and You: PART I


Published on

This is the first of a three-part series I gave at jsDay 2014 in Verona, Italy.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Mongodb, Node.js and You: PART I

  1. 1. Node.js, MongoDB and You: Part I Mitch Pirtle jsDay 2014, Verona Italy - @jsdayit
  2. 2. First, tell me about yourselves.
  3. 3. New to Node?
  4. 4. Come on, be honest!
  5. 5. New to Node?
  6. 6. New to MongoDB?
  7. 7. Does your Javascript totally suck?
  8. 8. Ok my Javascript totally sucks.
  9. 9. Now about me.
  10. 10. Mitch Pirtle • Recovering Joomla! founder • Mongo Master • Starting companies since 1995 • Musician, skate punk, football coach • American idiot living in Turin
  11. 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. 12. About this talk.
  13. 13. Ok, technically there are three talks today.
  14. 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. 15. That’s a lotta lotta stuff to cover STAY ALERT
  16. 16. All About MongoDB • Brief introduction to MongoDB • CONSOLE! • Really cool discoveries and surprises • Shameful admissions and painful stories
  17. 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. 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. 19. That sure looks like a nail to me.
  20. 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. 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. 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. 23. All those hours, spent mastering 3NF and procedural programming
  25. 25. It is REALLY hard to scale a relational database engine.
  26. 26. The common approach pushed logic out of the database back into the application tier.
  27. 27. Then why use a relational database in the first place?
  28. 28. Then there was…
  29. 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.
  31. 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. 32. Now some cool stories
  33. 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. 34. So how fast was it?
  35. 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.
  36. 36. Was development quicker?
  37. 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. 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. 39. Now some sad stories.
  40. 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. 41. Remember: Always update existing data when changing models.
  42. 42. Everything in the database! • Backups were brutal • Forgot to separate GridFS data from main database • Totally unprepared for the operational impact
  43. 43. Remember: Operational impact BEFORE you launch.
  44. 44. Stump the Geek™
  45. 45. Thanks! • AboutMe • @mitchitized - Twitter • spacemonkey - GitHub • LinkedIn - I’M AVAILABLE!