1. Solution Architect, MongoDB
Sam Weaver
#MongoDBBasics
‘MongoDB Back to Basics’
Build something Big with
MongoDB

2. Agenda
• Replica Sets Lifecycle
• Developing with Replica Sets
• Scaling your database

3. Q&A
• Virtual Genius Bar
– Use chat to post questions
– SolutionArchitecture /
Support Team are on
hand
– Make use of them during
the sessions!!!

4. Recap
• Introduction to MongoDB
• Thinking in documents

5. Deployment Considerations

6. Working Set Exceeds Physical
Memory

7. Why Replication?
• How many have faced node failures?
• How many have been woken up from sleep to do a
fail-over(s)?
• How many have experienced issues due to network
latency?
• Different uses for data
– Normal processing
– Simple analytics

8. Replica Set Lifestyle

9. Replica Set – Creation

10. Replica Set – Initialize

11. Replica Set – Failure

12. Replica Set – Failover

13. Replica Set – Recovery

14. Replica Set – Recovered

15. Developing with
Replica Sets

16. Strong Consistency

17. Delayed Consistency

18. Write Concern
• Network acknowledgement
• Wait for error
• Wait for journal sync
• Wait for replication

19. Unacknowledged

20. MongoDB Acknowledged (wait for
error)

21. Wait for Journal Sync

22. Wait for Replication

23. Tagging
• Control where data is written to, and read from
• Each member can have one or more tags
– tags: {dc: "ny"}
– tags: {dc: "ny", subnet: "192.168", rack:
"row3rk7"}
• Replica set defines rules for write concerns
• Rules can change without changing app code

24. {
_id : "mySet",
members : [
{_id : 0, host : "A", tags : {"dc": "ny"}},
{_id : 1, host : "B", tags : {"dc": "ny"}},
{_id : 2, host : "C", tags : {"dc": "sf"}},
{_id : 3, host : "D", tags : {"dc": "sf"}},
{_id : 4, host : "E", tags : {"dc": "cloud"}}],
settings : {
getLastErrorModes : {
allDCs : {"dc" : 3},
someDCs : {"dc" : 2}} }
}
> db.blogs.insert({...})
> db.runCommand({getLastError : 1, w : "someDCs"})
Tagging Example

25. Wait for Replication (Tagging)

26. Read Preference Modes
• 5 modes
– primary (only) - Default
– primaryPreferred
– secondary
– secondaryPreferred
– Nearest
When more than one node is possible, closest node is used
for reads (all modes but primary)

27. Tagged Read Preference
• Custom read preferences
• Control where you read from by (node) tags
– E.g. { "disk": "ssd", "use": "reporting" }
• Use in conjunction with standard read
preferences
– Except primary

28. Our application
//connect to a replica set, with auto-discovery of the primary, supply a seed
list of members
MongoClient mongoClient = new MongoClient(Arrays.asList(new
ServerAddress("localhost", 27017),
new ServerAddress("localhost", 27018),
new ServerAddress("localhost", 27019)));
DB db = mongoClient.getDB( "mydb" );

29. Scaling

30. Working Set Exceeds Physical
Memory

31. • When a specific resource becomes a bottle
neck on a machine or replica set
• RAM
• Disk IO
• Storage
• Concurrency
When to consider Sharding?

32. Vertical Scalability (Scale Up)

33. Horizontal Scalability (Scale Out)

34. Partitioning
• User defines shard key
• Shard key defines range of data
• Key space is like points on a line
• Range is a segment of that line

35. Initially 1 chunk
Default max chunk size: 64mb
MongoDB automatically splits & migrates chunks
when max reached
Data Distribution

36. Architecture

37. What is a Shard?
• Shard is a node of the cluster
• Shard can be a single mongod or a replica set

38. Meta Data Storage
• Config Server
– Stores cluster chunk ranges and locations
– Can have only 1 or 3 (production must have 3)
– Not a replica set

39. Routing and Managing Data
• Mongos
– Acts as a router / balancer
– No local data (persists to config database)
– Can have 1 or many

40. Sharding infrastructure

41. Cluster Request Routing
• Targeted Queries
• Scatter Gather Queries
• Scatter Gather Queries with Sort

42. Cluster Request Routing: Targeted
Query

43. Routable request received

44. Request routed to appropriate
shard

45. Shard returns results

46. Mongos returns results to client

47. Cluster Request Routing: Non-Targeted
Query

48. Non-Targeted Request Received

49. Request sent to all shards

50. Shards return results to mongos

51. Mongos returns results to client

52. Cluster Request Routing: Non-Targeted
Query with Sort

53. Non-Targeted request with sort
received

54. Request sent to all shards

55. Query and sort performed locally

56. Shards return results to mongos

57. Mongos merges sorted results

58. Mongos returns results to client

59. Shard Key

60. Shard Key
• Shard key is immutable
• Shard key values are immutable
• Shard key must be indexed
• Shard key limited to 512 bytes in size
• Shard key used to route queries
– Choose a field commonly used in queries
• Only shard key can be unique across shards
– `_id` field is only unique within individual shard

61. Summary

62. Things to remember
• Size appropriately for your working set
• Shard when you need to, not before
• Pick a shard key wisely

63. Thank you