Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Practical Tips from 2 Years of Growing on MongoDB

Practical Tips from 2 Years of Growing on MongoDB

The talk I gave at Mongo Boulder 2013

Avatar for Juan Patten

Juan Patten

January 24, 2013
Tweet

Other Decks in Programming

Transcript

  1. What We Talkin’ Bout? • Practical lessons learned from 3

    iterations of schema design • A few clever(?) tricks • Our approach to no-downtime schema migration
  2. Schema #1 Raffle = { _id: <string> [ ... ]

    entries: [ {...}, {...}, ... ] } • Tough to access • Padding Factor • Max Document Size LESSONS
  3. Schema #2 • “Denormalize!” • Each entry in own document

    • _id is UUID() • Indexes for each access pattern • Documents (almost) never grow • Cache results of expensive queries
  4. Schema #2 – Lessons • Complex queries for simple things

    • Indexes gigantic - killed performance • Old data “lingered” • _id unused
  5. Schema #3 – Goals • Minimal indexes • One document

    per entrant per raffle • _id derivable from known data • Old data should “expire” naturally
  6. ObjectID’s – A (not so) Secret Weapon 24-byte string →

    12-byte binary value new ObjectId() new ObjectId("47cc67093475061e3d95369d") or
  7. _id = new ObjectId() timestamp (seconds since epoch) “misc” ID

    info (machine_id | pid | incr) not derivable later! ObjectID’s – A (not so) Secret Weapon
  8. timestamp (raffle_date_created) “misc” ID info md5(entrant_id | raffle_id | salt)

    _id = new ObjectId(X) X = “1234567890abcdefabcdef” ObjectID’s – A (not so) Secret Weapon
  9. Schema #3 – Results ✓Minimal indexes (5 large → 2

    small) ✓One document per entrant per raffle ✓_id derivable from known data ✓Old data should “expire” naturally • write lock % cut by 9x • page faults cut by 10x • open cursor size cut by 5x
  10. Schema Takeaways • access patterns == indexes. design the schema

    around them • save queries and index space by deriving ID’s from known data • denormalize in moderation