Chris Kitechriskite.com

Intro to MongoDB

In This Talk…

What is MongoDB?Why use it?Documents and CollectionsQueryingJavaScript ShellSchema Design

What is MongoDB?

Not a RDBMS

Mongo is not a relational database like MySQLNo transactionsNo referential integrityNo joinsNo schema, so no columns or rowsNoSQL

Not a Key-Value Store

Mongo is not simply a key-value store like RedisStores structured dataRich query interfaceIndexesMap/ReduceAutomatic sharding, GridFS, geospatial indexing, etc.

Document-oriented Database

Records are JSON documents (actually BSON)Stored in collectionsNo predefined schemaDocs in the same collection don’t even need to have the same fieldsAtomic in-place operators for contention-free updates

$set, $inc, $push, $pop, etc.

Mongo Document

user = { name: "Frank Furter", occupation: "A scientist", location: "Transylvania"

}

Why Use MongoDB?

It’s Stupid Fast!

Anywhere from 2 to 10 times faster than MySQLDepends on which contrived benchmark you’re looking at

Here’s one I just made up:

MongoDB SQL0

500

1000

1500

2000

2500

3000

3500

4000

4500

Inserts / secQueries / sec

It’s Stupid Fast!

About 50 times faster than CouchDBAccording to http://www.idiotsabound.com/did-i-mention-mongodb-is-fast-way-to-go-mongo

2 important points:It’s pretty quickBenchmarks are worthless unless you do them on your actual workload

It’s Web Scale!

Sharding built-in, automatic, and *Just Works™*Just Works™ guarantee applies only if you have a cluster of shard replica sets with config servers and routing servers and you define your own shard key(s) with appropriate uniformity and granularity

Asynchronous replication for failover and redundancy

It’s Pretty Painless

SchemalessNo more configuring database columns with typesNo more defining and managing migrationsJust stick your data in there, it’s fine

NoSQLORMs exist mostly because writing SQL sucksMongo’s query language is basically JSONThe Mongo driver for your favorite language is really nice and officially supportedHandy JavaScript shell for the CLI

It’s Pretty Painless

/* First go create the database, the table, the schema, etc. */mysql_connect("localhost", "username", "password") or die(mysql_error());mysql_select_db("test") or die(mysql_error());$sql = "INSERT INTO users (name, age) VALUES ('Janet', 23)";mysql_query($sql);$result = mysql_query("SELECT * FROM users WHERE age = 23");$row = mysql_fetch_assoc($result);echo "Oh, " . $row['name'] . "!"; // prints "Oh, Janet!"

$mongo = new Mongo(); // defaults to localhost with no auth$users = $mongo->test_db->users; // database and collection created implicitly$users->insert( array('name' => 'Brad', 'age' => 25) );$user = $users->findOne( array('age' => 25) );echo "Oh, " . $user->name . "!"; // prints "Oh, Brad!"

MySQL

MongoDB

All the Cool Kids Are Doing It

http://www.mongodb.org/display/DOCS/Production+Deployments

Documents and Collections

Documents and Collections

Documents are the recordsLike objects in OOP, or rows in RDBMS

Collections are groups of documentsUsually represent a top-level class in your appHeterogeneous setUnlike RDBMS tables, no predefined schema

No foreign keys, so how do we reference other objects?

Don't! Just embed the sub-item in the parent docOr, use a key for references and deal with the fact that you don't get integrity or joins

Embedded Objects

Documents can embed other documentsUsed to efficiently represent a relation

For example:

{ name: 'Brad Majors', address: { street: 'Oak Terrace', city: 'Denton' }}

Querying

Queries

Queries are documentsQuery expression objects indicate a pattern to match

db.users.find( {last_name: 'Smith'} )

Several query objects for advanced queriesdb.users.find( {age: {$gte: 23} } )db.users.find( {age: {$in: [23,25]} } )

Querying Embedded Objects

Exact match an entire embedded objectdb.users.find( {address: {street: 'Oak Terrace', city: 'Denton'}} )

Dot-notation for a partial matchdb.users.find( {"address.city": 'Denton'} )

JavaScript Shell

JS Shell

Comes with MongoDBLaunch it with 'mongo' on the command-lineTry a simplified version at http://www.mongodb.org/Great fit since Mongo docs are basically JSON

Live Demo

If the tech demo gods allow it

Schema Design

I thought you said no schema?

There is no predefined schemaYour application creates an ad-hoc schema with the objects it createsThe schema is implicit in the queries your application runs

Schema Design

Use collections to represent the top-level classes of your applicationBut don't just make a collection for every object type

These aren't like tables in an RDBMSLess normalization, more embedding

Obligatory Blog Post Example

A blog post has an author, some text, and many commentsThe comments are unique per post, but one author has many postsHow would you design this in SQL?Let's look at how we might design it in Mongo

Bad Schema Design: References

Collections for posts, authors, and commentsReferences by manually created ID

post = { id: 150, author: 100, text: 'This is a pretty awesome post.', comments: [100, 105, 112]}author = { id: 100, name: 'Michael Arrington' posts: [150]}comment = { id: 105, text: 'Whatever this sux.'}

Better Schema Design: Embedding

Collection for postsEmbed comments, author name

post = { author: 'Michael Arrington', text: 'This is a pretty awesome post.', comments: [ 'Whatever this post sux.', 'I agree, lame!' ]}

Benefits

Embedded objects brought back in the same query as parent object

Only 1 trip to the DB server requiredObjects in the same collection are generally stored contiguously on disk

Spatial locality = fasterIf the document model matches your domain well, it can be much easier to comprehend than nasty joins

Indexes

Mongo supports indexes to greatly improve query performanceNo need to create in advanceCreate idempotent indexes in your app with "ensure_index"

Schema Design Limitations

No referential integrityHigh degree of denormalization means updating something in many places instead of oneLack of predefined schema is a double-edged sword

Hopefully you have a model in your appObjects within a collection can be completely inconsistent in their fields

Final Thoughts

Final Thoughts

MongoDB is fast no matter how you slice itIt achieves high performance by literally playing fast and loose with your data

That's not necessarily a bad thing, just a tradeoffVery rapid development, open sourceDocument model is simple but powerfulAdvanced features like map/reduce, geospatial indexing etc. are very compellingSurprisingly great drivers for most languages

Questions?

Thanks!

These slides are online:http://bit.ly/intro_to_mongo