Scaling with MongoDB

Alvin Richards
[email protected]
 Agenda

• Vertical Scaling
• Horizontal Scaling with MongoDB
• Schema & Index design
• Auto Sharding
• Replication
 Scaling

• Operations/sec go up
• Storage needs go up
• Capacity
• IOPs
• Complexity goes up
• Caching
 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
MongoDB Scaling - Single Node
read

node_a1

write
Read scaling - add Replicas
read

node_b1

node_a1

write
Read scaling - add Replicas
read

node_c1

node_b1

node_a1

write
Write scaling - Sharding
read

shard1

node_c1

node_b1

node_a1

write
Write scaling - add Shards
read

shard1 shard2

node_c1 node_c2

node_b1 node_b2

node_a1 node_a2

write
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
 Scaling with MongoDB

• Schema & Index Design

• Sharding
• Replication
 Schema

• Data model effects performance

• Embedding versus Linking
• Roundtrips to database
• Disk seek time
• Size if data to read & write
• Partial versus full document writes

• Performance problems can be solved by changing

schema

not schema less - dynamic schema

schema is just as important, or more important than relational
understand write vs read tradeoffs
 Indexes

• Index common queries

• Do not over index
•(A) and (A,B) are equivalent, choose one
• Right-balanced indexes keep working set small

most common performance problem

why _id index can be ignored
Random Index Access

Entire index
in ram
Right-Balanced Index Access

Small portion
in ram
 What is Sharding

• Ad-hoc partitioning
• Consistent hashing
• Amazon Dynamo
• Range based partitioning
• Google BigTable
• Yahoo! PNUTS
• MongoDB

sharding isn’t new

 MongoDB Sharding

• Automatic partitioning and management

• Range based
• Convert to sharded system with no downtime
• Almost no functionality lost over single master
• Fully consistent
 How MongoDB Sharding works

>  db.runCommand(  {  addshard  :  "shard1"  }  );

-∞   +∞  

•Range keys from -∞ to +∞  

•Ranges are stored as “chunks”
 How MongoDB Sharding works

>  db.posts.save(  {age:40}  )

-∞   +∞  

-∞   40 41 +∞  

•Data in inserted
•Ranges are split into more “chunks”
 How MongoDB Sharding works

>  db.posts.save(  {age:40}  )

>  db.posts.save(  {age:50}  )

-∞   +∞  

-∞   40 41 +∞  
41 50 51 +∞  
•More Data in inserted
•Ranges are split into more“chunks”
 How MongoDB Sharding works

>  db.posts.save(  {age:40}  )

>  db.posts.save(  {age:50}  )
>  db.posts.save(  {age:60}  )

-∞   +∞  

-∞   40 41 +∞  
41 50 51 +∞  
51 60 61 +∞  
 How MongoDB Sharding works

>  db.posts.save(  {age:40}  )

>  db.posts.save(  {age:50}  )
>  db.posts.save(  {age:60}  )

-∞   +∞  

-∞   40 41 +∞  
41 50 51 +∞  
51 60 61 +∞  
 How MongoDB Sharding works

shard1
-∞   40
41 50
51 60
61 +∞  
 How MongoDB Sharding works

>  db.runCommand(  {  addshard  :  "shard2"  }  );

-∞   40
41 50
51 60
61 +∞  
 How MongoDB Sharding works

>  db.runCommand(  {  addshard  :  "shard2"  }  );

shard1
-∞   40
41 50
51 60
61 +∞  
 How MongoDB Sharding works

>  db.runCommand(  {  addshard  :  "shard2"  }  );

shard1 shard2
-∞   40
41 50
51 60
61 +∞  
 How MongoDB Sharding works

>  db.runCommand(  {  addshard  :  "shard2"  }  );

>  db.runCommand(  {  addshard  :  "shard3"  }  );

shard1 shard2 shard3

-∞   40
41 50
51 60
61 +∞  
 Sharding Key Examples
{
     server  :  "ny153.example.com"  ,
     application  :  "apache"  ,
     time  :  "2011-­‐01-­‐02T21:21:56.249Z"  ,
     level  :  "ERROR"  ,
     msg  :  "something  is  broken"
}

•Good  :  {server:1}
• All data for one server is in a single chunk
• Chunk cannot be split any smaller

•Better  :  {server:1,time:1}
‣  Chunk  can  be  split  by  millisecond
 Sharding Key Examples
{
     server  :  "ny153.example.com"  ,
     application  :  "apache"  ,
     time  :  "2011-­‐01-­‐02T21:21:56.249Z"  ,
     level  :  "ERROR"  ,
     msg  :  "something  is  broken"
}

•Good  :  {time  :  1}

‣ Time is an increasing number
‣ All data will be first written to a single shard
‣ Data balanced to other shards later

•Better  :  {server:1,application:1,time:1}
‣More key values to enable writes to all shards
 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
 MongoDB Replication

• MongoDB replication like MySQL replication

•Asynchronous master/slave

• Variations:
•Master / slave
•Replica Sets
 Replica Set features
• A cluster of N servers
• Any (one) node can be primary
• Consensus election of primary
• Automatic failover
• Automatic recovery
• All writes to primary
• Reads can be to primary (default) or a secondary
 How MongoDB Replication works

Member  1
Member  3

Member  2

•Set is made up of 2 or more nodes

 How MongoDB Replication works

Member  1
Member  3

Member  2
PRIMARY

•Election establishes the PRIMARY

•Data replication from PRIMARY to
SECONDARY
 How MongoDB Replication works
negotiate  
new  master
Member  1
Member  3

Member  2
DOWN

•PRIMARY may fail

•Automatic election of new PRIMARY
 How MongoDB Replication works

Member  1
Member  3
PRIMARY

Member  2
DOWN

•New PRIMARY elected

•Replication Set re-established
 How MongoDB Replication works

Member  1
Member  3
PRIMARY

Member  2
RECOVERING

•Automatic recovery
 How MongoDB Replication works

Member  1
Member  3
PRIMARY

Member  2

•Replication Set re-established

 Using Replicas

slaveOk()
- driver will send read requests to Secondaries
- driver will always send writes to Primary

Java examples
-­‐  DB.slaveOk()
-­‐  Collection.slaveOk()
-­‐  find(q).addOption(Bytes.QUERYOPTION_SLAVEOK);
 Creating a Replica Set

>  cfg  =  {
...  _id  :  "acme_a",
...  members  :  [
...  {  _id  :  0,  host  :  "sf1.acme.com"  },
...  {  _id  :  1,  host  :  "sf2.acme.com"  },
...  {  _id  :  2,  host  :  "sf3.acme.com"  }  ]  }
>  use  admin
>  db.runCommand({replSetInitiate:cfg})
 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
 Replication features

• Reads from Primary are always consistent

• Reads from Secondaries are eventually consistent
• Automatic failover if a Primary fails
• Automatic recovery when a node joins the set
 Summary

• Schema & Index design

• Simplest way to scale

•Sharding
• Automatically scale writes
•Replication
•Automatically scale reads
 download at mongodb.org

conferences,  appearances,  and  meetups

http://www.10gen.com/events

Facebook                    |                  Twitter                  |                  LinkedIn

http://bit.ly/mongoJ   @mongodb http://linkd.in/joinmongo