Scaling with mongodb

Transcription

1 Scaling with mongodb

2 Ross Lawley Python 10gen Web developer since 1999 Passionate about open source Agile methodology 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 How do you scale now? Optimization & Tuning Schema & Index Design O/S tuning Hardware configuration $$$ Vertical scaling Hardware is expensive Hard to scale in cloud throughput

6 mongodb Scaling - Single Node read node_a1 write

7 Read scaling - add Replicas read node_b1 node_a1 write

8 Read scaling - add Replicas read node_c1 node_b1 node_a1 write

9 Write scaling - Sharding read shard1 node_c1 node_b1 node_a1 write

10 Write scaling - add shards read shard1 shard2 node_c1 node_c2 node_b1 node_b2 node_a1 node_a2 write

11 Write scaling - add shards read shard1 shard2 shard3 node_c1 node_c2 node_c3 node_b1 node_b2 node_b3 node_a1 node_a2 node_a3 write

12 Understanding mongodb's architecture

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... Header (Size, Offset, Next, Prev) BSON Data Padding Deleted Record (Size, Offset, Next)...

15 Collection 1 Index 1

16 Collection 1 Virtual Address Space 1 Index 1

17 Collection 1 Virtual Address Space 1 Index 1 This is your virtual memory size (mapped)

18 Collection 1 Virtual Address Space 1 Physical RAM Index 1

19 Collection 1 Virtual Address Space 1 Physical RAM Index 1 This is your resident memory size

20 Collection 1 Virtual Address Space 1 Disk Physical RAM Index 1

21 Collection 1 Virtual Address Space 1 Disk Physical RAM Index 1 Virtual Address Space 2

22 Collection 1 Virtual Address Space 1 Disk Physical RAM 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

25 Schema

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} With Index [-, 5) [5, 10) [10, ) [-, 5) buckets [5, 7) [7, 9) [9, 10) [10, ) buckets {...} {...} {...} {...} {...} {...} {...} {...} {...} {...} {...} Without index - Scan

29 Picking an a Index db.col.find({x: 10, y: "foo"}) scan index on x terminate index on y remember

30 Random Index Access random address hash Have to keep entire index in ram

31 Right-Balanced Index Access Time Based ObjectId Auto Increment Only have to keep small portion in ram

32 Covered Indexes Use just the index > db.users.ensureindex({uname: 1, first: 1, last: 1}) > db.users.find( { uname: "RossC0" }, {_id: 0, first: 1, last: 1})

33 Schema Schema and data usage critical for scaling and performance Understand data access patterns Use indexes but don't over index

34 Replication

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 3 Member 2 Set is made up of 2 or more nodes

37 How mongodb Replication works Member 1 Member 3 Member 2 Primary Election establishes the PRIMARY Data replication from PRIMARY to SECONDARY

38 How mongodb Replication works Member 1 negotiate new master Member 3 Member 2 DOWN PRIMARY may fail Automatic election of new PRIMARY if majority exists

39 How mongodb Replication works Member 1 Member 3 Primary Member 2 DOWN New PRIMARY elected Replica Set re-established

40 How mongodb Replication works Member 1 Member 3 Primary Member 2 Recovering Automatic recovery

41 How mongodb Replication works Member 1 Member 3 Primary Member 2 Replica Set re-established

42 Creating a Replica Set > 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 } )

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

46 Sharding

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 How mongodb Sharding works > db.runcommand({addshard: "shard1"}); > db.runcommand({shardcollection: "mydb.users", key: {age: 1}}) - + Range keys from - to + Ranges are stored as "chunks"

50 How mongodb Sharding works > db.users.save({age: 40}) Data in inserted Ranges are split into more "chunks"

51 How mongodb Sharding works > db.users.save({age: 40}) > db.users.save({age: 50}) More data inserted Ranges are split into more "chunks"

52 How mongodb Sharding works > db.users.save({age: 40}) > db.users.save({age: 50}) > db.users.save({age: 60})

53 How mongo Sharding works > db.users.save({age: 40}) > db.users.save({age: 50}) > db.users.save({age: 60})

54 How mongo Sharding works > db.users.save({age: 40}) > db.users.save({age: 50}) > db.users.save({age: 60}) shard

55 How mongodb Sharding works > db.runcommand({addshard: "shard2"}); > db.runcommand({addshard: "shard3"});

56 How mongodb Sharding works > db.runcommand({addshard: "shard2"}); > db.runcommand({addshard: "shard3"}); shard

57 How mongodb Sharding works > db.runcommand({addshard: "shard2"}); > db.runcommand({addshard: "shard3"}); shard1 shard2 shard

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 download at mongodb.org conferences, appearances, and meetups Facebook Twitter LinkedIn support, training, and this talk brought to you by