Technical Overview  Paul Pedersen, Deputy CTO       paul@10gen.com         Phoenix MUG        March 27, 2012
RDBMS systems                Costs go up
Productivity goes downProject Start          De-       normalize      data model                   Stop using             ...
MongoDB / NoSQL objective:                Make it as simple as possible, but no simpler                               Memc...
mongodb stores BSON{    “_id” : 123456789,    “name” : { “first”: “mongo”, “last”: “db” },    “address” : “555 University A...
MongoDB architecture• BSON object store, unique _id• mmap memory management• B-Tree indexing• single-master replication• l...
MongoDB design goals• agile development -   rich data model, well matched to OO data -   general-purpose DBMS -   simple, ...
MongoDB design goals• web scale -   eventual consistency: single master -   availability: non-blocking writes, journal-   ...
MongoDB design goals• High performance. For example:   “Last week we learned about a government agency using   mongodb to ...
MongoDB scale• We are running instances on the order of: -   25B objects -   50TB storage -   50K qps per server -   500 s...
SCHEMA DESIGN
Schema design checklist1. When do we embed data versus linking? Our decisionshere imply the answer to question 2:2. How ma...
Embedding v. linkingEmbedding is the nesting of objects and arrays inside aBSON document.Links are references between docu...
Embedding v. linkingOperations within a document are easy for the server tohandle. These operations can be fairly rich.Lin...
Embedding v. linkingEmbedded objects are a bit harder to link to than "top level"objects in collections. (http://www.mongo...
ExampleOur content management system will manage posts.Posts have titles, dates, and authors.Wed like to support commentin...
Example> db.posts.findOne(){  _id : ObjectId("4e77bb3b8a3e000000004f7a"),  when : Date("2011-09-19T02:10:11.3Z",  author :...
Disk seeks and data localitySeek = 5+ ms          Read = really really fast               Post                            ...
Disk seeks and data locality          Post       Author       Comment       Comment        Comment         Comment        ...
CollectionsCollections of documents in MongoDB are analogous totables of rows in a relational database.There is no explici...
CollectionsMongoDB does not require documents in a collection tohave the same structure.In practice, most collections are ...
AtomicitySome problems require the ability to perform atomicoperations. For example:     atomically {       if (doc.credit...
IndexesIndexes in MongoDB are highly analogous to indexes in arelational database. (B-Tree indexes)Indexes are needed for ...
Choosing indexesAs a general rule -- where you want an index in a relationaldatabase, you want an index in MongoDB.•The _i...
ExampleTo grab the whole post we might execute:  > db.posts.findOne( { _id :  ObjectId("4e77bb3b8a3e000000004f7a") } );To ...
ExampleWe may want to search for posts by tag:  > // make and index of all tags so that the query is fast:  > db.posts.ens...
ExampleWe track voters above so that no one can vote more than once.Suppose calvin wants to vote for the example post abov...
ShardingA collection may be sharded (i.e. partitioned).When sharded, the collection has a shard key, whichdetermines how t...
Sharding                                         mongos                                                                   ...
ExampleIf the posts collection is small, we would not need to shard it atall. But if posts is huge, we probably want to sh...
Shard key best practicesIt is very important that the shard key is granular enough thatdata can be partitioned among many ...
Shard key best practicesA query including a sort is sent to the same shards that would havereceived the equivalent query w...
ExampleSay you have a photo storage system, with photo entries:  {      _id: ObjectId("4d084f78a4c8707815a601d7"),      us...
SHARDING: HOW IT WORKS
Keys> db.runCommand( { shardcollection: “test.users”,                   key: { email: 1 }} )      {          name: “Jared”...
Chunks-∞            +∞
Chunks-∞                                              +∞     dan@10gen.com            scott@10gen.com              jsr@10g...
Chunks                     Split!-∞                                              +∞     dan@10gen.com            scott@10g...
Chunks     This is a             Split!          This is a      chunk                                 chunk-∞             ...
Chunks-∞                                              +∞     dan@10gen.com            scott@10gen.com              jsr@10g...
Chunks      Split!-∞                                               +∞     dan@10gen.com             scott@10gen.com       ...
ChunksMin Key           Max Key           Shard-∞                adam@10gen.com    1adam@10gen.com    jared@10gen.com   1j...
Balancing                                      mongos                                                                     ...
Balancing                                      mongos                                                                     ...
Balancing                                    mongos                                                                       ...
Balancing                                    mongos                                                                       ...
Balancing                                    mongos                                                                       ...
Balancing                                    mongos                                                                       ...
Balancing                                    mongos                                                                       ...
Balancing                                    mongos                                                                       ...
CHOOSING A SHARD KEY
ROUTING
Routed Request                         1                                        1. Query  arrives at                      ...
Scatter Gather                            1                                4                 1. Query   arrives at        ...
Distributed Merge Sort                            1                                                  1. Query   arrives at...
WritesInserts   Requires shard   db.users.insert({          key                name: “Jared”,                             ...
QueriesBy Shard      Routed             db.users.find(                                   {email: “jsr@10gen.com”})KeySorte...
REPLICATION: HOW IT WORKS
Replica Sets         Write                    Primary         Read                                AsynchronousDriver      ...
Replica Sets                   PrimaryDriver                  Secondary         Read                  Secondary         Read
Replica Sets                    Primary         Write                 AutomaticDriver                    Primary    Leader...
Replica Sets                   Secondary         Read         WriteDriver                    Primary         Read         ...
CONSISTENCY ANDDURABILITY
Strong Consistency         Write                  PrimaryDriver         Read                 Secondary                 Sec...
Eventual Consistency         Write                  PrimaryDriver                 Secondary         Read                 S...
Durability• Fire and forget• Wait for error• Wait for fsync• Wait for journal sync• Wait for replication
Fire and forgetDriver            Primary         write                            apply in memory
Get last errorDriver              Primary         write     getLastError                              apply in memory
Wait for Journal SyncDriver              Primary         write     getLastError                              apply in memo...
Wait for fsyncDriver                Primary           write     getLastError                                apply in memor...
Wait for replicationDriver              Primary                     Secondary         write     getLastError              ...
Write Concern OptionsValue          Meaning<n:integer>    Replicate to N members of replica set“majority”     Replicate to...
Tagging{ _id: “someSet”,   members: [     { _id:0, host:”A”, tags: { dc: “ny”}},     { _id:1, host:”B”, tags: { dc: “ny”}}...
Tagging              { _id: “someSet”,                 members: [                   { _id:0, host:”A”, tags: { dc: “ny”}},...
REPLICA SET OPTIONS
Priorities• Between 0..1000• Highest member that is up to date wins  –Up to date == within 10 seconds of primary• If a hig...
Slave Delay• Lags behind master by configurable time delay• Automatically hidden from clients• Protects against operator er...
Arbiters• Vote in elections• Don’t store a copy of data• Use as tie breaker
COMMON DEPLOYMENTSCENARIOS
Typical           Data CenterPrimary   Secondary      Secondary
Backup Node           Data CenterPrimary   Secondary      Secondary                         hidden = true                 ...
Disaster Recovery       Active Data Center          Standby Data CenterPrimary            Secondary       Secondarypriorit...
Multi Data CenterWest Coast DC      Central DC    East Coast DCSecondary         Primary        Secondary                 ...
mongo sharding
Quick Release History•   1.0 - August 2009: bson, BTree range query optimization•   1.2 - December 2009: map-reduce•   1.4...
Roadmap• v2.2 Projected 2012 Q1 • Concurrency: yielding and db or   collection-level locking • Improved free list implemen...
Roadmap: short List• Full text Search• Online compaction• Internal compression• Read tagging• XML / JSON transcoder Vote: ...
Thank you
Upcoming SlideShare
Loading in...5
×

2012 phoenix mug

1,797

Published on

Phoenix MongoDB Users Group

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,797
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
96
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 2012 phoenix mug

    1. 1. Technical Overview Paul Pedersen, Deputy CTO paul@10gen.com Phoenix MUG March 27, 2012
    2. 2. RDBMS systems Costs go up
    3. 3. Productivity goes downProject Start De- normalize data model Stop using joins Custom caching Custom layer sharding
    4. 4. MongoDB / NoSQL objective: Make it as simple as possible, but no simpler Memcached Key / ValueScalability & Performance RDBMS Depth of functionality
    5. 5. mongodb stores BSON{ “_id” : 123456789, “name” : { “first”: “mongo”, “last”: “db” }, “address” : “555 University Ave., Palo Alto CA 94301”, “checkins” : [ “starbucks”, “ace hardware”, “evvia” ], “loc” : [38.57, 121.62 ]} Types: • unique id • strings, dates, numbers, bool • embedded documents • arrays • regex • binary data
    6. 6. MongoDB architecture• BSON object store, unique _id• mmap memory management• B-Tree indexing• single-master replication• logical key-range sharding• global configuration manager
    7. 7. MongoDB design goals• agile development - rich data model, well matched to OO data - general-purpose DBMS - simple, but powerful query syntax - multiple secondary indexes, geo indexes - smooth path to horizontal scaling - broad integration into existing ecosystems
    8. 8. MongoDB design goals• web scale - eventual consistency: single master - availability: non-blocking writes, journal- blocking writes, replication-blocking writes - durability: journaling - partition: multi-data center replication - easy horizontal scaling by data sharding
    9. 9. MongoDB design goals• High performance. For example: “Last week we learned about a government agency using mongodb to process about 2 million transactions per second. Around 50 machines in each of 8 data centers..” Wordnik stores its entire text corpus in MongoDB - 3.5T of data in 20 billion records. The speed to query the corpus was cut to 1/4 the time it took prior to migrating to MongoDB.
    10. 10. MongoDB scale• We are running instances on the order of: - 25B objects - 50TB storage - 50K qps per server - 500 servers
    11. 11. SCHEMA DESIGN
    12. 12. Schema design checklist1. When do we embed data versus linking? Our decisionshere imply the answer to question 2:2. How many collections do we have, and what are they?3. When do we need atomic operations? These operationscan be performed within the scope of a BSON document,but not across documents.4. What indexes will we create to make query and updatesfast?5. How will we shard? What is the shard key?
    13. 13. Embedding v. linkingEmbedding is the nesting of objects and arrays inside aBSON document.Links are references between documents (by _id)There are no joins in MongoDB. (Distributed joins areinherently expensive.)Embedding is a bit like "prejoined" data.
    14. 14. Embedding v. linkingOperations within a document are easy for the server tohandle. These operations can be fairly rich.Links in contrast must be processed client-side by theapplication issuing a follow-up query.For "contains" relationships between entities, embeddingshould be be chosen.Use linking when not using linking would result in grossduplication of data.
    15. 15. Embedding v. linkingEmbedded objects are a bit harder to link to than "top level"objects in collections. (http://www.mongodb.org/display/DOCS/Dot+Notation+(Reaching+into+Objects))If the amount of data to embed is large, you may reach thelimit on size of a single object. Then consider using GridFS.If performance is an issue, embed.
    16. 16. ExampleOur content management system will manage posts.Posts have titles, dates, and authors.Wed like to support commenting and voting on posts.Wed also like posts to be taggable for searching.
    17. 17. Example> db.posts.findOne(){ _id : ObjectId("4e77bb3b8a3e000000004f7a"), when : Date("2011-09-19T02:10:11.3Z", author : "alex", title : "No Free Lunch", text : "This is the text of the post. It could be very long.", tags : [ "business", "ramblings" ], votes : 5, voters : [ "jane", "joe", "spencer", "phyllis", "li" ], comments : [ { who : "jane", when : Date("2011-09-19T04:00:10.112Z"), comment : "I agree." }, { who : "meghan", when : Date("2011-09-20T14:36:06.958Z"), comment : "You must be joking. etc etc ..." } ]}
    18. 18. Disk seeks and data localitySeek = 5+ ms Read = really really fast Post Comment Author
    19. 19. Disk seeks and data locality Post Author Comment Comment Comment Comment Comment
    20. 20. CollectionsCollections of documents in MongoDB are analogous totables of rows in a relational database.There is no explicit schema declaration. No schema object.There is a conceptual design of how the documents in thecollection will be structured.
    21. 21. CollectionsMongoDB does not require documents in a collection tohave the same structure.In practice, most collections are relatively homogenous.We can move away from this when we need -- for examplewhen adding a new field. No analog of "alter table" isrequired.
    22. 22. AtomicitySome problems require the ability to perform atomicoperations. For example: atomically { if (doc.credits > 5) { doc.credits -= 5; doc.debits += 5; } }The scope of atomicity / ACID properties is the document.We need to assure that all fields relevant to the atomicoperation are in the same document.
    23. 23. IndexesIndexes in MongoDB are highly analogous to indexes in arelational database. (B-Tree indexes)Indexes are needed for efficient query processing: both forselection and sorting.Indexes must be explicitly declared.As in a relational database, indexes can be added to existingcollections.
    24. 24. Choosing indexesAs a general rule -- where you want an index in a relationaldatabase, you want an index in MongoDB.•The _id field is automatically indexed.• Fields whose keys are looked up should be indexed.• Sort fields generally should be indexed.The MongoDB profiling facility provides useful informationfor where an index should be added that is missing.Adding an index slows writes to a collection, but not reads.
    25. 25. ExampleTo grab the whole post we might execute: > db.posts.findOne( { _id : ObjectId("4e77bb3b8a3e000000004f7a") } );To get all posts written by alex: > db.posts.find( { author : "alex" } )If the above is a common query we would create an index on the authorfield: > db.posts.ensureIndex( { author : 1 } )To get just the titles of the posts by alex: > db.posts.find( { author : "alex" }, { title : 1 } )
    26. 26. ExampleWe may want to search for posts by tag: > // make and index of all tags so that the query is fast: > db.posts.ensureIndex( { tags : 1 } ) > db.posts.find( { tags : "business" } )What if we want to find all posts commented on by meghan? > db.posts.find( { comments.who : "meghan" } )Lets index that to make it fast: > db.posts.ensureIndex( { "comments.who" : 1 } )
    27. 27. ExampleWe track voters above so that no one can vote more than once.Suppose calvin wants to vote for the example post above.The following update operation will record calvins vote. Because of the$nin sub-expression, if calvin has already voted, the update will have noeffect. > db.posts.update( { _id : ObjectId("4e77bb3b8a3e000000004f7a"), voters : { $nin : "calvin" } }, { votes : { $inc : 1 }, voters : { $push : "calvin" } );Note the above operation is atomic : if multiple users votesimultaneously, no votes would be lost.
    28. 28. ShardingA collection may be sharded (i.e. partitioned).When sharded, the collection has a shard key, whichdetermines how the collection is partitioned among shards.A BSON document (which may have significant amounts ofembedding) resides on one and only one shard.Typically (but not always) queries on a sharded collectioninvolve the shard key as part of the query expression.Changing shard keys is difficult. You will want to choose theright shard key from the start.
    29. 29. Sharding mongos config balancer configChunks = logical key range config 1 2 3 4 13 14 15 16 25 26 27 28 37 38 39 40 5 6 7 8 17 18 19 20 29 30 31 32 41 42 43 44 9 10 11 12 21 22 23 24 33 34 35 36 45 46 47 48 Shard 1 Shard 2 Shard 3 Shard 4
    30. 30. ExampleIf the posts collection is small, we would not need to shard it atall. But if posts is huge, we probably want to shard it.The shard key should be chosen based on the queries that will becommon. We want those queries to involve the shard key. • Sharding by _id is one option here. • If finding the most recent posts is a very frequent query, we would then shard on the when field.
    31. 31. Shard key best practicesIt is very important that the shard key is granular enough thatdata can be partitioned among many machines.One of the primary reasons for using sharding is to distributewrites. To do this, its important that writes hit as many chunksas possible.Another key consideration is how many shards any query hasto hit. Ideally a query would go directly from mongos to theshard (mongod) that owns the document requested.
    32. 32. Shard key best practicesA query including a sort is sent to the same shards that would havereceived the equivalent query without the sort expression. Each suchshard performs a sort on its subset of the data. Mongos merges theordered .it is usually much better performance-wise if only a portion of theindex is read/updated, so that this "active" portion can stay in RAMmost of the time.Most shard keys described above result in an even spread over theshards but also within each mongods index. It can be beneficial tofactor in some kind of timestamp at the beginning of the shard key inorder to limit the portion of the index that gets hit.
    33. 33. ExampleSay you have a photo storage system, with photo entries: { _id: ObjectId("4d084f78a4c8707815a601d7"), user_id : 42 , title: "sunset at the beach", upload_time : "2011-01-02T21:21:56.249Z" , data: ..., }You could instead build a custom id that includes the month of the uploadtime, and a unique identifier (ObjectId, MD5 of data, etc): { _id: "2011-01_4d084f78a4c8707815a601d7", user_id : 42 , title: "sunset at the beach", upload_time : "2011-01-02T21:21:56.249Z" , data: ..., }This custom id would be the key used for sharding, and also the id used toretrieve a document. It gives both a good spread across all servers, and itreduces the portion of the index hit on most queries.
    34. 34. SHARDING: HOW IT WORKS
    35. 35. Keys> db.runCommand( { shardcollection: “test.users”, key: { email: 1 }} ) { name: “Jared”, email: “jsr@10gen.com”, } { name: “Scott”, email: “scott@10gen.com”, } { name: “Dan”, email: “dan@10gen.com”, }
    36. 36. Chunks-∞ +∞
    37. 37. Chunks-∞ +∞ dan@10gen.com scott@10gen.com jsr@10gen.com
    38. 38. Chunks Split!-∞ +∞ dan@10gen.com scott@10gen.com jsr@10gen.com
    39. 39. Chunks This is a Split! This is a chunk chunk-∞ +∞ dan@10gen.com scott@10gen.com jsr@10gen.com
    40. 40. Chunks-∞ +∞ dan@10gen.com scott@10gen.com jsr@10gen.com
    41. 41. Chunks Split!-∞ +∞ dan@10gen.com scott@10gen.com jsr@10gen.com
    42. 42. ChunksMin Key Max Key Shard-∞ adam@10gen.com 1adam@10gen.com jared@10gen.com 1jared@10gen.com scott@10gen.com 1scott@10gen.com +∞ 1• Stored in the config servers• Cached in mongos• Used to route requests and keep cluster balanced
    43. 43. Balancing mongos config balancer configChunks! config 1 2 3 4 13 14 15 16 25 26 27 28 37 38 39 40 5 6 7 8 17 18 19 20 29 30 31 32 41 42 43 44 9 10 11 12 21 22 23 24 33 34 35 36 45 46 47 48 Shard 1 Shard 2 Shard 3 Shard 4
    44. 44. Balancing mongos config balancer config Imbalance Imbalance config1 2 3 45 6 7 89 10 11 12 21 22 23 24 33 34 35 36 45 46 47 48 Shard 1 Shard 2 Shard 3 Shard 4
    45. 45. Balancing mongos config balancer config Move chunk 1 to config Shard 21 2 3 45 6 7 89 10 11 12 21 22 23 24 33 34 35 36 45 46 47 48 Shard 1 Shard 2 Shard 3 Shard 4
    46. 46. Balancing mongos config balancer config config1 2 3 45 6 7 89 10 11 12 21 22 23 24 33 34 35 36 45 46 47 48 Shard 1 Shard 2 Shard 3 Shard 4
    47. 47. Balancing mongos config balancer config config 2 3 45 6 7 8 19 10 11 12 21 22 23 24 33 34 35 36 45 46 47 48 Shard 1 Shard 2 Shard 3 Shard 4
    48. 48. Balancing mongos config balancer config config 3 45 6 7 8 1 29 10 11 12 21 22 23 24 33 34 35 36 45 46 47 48 Shard 1 Shard 2 Shard 3 Shard 4
    49. 49. Balancing mongos config balancer config config 45 6 7 8 1 2 39 10 11 12 21 22 23 24 33 34 35 36 45 46 47 48 Shard 1 Shard 2 Shard 3 Shard 4
    50. 50. Balancing mongos config balancer config Chunks 1,2, and 3 have migrated config 45 6 7 8 1 2 39 10 11 12 21 22 23 24 33 34 35 36 45 46 47 48 Shard 1 Shard 2 Shard 3 Shard 4
    51. 51. CHOOSING A SHARD KEY
    52. 52. ROUTING
    53. 53. Routed Request 1 1. Query arrives at 4 mongos mongos 2. mongos routes query to a single shard 2 3. Shard returns 3 results of query 4. Results returned to clientShard 1 Shard 2 Shard 3
    54. 54. Scatter Gather 1 4 1. Query arrives at mongos mongos 2. mongos broadcasts query to all shards 2 3. Each shard returns 2 2 3 results for query 3 3 4. Results combined and returned to clientShard 1 Shard 2 Shard 3
    55. 55. Distributed Merge Sort 1 1. Query arrives at 6 mongos mongos 2. mongos broadcasts 5 query to all shards 3. Each shard locally 2 sorts results 2 2 4. Results returned to 4 4 4 mongos 5. mongos merge sorts3 3 3 individual resultsShard 1 Shard 2 Shard 3 6. Combined sorted result returned to client
    56. 56. WritesInserts Requires shard db.users.insert({ key name: “Jared”, email: “jsr@10gen.com”})Removes Routed db.users.delete({ email: “jsr@10gen.com”}) Scattered db.users.delete({name: “Jared”})Updates Routed db.users.update( {email: “jsr@10gen.com”}, Scattered db.users.update( “CA”}}) {$set: { state: {state: “FZ”}, {$set:{ state: “CA”}} )
    57. 57. QueriesBy Shard Routed db.users.find( {email: “jsr@10gen.com”})KeySorted by Routed in order db.users.find().sort({email:-1})shard keyFind by non Scatter Gather db.users.find({state:”CA”})shard keySorted by Distributed merge db.users.find().sort({state:1}) sortnon shardkey
    58. 58. REPLICATION: HOW IT WORKS
    59. 59. Replica Sets Write Primary Read AsynchronousDriver Secondary Replication Read Secondary Read
    60. 60. Replica Sets PrimaryDriver Secondary Read Secondary Read
    61. 61. Replica Sets Primary Write AutomaticDriver Primary Leader Election Read Secondary Read
    62. 62. Replica Sets Secondary Read WriteDriver Primary Read Secondary Read
    63. 63. CONSISTENCY ANDDURABILITY
    64. 64. Strong Consistency Write PrimaryDriver Read Secondary Secondary
    65. 65. Eventual Consistency Write PrimaryDriver Secondary Read Secondary Read
    66. 66. Durability• Fire and forget• Wait for error• Wait for fsync• Wait for journal sync• Wait for replication
    67. 67. Fire and forgetDriver Primary write apply in memory
    68. 68. Get last errorDriver Primary write getLastError apply in memory
    69. 69. Wait for Journal SyncDriver Primary write getLastError apply in memory j:true Write to journal
    70. 70. Wait for fsyncDriver Primary write getLastError apply in memory fsync:true fsync
    71. 71. Wait for replicationDriver Primary Secondary write getLastError apply in memory w:2 replicate
    72. 72. Write Concern OptionsValue Meaning<n:integer> Replicate to N members of replica set“majority” Replicate to a majority of replica set members<m:modeName> Use custom error mode name
    73. 73. Tagging{ _id: “someSet”, 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: { veryImportant: { dc: 3 }, sortOfImportant: { dc: 2 } } } }
    74. 74. Tagging { _id: “someSet”, 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: {These are the veryImportant: { dc: 3 },modes you can sortOfImportant: { dc: 2 } use in write } concern } }
    75. 75. REPLICA SET OPTIONS
    76. 76. Priorities• Between 0..1000• Highest member that is up to date wins –Up to date == within 10 seconds of primary• If a higher priority member catches up, it will force election and win Primary Secondary Secondary priority = 100 priority = 50 priority = 20
    77. 77. Slave Delay• Lags behind master by configurable time delay• Automatically hidden from clients• Protects against operator errors –Accidentally delete database –Application corrupts data
    78. 78. Arbiters• Vote in elections• Don’t store a copy of data• Use as tie breaker
    79. 79. COMMON DEPLOYMENTSCENARIOS
    80. 80. Typical Data CenterPrimary Secondary Secondary
    81. 81. Backup Node Data CenterPrimary Secondary Secondary hidden = true backups
    82. 82. Disaster Recovery Active Data Center Standby Data CenterPrimary Secondary Secondarypriority = 1 priority = 1
    83. 83. Multi Data CenterWest Coast DC Central DC East Coast DCSecondary Primary Secondary priority = 1
    84. 84. mongo sharding
    85. 85. Quick Release History• 1.0 - August 2009: bson, BTree range query optimization• 1.2 - December 2009: map-reduce• 1.4 - March 2010: background indexing, geo indexes• 1.6 - August 2010: sharding, replica sets• 1.8 - March 2011: journaling, sparse and covered indexes• 1.10 = 2.0 - Sep 2011: cumulative performance improvements
    86. 86. Roadmap• v2.2 Projected 2012 Q1 • Concurrency: yielding and db or collection-level locking • Improved free list implementation • New aggregation framework • TTL Collections• Hash shard key
    87. 87. Roadmap: short List• Full text Search• Online compaction• Internal compression• Read tagging• XML / JSON transcoder Vote: http://jira.mongodb.org/
    88. 88. Thank you
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×