introduction_to_mongodb.ppt

chris kite ,intro to mongodb,in this talk,what is mongodb? why use it? documents and collections querying javascript shell schema design,what is mongodb?,not a rdbms,mongo is not a relational database like mysql no transactions no referential integrity no joins no schema, so no columns or rows nosql,not a key-value store,mongo is not simply a key-value store like redis stores structured data rich query interface indexes map/reduce automatic sharding, gridfs, geospatial indexing, etc.,document-oriented database,records are json documents (actually bson) stored in collections no predefined schema docs in the same collection dont even need to have the same fields atomic 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?,its stupid fast!,anywhere from 2 to 10 times faster than mysql depends on which contrived benchmark youre looking at heres one i just made up:,its stupid fast!,about 50 times faster than couchdb according to /did-i-mention-mongodb-is-fast-way-to-go-mongo 2 important points: its pretty quick benchmarks are worthless unless you do them on your actual workload,its 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,its pretty painless,schemaless no more configuring database columns with types no more defining and managing migrations just stick your data in there, its fine nosql orms exist mostly because writing sql sucks mongos query language is basically json the mongo driver for your favorite language is really nice and officially supported handy javascript shell for the cli,its 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, “ . $rowname . “!“; / 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,/display/docs/production+deployments,documents and collections,documents and collections,documents are the records like objects in oop, or rows in rdbms collections are groups of documents usually represent a top-level class in your app heterogeneous set unlike rdbms tables, no predefined schema no foreign keys, so how do we reference other objects? dont! just embed the sub-item in the parent doc or, use a key for references and deal with the fact that you dont get integrity or joins,embedded objects,documents can embed other documents used to efficiently represent a relation for example:, name: brad majors, address: street: oak terrace, city: denton ,querying,queries,queries are documents query expression objects indicate a pattern to match db.users.find( last_name: smith ) several query objects for advanced queries db.users.find( age: $gte: 23 ) db.users.find( age: $in: 23,25 ),querying embedded objects,exact match an entire embedded object db.users.find( address: street: oak terrace, city: denton ) dot-notation for a partial match db.users.find( “address.city“: denton ),javascript shell,js shell,comes with mongodb launch it with mongo on the command-line try a simplified version at / 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 schema your application creates an ad-hoc schema with the objects it creates the schema is implicit in the queries your application runs,schema design,use collections to represent the top-level classes of your application but dont just make a collection for every object type these arent like tables in an rdbms less normalization, more embedding,obligatory blog post example,a blog post has an author, some text, and many comments the comments are unique per post, but one author has many posts how would you design this in sql? lets look at how we might design it in mongo,bad schema design: references,collections for posts, authors, and comments references 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 posts embed 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 required objects in the same collection are generally stored contiguously on disk spatial locality = faster if 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 performance no need to create in advance create idempotent indexes in your app with “ensure_index“,schema design limitations,no referential integrity high degree of denormalization means updating something in many places instead of on