• Share
  • Email
  • Embed
  • Like
  • Private Content
Why mongo db was created  - Dwight Merriman - MongoSF 2011
 

Why mongo db was created - Dwight Merriman - MongoSF 2011

on

  • 2,086 views

 

Statistics

Views

Total Views
2,086
Views on SlideShare
1,465
Embed Views
621

Actions

Likes
2
Downloads
25
Comments
0

10 Embeds 621

http://www.10gen.com 464
http://www.mongodb.com 145
http://drupal1.10gen.cc 3
https://www.mongodb.com 2
http://www.slideshare.net 2
http://local.10gen.com 1
url_unknown 1
http://app.mongodb.org 1
http://babble.10gen.com 1
http://localhost:8080 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Why mongo db was created  - Dwight Merriman - MongoSF 2011 Why mongo db was created - Dwight Merriman - MongoSF 2011 Presentation Transcript

    • Why MongoDB was Createdwe start at 9:30
      MongoSF 2011
      Dwight Merriman / 10gen
    • signs we needed something different
      doubleclick - 400,000 ads/second
      people writing their own stores
      caching is de rigueur
      complex ORM frameworks
      computer architecture trends
      cloud computing
    • the db space 2000 - 2010
      + great for complex transactions
      + great for tabular data
      + ad hoc queries easy
      - O<->R mapping hard
      - speed/scale challenges
      - not super agile
      + ad hoc queries easy
      + SQL gives us a standard protocol for the interface between clients and servers
      + scales horizontally better than operational dbs. some scale limits at massive scale
      - schemas are rigid
      - real time is hard; very good at bulk nightly data loads
    • the db space 2000 - 2010
      + great for complex transactions
      + great for tabular data
      + ad hoc queries easy
      - O<->R mapping hard
      - speed/scale challenges
      - not super agile
      + ad hoc queries easy
      + SQL gives us a standard protocol for the interface between clients and servers
      + scales horizontally better than operational dbs. some scale limits at massive scale
      - schemas are rigid
      - real time is hard; very good at bulk nightly data loads
    • the db space 2000 - 2010
      + great for complex transactions
      + great for tabular data
      + ad hoc queries easy
      - O<->R mapping hard
      - speed/scale challenges
      - not super agile
      + ad hoc queries easy
      + SQL gives us a standard protocol for the interface between clients and servers
      + scales horizontally better than operational dbs. some scale limits at massive scale
      - schemas are rigid
      - real time is hard; very good at bulk nightly data loads
    • the db space
      + fits OO programming well
      + agile
      + speed/scale
      - querying a little less add hoc
      - not super transactional
      - not sql
    • data models
    • as simple as possible but no simpler
    • as simple as possible but no simpler
      need a good degree of functionality to handle a large set of use cases
      sometimes need strong consistency / atomicity
      secondary indexes
      ad hoc queries
    • as simple as possible but no simpler
      but, leave out a few things so we can scale
      no choice but to leave out relational
      distributed transactions are hard to scale
    • as simple as possible but no simpler
      to scale, need a new data model. some options:
      key/value
      columnar / tabular
      document oriented (JSON inspired)
      opportunity to innovate -> agility
    • mongodb philosphy
      No longer one-size-fits all. but not 12 tools either.
      By reducing transactional semantics the db provides, one can still solve an interesting set of problems where performance is very important, and horizontal scaling then becomes easier.
      Non-relational (no joins) makes scaling horizontally practical
      Document data models are good
      Keep functionality when we can (key/value stores are great, but we nee more)
      Database technology should run anywhere, being available both for running on your own servers or VMs, and also as a cloud pay-for-what-you-use service. And ideally open source...
    • Questions?
      http://blog.mongodb.org/
      @mongodb
      me - @dmerr
      www.mongodb.org
      http://groups.google.com/group/mongodb-user
      irc://irc.freenode.net/#mongodb
      MongoNYC - June 7Mongo Hamburg - June 27MongoDC - June 27
      10AM - in this room: Schema Design
      10:45AM - break
      thanks