MongoDB Pros and Cons

of 47/47
  • date post

  • Category


  • view

  • download


Embed Size (px)

Transcript of MongoDB Pros and Cons

  • MongoDB

  • My name isJohn Jenson

  • 12 years writing code11 years using Oracle9 months using MongoBYU AlumnusPrincipal Engineer @ CengageCurrently doing MEAN stack dev

  • When to use MongoDB?

  • Dont want/need a rigid schema

    Need horizontally scalable performance for high loads

    Make sure you wont need real-time reporting that aggregates a lot of disparate data

  • Use Cases for Mongo

  • Problem:Business needed more flexibility than Oracle could deliverSolution:Used MongoDB instead of OracleResults:Developed application in one sprint cycle500% cost reduction compared to Oracle900% performance improvement compared to Oracle

    Photo Meta-DataSlide Courtesy of Steve Francia -

  • Solution:Switched from MySQL to MongoDBResults:Massive simplification of code base Eliminated need for external caching system20x performance improvement over MySQL Online DictionaryProblem:MySQL could not scale to handle their 5B+ documentsSlide Courtesy of Steve Francia -

  • Solution:Switched from MySQL to MongoDBResults:Massive simplification of code base Rapidly build, halving time to market (and cost)Eliminated need for external caching system50x+ improvement over MySQLE-commerceProblem:Multi-vertical E-commerce impossible to model (efficiently) in RDBMS Slide Courtesy of Steve Francia -

  • Mongos PhilosophyMongo tries to provide a good degree of functionality to handle a large set of use casessometimes need strong consistency / atomicitysecondary indexesad hoc queries

  • Had to leave out a few things in order to scaleNo Joinsno choice here. Cant have joins if we want to scale horizontallyNo ACID Transactionsdistributed transactions are hard to scaleMongo does not support multi-document transactionsOnly document level atomic operations provided

  • MongoDBJSON DocumentsQuerying/Indexing/Updating similar to relational databasesConfigurable ConsistencyAuto-Sharding

  • Database LandscapeSlide Courtesy of Steve Francia -

  • MongoDB is:Horizontally Scalable{ author: steve, date: new Date(), text: About MongoDB..., tags: [tech, database]}Document OrientedApplicationHigh PerformanceSlide Courtesy of Steve Francia -

  • MongoDB has the best features of key/ values stores, document databases and relational databases in one.John Nunemaker

  • Schema Design

  • Normalized Relational DataSlide Courtesy of Steve Francia -

  • Document databases make normalized data look like thisSlide Courtesy of Steve Francia -

  • TerminologySlide Courtesy of Steve Francia -

    RDBMSMongoTable, ViewCollectionRowJSON DocumentIndexIndexJoinEmbedded DocumentPartitionShardPartition KeyShard Key

  • Create CollectionSQL equivalent CREATE TABLE posts( col1 col1_type, col2 col2_type, )> db.createCollection('posts)

  • Insert DocumentSQL equivalent INSERT INTO posts (col1, col2, ) VALUES (val1, val2, )> p = {author: "roger", date: new Date(), text: "about mongoDB...", tags: ["tech", "databases"]}


  • Querying

    > db.posts.find()

    > { _id : ObjectId("4c4ba5c0672c685e5e8aabf3"), author : "roger", date : "Sat Jul 24 2010 19:47:11", text : "About MongoDB...", tags : [ "tech", "databases" ] } SQL equivalent SELECT * FROM POSTS

  • Secondary IndexesCreate index on any field in document // 1 means ascending, -1 means descending > db.posts.ensureIndex({author: 1}) > db.posts.find({author: 'roger'}) > { _id : ObjectId("4c4ba5c0672c685e5e8aabf3"), author : "roger", ... }SQL equivalent CREATE INDEX ON posts(author)

  • Conditional Query Operators

    $all, $exists, $mod, $ne, $in, $nin, $nor, $or, $size, $type, $lt, $lte, $gt, $gte

    // find posts with any tags > db.posts.find( {tags: {$exists: true }} )

    // find posts matching a regular expression> db.posts.find( {author: /^rog*/i } )

    // count posts by author> db.posts.find( {author: roger} ).count()

  • Update Operations $set, $unset, $inc, $push, $pushAll, $pull, $pullAll, $bit> comment = { author: fred, date: new Date(), text: Best Movie Ever}

    > db.posts.update( { _id: ... }, $push: {comments: comment} );

  • Secondary Indexes// Index nested documents> db.posts.ensureIndex( 1)> db.posts.find({})

    // Compound index> db.posts.ensureIndex({author: 1, date: 1})> db.posts.find({author: Fred, date: { $gt: Sat Apr 24 2011 19:47:11} })

    // Multikey index (index on tags array)> db.posts.ensureIndex( tags: 1)> db.posts.find( { tags: tech } )

    // Text index> db.posts.ensureIndex( text: text )> db.posts.find( { $text: { $search: Mongo} } )

  • Our Use Case for MongoWe needed to prototype some app ideas for a class test in the market. We didnt want a hardened schema. Just wanted to get stuff out quick to try it out.We made sure that real-time analytic reporting wasnt needed.We were using nodejs on the backend so Mongo was a natural fit.

  • What we gained by using MongoFaster turnaround in developmentThe flexibility to figure out our schema design as we went and change our minds often if neededA database that we could scale horizontally if needed in the future

  • What we gave up by using MongoNo multi-document transactions. This means We could not guarantee consistency in some cases.Cant write queries that use more than one collection. Aggregation framework only works on one collection at a time. Joining data has to be done programmatically and doesnt scale.Nesting isnt always possible, and there are no foreign key constraints to enforce consistency.

  • Mongo Architecture

  • LimitationsMax BSON document size is 16MBMongo provides GridFS to get around thisNo more than 100 levels of nestingNo more than 12 members in a replica set

  • ScalingSharding MongoDB

  • MongoDB ShardingShard data without no downtimeAutomatic balancing as data is writtenRange based or hash based sharding

  • Accessing a sharded collectionInserts - must have the Shard KeyUpdates - must have the Shard KeyQueries With Shard Key - routed to nodes Without Shard Key - scatter gatherIndexed Queries With Shard Key - routed in order Without Shard Key - distributed sort merge

  • High Availability

  • MongoDB ReplicationMongoDB replication like MySQL replication (kinda)Asynchronous master/slaveVariationsMaster / slaveReplica Sets

  • 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 Control of where writes occur

  • How MongoDB Replication worksSet is made up of 2 or more nodes

  • How MongoDB Replication worksElection establishes the PRIMARYData replication from PRIMARY to SECONDARY

  • How MongoDB Replication worksPRIMARY may failAutomatic election of new PRIMARY if majority existsnegotiate new master

  • How MongoDB Replication worksNew PRIMARY electedReplication Set re-established

  • How MongoDB Replication worksAutomatic recovery

  • How MongoDB Replication worksReplication Set re-established

  • Typical Deployments

    Use?Set sizeData ProtectionHigh AvailabilityNotesXOneNoNoMust use --journal to protect against crashesTwoYesNoOn loss of one member, surviving member is read onlyThreeYesYes - 1 failureOn loss of one member, surviving two members can elect a new primaryXFourYesYes - 1 failure** On loss of two members, surviving two members are read only FiveYesYes - 2 failuresOn loss of two members, surviving three members can elect a new primary

  • Replica Set features A cluster of up to 12 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

  • Mongo Architecture