OSDC 2012 | Scaling with MongoDB by Ross Lawley
•
0 likes•19 views
MongoDB's architecture features built-in support for horizontal scalability, and high availability through replica sets. Auto-sharding allows users to easily distribute data across many nodes. Replica sets enable automatic failover and recovery of database nodes within or across data centers. This session will provide an introduction to scaling with MongoDB by one of the developers working on the project.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to OSDC 2012 | Scaling with MongoDB by Ross Lawley
Similar to OSDC 2012 | Scaling with MongoDB by Ross Lawley (20)
Recently uploaded
Recently uploaded (20)
OSDC 2012 | Scaling with MongoDB by Ross Lawley
- 2. Ross Lawley Python Engineer @ 10gen Web developer since 1999 Passionate about open source Agile methodology email: ross@10gen.com twitter: RossC0
- 3. Today's Talk • Scaling • Understanding mongoDB's architecture • Schema design and usage • Replication • Sharding
- 4. Scaling • Operations/sec go up • Storage needs go up • Capacity • IOPs • Complexity goes up • Caching
- 5. • Optimization & Tuning • Schema & Index Design • O/S tuning • Hardware configuration • Vertical scaling • Hardware is expensive • Hard to scale in cloud How do you scale now? $$$ throughput
- 6. mongoDB Scaling - Single Node write read node_a1
- 7. Read scaling - add Replicas write read node_b1 node_a1
- 8. Read scaling - add Replicas write read node_c1 node_b1 node_a1
- 9. Write scaling - Sharding shard1 write read node_c1 node_b1 node_a1
- 10. Write scaling - add shards write read shard1 node_c1 node_b1 node_a1 shard2 node_c2 node_b2 node_a2
- 11. Write scaling - add shards write read shard1 node_c1 node_b1 node_a1 shard2 node_c2 node_b2 node_a2 shard3 node_c3 node_b3 node_a3
- 13. mongod architecture • mongod memory maps the numbered & .ns files • Memory mapping makes in-place updates effective • File page residency decisions left to operating system
- 14. mongod Data Files • Fixed-size extents in data files store records, indexes • Records contain documents • Unused records get placed in free lists • Indexes are B-Trees Deleted Record (Size, Offset, Next) BSON Data Header (Size, Offset, Next, Prev) Padding ... ...
- 17. Virtual Address Space 1 Collection 1 Index 1 This is your virtual memory size (mapped)
- 19. Virtual Address Space 1 Physical RAM Collection 1 Index 1 This is your resident memory size
- 22. Virtual Address Space 1 Physical RAM DiskCollection 1 Index 1 100 ns 10,000,000 ns = =
- 23. mongod Concurrency • Readers block writers • A writer blocks everything • Everybody yields periodically • When a new writer queues up, new readers block • In v2.0 and earlier, this concurrency model is global to the mongod • In v2.2, this model will be scoped to the database
- 24. Architecture Summary • Uses memory mapped files - RAM • Faster disks - more IOPS (SSDs are good!) • CPU usage low
- 26. Schema • Data model effects performance • Embedding versus Linking • Roundtrips to database • Disk seek time • Size of data to read & write • Partial versus full document writes • Partial versus full document reads
- 27. Indexes • Index common queries • Do not over index • (A) and (A,B) are equivalent, choose one
- 28. Query for {a: 7} {...} {...} {...} {...} {...} {...} {...} {...} {...} {...} {...} [-∞, 5) [5, 10) [10, ∞) [5, 7) [7, 9) [9, 10) [10, ∞) buckets[-∞, 5) buckets With Index Without index - Scan
- 29. Picking an a Index db.col.find({x: 10, y: "foo"}) scan index on x index on y remember terminate
- 30. Random Index Access Have to keep entire index in ram random email address hash
- 31. Right-Balanced Index Access Only have to keep small portion in ram Time Based ObjectId Auto Increment
- 32. > db.users.ensureIndex({uname: 1, first: 1, last: 1}) > db.users.find( { uname: "RossC0" }, {_id: 0, first: 1, last: 1}) Covered Indexes Use just the index
- 33. Schema • Schema and data usage critical for scaling and performance • Understand data access patterns • Use indexes but don't over index
- 35. Replication • mongoDB replication like MySQL replication • Asynchronous master/slave • Replica sets • A cluster of N servers • All writes to primary • Reads can be to primary (default) or a secondary • Any (one) node can be primary • Consensus election of primary • Automatic failover • Automatic recovery
- 36. How mongoDB Replication works Member 1 Member 2 Member 3 • Set is made up of 2 or more nodes
- 37. How mongoDB Replication works • Election establishes the PRIMARY • Data replication from PRIMARY to SECONDARY Member 1 Member 2 Primary Member 3
- 38. How mongoDB Replication works • PRIMARY may fail • Automatic election of new PRIMARY if majority exists Member 1 Member 2 DOWN Member 3 negotiate new master
- 39. How mongoDB Replication works • New PRIMARY elected • Replica Set re-established Member 1 Member 2 DOWN Member 3 Primary
- 40. How mongoDB Replication works • Automatic recovery Member 1 Member 3 Primary Member 2 Recovering
- 41. How mongoDB Replication works • Replica Set re-established Member 1 Member 3 Primary Member 2
- 42. > cfg = { _id : "myset", members : [ { _id : 0, host : "germany1.acme.com" }, { _id : 1, host : "germany2.acme.com" }, { _id : 2, host : "germany3.acme.com" } ] } > use admin > db.runCommand( { replSetInitiate : cfg } ) Creating a Replica Set
- 43. Replica Set Member Types • Normal {priority: 1} • Passive {priority: 0} • Cannot be elected as PRIMARY • Arbiters • Can vote in an election • Do not hold any data • Hidden {hidden: True} • Tagging: • {tags: {"dc": "germany", "rack": r23s5}}
- 44. Safe writes db.runCommand({getLastError: 1, w : 1}) • ensure write is synchronous • command returns after primary has written to memory w: n or w: 'majority' • n is the number of nodes data must be replicated to • driver will always send writes to Primary w: 'my_tag' • Each member is "tagged" e.g. "allDCs" • Ensure that the write is executed in each tagged "region" j: true • Ensures changes are flushed to the Journal
- 45. Replication features • Reads from Primary are always consistent • Reads from Secondaries are eventually consistent • Can be used to scale reads • Automatic failover if a Primary fails • Automatic recovery when a node joins the set
- 47. What is Sharding? • Ad-hoc partitioning • Consistent hashing • Amazon Dynamo • Range based partitioning • Google BigTable • Yahoo! PNUTS • mongoDB
- 48. mongoDB Sharding • Automatic partitioning and management • Range based • Convert to sharded system with no downtime • Fully consistent
- 49. > db.runCommand({addshard: "shard1"}); > db.runCommand({shardCollection: "mydb.users", key: {age: 1}}) How mongoDB Sharding works Range keys from -∞ to +∞ Ranges are stored as "chunks" -∞ +∞
- 50. > db.users.save({age: 40}) How mongoDB Sharding works Data in inserted Ranges are split into more "chunks" -∞ +∞ -∞ 40 41 +∞
- 51. > db.users.save({age: 40}) > db.users.save({age: 50}) How mongoDB Sharding works More data inserted Ranges are split into more "chunks" -∞ +∞ -∞ 40 41 +∞ 41 50 51 +∞
- 52. > db.users.save({age: 40}) > db.users.save({age: 50}) > db.users.save({age: 60}) How mongoDB Sharding works -∞ +∞ -∞ 40 41 +∞ 41 50 51 +∞ 61 +∞ 51 60
- 53. -∞ +∞ 41 +∞ 51 +∞ -∞ 40 41 50 61 +∞ 51 60 > db.users.save({age: 40}) > db.users.save({age: 50}) > db.users.save({age: 60}) How mongo Sharding works
- 54. -∞ 40 41 50 61 +∞ 51 60 shard1 > db.users.save({age: 40}) > db.users.save({age: 50}) > db.users.save({age: 60}) How mongo Sharding works
- 55. -∞ 40 41 50 61 +∞ 51 60 > db.runCommand({addshard: "shard2"}); > db.runCommand({addshard: "shard3"}); How mongoDB Sharding works
- 56. -∞ 40 41 50 61 +∞ 51 60 shard1 > db.runCommand({addshard: "shard2"}); > db.runCommand({addshard: "shard3"}); How mongoDB Sharding works
- 57. -∞ 40 41 50 61 +∞ 51 60 shard1 shard2 shard3 > db.runCommand({addshard: "shard2"}); > db.runCommand({addshard: "shard3"}); How mongoDB Sharding works
- 58. Sharding Features • Shard data without no downtime • Automatic balancing as data is written • Commands routed (switched) to correct node • Inserts - must have the Shard Key • Updates - must have the Shard Key • Queries • With Shard Key - routed to nodes • Without Shard Key - scatter gather • Indexed Queries • With Shard Key - routed in order • Without Shard Key - distributed sort merge
- 59. Architecture
- 60. Scaling with mongoDB • Schema & Index design • Simplest way to scale • Replication • Provides High Availabilty • Can be used to automatically scale reads • Sharding • Automatically scale writes
- 61. Any Questions?
- 62. @mongodb conferences, appearances, and meetups http://www.10gen.com/events http://bit.ly/mongofb Facebook | Twitter | LinkedIn http://linkd.in/joinmongo download at mongodb.org support, training, and this talk brought to you by