Tech Gupshup Meetup On MongoDB - 24/06/2016

1. MongoDB
Tech Gupshup

2. In This Talk…
• What is MongoDB?
• Why use it?
• Documents and Collections
• Querying
• JavaScript Shell
• Schema Design

3. What is MongoDB?

4. 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

5. Not a Key-Value Store
• Mongo is not simply a key-value store like
Redis
• Stores structured data
• Indexes
• Map/Reduce
• Sharding, GridFS, etc.

6. Document-oriented Database
• Records are JSON documents (actually BSON)
• Stored in collections
• No predefined schema
• Docs in the same collection don’t even need to
have the same fields
• Operators for updates
–$set, $inc, $push, $pop, etc.

7. Mongo Document
• user = {
• name: "Frank Furter",
• occupation: "A scientist",
• location: "Transylvania"
• }

8. Why Use MongoDB?

9. • Organizations of all sizes are adopting
MongoDB because it enables them to build
applications faster, handle highly diverse data
types, and manage applications more
efficiently at scale.
• MongoDB’s flexible data model also means
that your database schema can evolve with
business requirements.

10. It’s Web Scale!
• Sharding built-in, automatic - As your
deployments grow in terms of data volume and
throughput, MongoDB scales easily with no
downtime, and without changing your
application. In contrast, to achieve scale with
MySQL often requires significant, custom
engineering work.

11. • Asynchronous replication for failover and
redundancy

12. It’s Pretty Painless
• Schemaless
– No more configuring database columns with types
– No more defining and managing migrations
– Just stick your data in there, it’s fine
• NoSQL
– Mongo’s query language is basically JSON
– The Mongo driver for your favorite language is
really nice and officially supported
– Handy JavaScript shell for the CLI

13. 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!"

14. Documents and
Collections

15. 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
– Unlike 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 doc
– Or, use a key for references and deal with the fact that you
don't get integrity or joins

16. Embedded Objects
• Documents can embed other documents
– Used to efficiently represent a relation
• For example:
{
name: 'Brad Majors',
address:
{
street: 'Oak Terrace',
city: 'Denton'
}
}

17. Querying

18. 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]} } )

19. 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'} )

20. JavaScript Shell

21. JS Shell
• Comes with MongoDB
• Launch it with 'mongo' on the command-line

22. Schema Design

23. • There is no predefined schema
• Your application creates an schema with the
objects it creates
• The schema is implicit in the queries your
application runs

24. Schema Design
• Use collections to represent the top-level
classes of your application
• But don't just make a collection for every
object type
– These aren't like tables in an RDBMS
• Less normalization, more embedding

25. 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?
• Let's look at how we might design it in Mongo

26. 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.'
}

27. 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!'
]
}

28. 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

29. Indexes
• Mongo supports indexes to greatly improve
query performance

30. Schema Design Limitations
• No referential integrity
• High degree of denormalization means
updating something in many places instead of
one
• Lack of predefined schema is a double-edged
sword
– Objects within a collection can be completely
inconsistent in their fields

31. Final Thoughts

32. Final Thoughts
• MongoDB is fast
• Very rapid development, open source
• Document model is simple but powerful
• Advanced features like map/reduce etc. are
very compelling
• Surprisingly great drivers for most languages

33. Questions?