Downloaded 412 times
![MongoDB: The Leading NoSQL Database
Document
Data Model
Open-
Source
Fully Featured
High Performance
Scalable
{
name: “John Smith”,
pfxs: [“Dr.”,”Mr.”],
address: “10 3rd St.”,
phones: [
{ number: “555-1212”,
type: “land” },
{ number: “444-1212”,
type: “mobile” }
]
}](https://image.slidesharecdn.com/learnmdbmug20160107-160108020149/85/Introduction-to-MongoDB-4-320.jpg)
![{
_id: “123”,
title: "MongoDB: The Definitive Guide",
authors: [
{ _id: "kchodorow", name: "Kristina Chodorow“ },
{ _id: "mdirold", name: “Mike Dirolf“ }
],
published_date: ISODate(”2010-09-24”),
pages: 216,
language: "English",
thumbnail: BinData(0,"AREhMQ=="),
publisher: {
name: "O’Reilly Media",
founded: 1980,
locations: ["CA”, ”NY” ]
}
}
The Data Is The Schema](https://image.slidesharecdn.com/learnmdbmug20160107-160108020149/85/Introduction-to-MongoDB-9-320.jpg)
![> db.authors.find()
{
_id: ”X12",
name: { first: "Kristina”, last: “Chodorow” },
personalData: {
favoritePets: [ “bird”, “dog” ],
awards: [ {name: “Hugo”, when: 1983}, {name: “SSFX”,
when: 1992} ]
}
}
{
_id: ”Y45",
name: { first: ”Mike”, last: “Dirolf” } ,
personalData: {
dob: ISODate(“1970-04-05”)
}
}
Treat Your Data More Like Objects](https://image.slidesharecdn.com/learnmdbmug20160107-160108020149/85/Introduction-to-MongoDB-10-320.jpg)
![// Java: maps
DBObject query = new BasicDBObject(”publisher.founded”, 1980));
Map m = collection.findOne(query);
Date pubDate = (Date)m.get(”published_date”); // java.util.Date
List locs = (List)m.get(”locations”);
// Javascript: objects
m = collection.findOne({”publisher.founded” : 1980});
pubDate = m.published_date; // ISODate
year = pubDate.getUTCFullYear();
# Python: dictionaries
m = coll.find_one({”publisher.founded” : 1980 });
pubDate = m[”pubDate”].year # datetime.datetime
Documents Natively Map to Language](https://image.slidesharecdn.com/learnmdbmug20160107-160108020149/85/Introduction-to-MongoDB-11-320.jpg)
![21
Verify Operation
$ mongodb-osx-x86_64-enterprise-3.2.0/bin/mongo
MongoDB shell version: 3.2.0
connecting to: 127.0.0.1:27017/test
Server has startup warnings:
2016-01-01T12:44:01.646-0500 I CONTROL [initandlisten]
2016-01-01T12:44:01.646-0500 I CONTROL [initandlisten] ** WARNING:
soft rlimits too low. Number of files is 256, should be at least
1000
MongoDB Enterprise > use mug
switched to db mug
MongoDB Enterprise > db.foo.insert({name:”bob”,hd: new ISODate()});
MongoDB Enterprise > db.foo.insert({name:"buzz"});
MongoDB Enterprise > db.foo.insert({pets:["dog","cat"]});
MongoDB Enterprise > db.foo.find();
{ "_id" : ObjectId("5686cef538ea4981e63111dd"), "name" : "bob", "hd"
: ISODate("2016-01-01T19:09:41.442Z") }
{ "_id" : ObjectId("5686…79d5"), "name" : "buzz" }
{ "_id" : ObjectId("5686…79d6"), "pets" : [ "dog", "cat" ] }](https://image.slidesharecdn.com/learnmdbmug20160107-160108020149/85/Introduction-to-MongoDB-21-320.jpg)
![22
The Simple Java App
import com.mongodb.client.*;
import com.mongodb.*;
import java.util.Map;
public class mug1 {
public static void main(String[] args) {
try {
MongoClient mongoClient = new MongoClient();
MongoDatabase db = mongoClient.getDatabase("mug”);
MongoCollection coll = db.getCollection("foo");
MongoCursor c = coll.find().iterator();
while(c.hasNext()) {
Map doc = (Map) c.next();
System.out.println(doc);
}
} catch(Exception e) {
// ...
}
}
}](https://image.slidesharecdn.com/learnmdbmug20160107-160108020149/85/Introduction-to-MongoDB-22-320.jpg)
![23
Compile and Run!
$ curl -o mongodb-driver-3.0.4.jar
https://oss.sonatype.org/content/repositories/releases/org
/mongodb/mongodb-driver/3.0.4/mongodb-driver-3.0.4.jar
$ javac –cp mongo-java-driver-3.0.4.jar:. mug1.java
$ java –cp mongo-java-driver-3.0.4.jar:. mug1
(logger output)
Document{{_id=5686cef538ea4981e63111dd, name=bob,
hd=Fri Jan 01 14:09:41 EST 2016}}
Document{{_id=5686c71338ea4981e63111d6, name=buzz}}
Document{{_id=5686c71938ea4981e63111d7, pets=[dog, cat]}}](https://image.slidesharecdn.com/learnmdbmug20160107-160108020149/85/Introduction-to-MongoDB-23-320.jpg)
![24
The Same App in python
from pymongo import MongoClient
client = MongoClient()
db = client.mug
coll = db.foo
for c in coll.find():
print c
$ python mug1.py
{u'_id': ObjectId('5686cef538ea4981e63111dd'), u'name': u'bob',
u'hd': datetime.datetime(2016, 1, 1, 19, 9, 41, 442000)}
{u'_id': ObjectId('5686f54b38ea4981e631124c'), u'name': u'buzz'}
{u'_id': ObjectId('5686f55138ea4981e631124d'), u'pets': [u'dog',
u'cat']}](https://image.slidesharecdn.com/learnmdbmug20160107-160108020149/85/Introduction-to-MongoDB-24-320.jpg)
![25
…and, as expected in Perl…
$ perl -MMongoDB -MData::Dumper –e 'my $c =
MongoDB::MongoClient->new()->get_database("mug")-
>get_collection("foo")->find(); while($c->has_next()) {
print Dumper($c->next()); }’
$VAR1 = { '_id' => bless( {'value' => '5686cef538ea4981e63111dd’},
'MongoDB::OID' ),
'hd' => bless( {
'local_rd_secs' => 68981,
'rd_nanosecs' => 442000000, // etc
}, 'DateTime' ),
'name' => 'bob'
};
$VAR1 = { '_id' => bless( {'value' => '5686c71338ea4981e63111d6’},
'MongoDB::OID' ),
'name' => 'buzz'
};
$VAR1 = { 'pets' => [ 'dog’,'cat’],
'_id' => bless( {'value' => '5686c71938ea4981e63111d7’},
'MongoDB::OID' )
};](https://image.slidesharecdn.com/learnmdbmug20160107-160108020149/85/Introduction-to-MongoDB-25-320.jpg)
![Document Validation: Stronger Than
Schema…?
> db.createCollection(”contacts", { "validator":
{ $or: [
{ $and: [ { “vers": 1},
{ ”customer_id": {$type: “string”} }
]
},
{ $and: [ { "vers": 2},
{ ”customer_id": {$type: “string”} },
{ $or: [
{ ”name.f": {$type: “string”},
”name.l": {$type: “string”}}
,
{ ”ssn": {$type: “string”}}
]
}
]
}]});](https://image.slidesharecdn.com/learnmdbmug20160107-160108020149/85/Introduction-to-MongoDB-27-320.jpg)
![A Slightly Bigger Example
Relational MongoDB
{ vers: 1,
customer_id : 1,
name : {
“f”:"Mark”,
“l”:"Smith” },
city : "San Francisco",
phones: [ {
number : “1-212-777-1212”,
dnc : true,
type : “home”
},
{
number : “1-212-777-1213”,
type : “cell”
}]
}
Customer
ID
First Name Last Name City
0 John Doe New York
1 Mark Smith San Francisco
2 Jay White Dallas
3 Meagan White London
4 Edward Daniels Boston
Phone Number Type DNC
Customer
ID
1-212-555-1212 home T 0
1-212-555-1213 home T 0
1-212-555-1214 cell F 0
1-212-777-1212 home T 1
1-212-777-1213 cell (null) 1
1-212-888-1212 home F 2](https://image.slidesharecdn.com/learnmdbmug20160107-160108020149/85/Introduction-to-MongoDB-28-320.jpg)
![29
MongoDB Queries Are Expressive
SQL select A.did, A.lname, A.hiredate, B.type,
B.number from contact A left outer join phones B
on (B.did = A.did) where b.type = ’home' or
A.hiredate > '2014-02-02'::date
MongoDB CLI db.contacts.find({"$or”: [
{"phones.type":”home”},
{"hiredate": {”$gt": new ISODate("2014-
02-02")}}
]});
Find all contacts with at least one home phone or
hired after 2014-02-02](https://image.slidesharecdn.com/learnmdbmug20160107-160108020149/85/Introduction-to-MongoDB-29-320.jpg)
![30
MongoDB Aggregation Is Powerful
Sum the different types of phones and create a list
of the owners if there is more than 1 of that type
> db.contacts.aggregate([
{$unwind: "$phones"}
,{$group: {"_id": "$phones.t", "count": {$sum:1},
"names": {$push: "$name"} }}
,{$match: {"count": {$gt: 1}}}
]);
{ "_id" : "home", "count" : 2, "names" : [
{ "f" : "John", "l" : "Doe" },
{ "f" : "Mark", "l" : "Smith" } ] }
{ "_id" : "cell", "count" : 4, "names" : [
{ "f" : "John", "l" : "Doe" },
{ "f" : "Meagan", "l" : "White" },
{ "f" : "Edward", "l" : "Daniels” }
{ "f" : "Mark", "l" : "Smith" } ] }](https://image.slidesharecdn.com/learnmdbmug20160107-160108020149/85/Introduction-to-MongoDB-30-320.jpg)
![31
$lookup: “Left Outer Join++”
> db.leases.aggregate([ ]);
{
"_id" : ObjectId("5642559e0d4f2076a43584fc"),
"leaseID" : "A5",
"sku" : "GD652",
"origDate" : ISODate("2010-01-01T00:00:00Z"),
"histDate" : ISODate("2010-10-28T00:00:00Z"),
"monthlyDue" : 10,
"vers" : 11,
"delinq" : { "d30" : 10, "d60" : 10, "d90" : 60
},
"credit" : 0
}
// 66 more ….
Step 1: Get a sense of the raw material](https://image.slidesharecdn.com/learnmdbmug20160107-160108020149/85/Introduction-to-MongoDB-31-320.jpg)
![32
$lookup: “Left Outer Join++”
Step 2: Group leases by SKU and capture count and max value of 90
day delinquency
> db.leases.aggregate([
{$group: { _id: "$sku", n:{$sum:1},
max90:{$max:"$delinq.d90"} }}
]);
{ "_id" : "AC775", "n" : 27, "max90" : 20 }
{ "_id" : "AB123", "n" : 26, "max90" : 5 }
{ "_id" : "GD652", "n" : 14, "max90" : 80 }](https://image.slidesharecdn.com/learnmdbmug20160107-160108020149/85/Introduction-to-MongoDB-32-320.jpg)
![33
$lookup: “Left Outer Join++”
Step 3: Reverse sort and then limit to the top 2
> db.leases.aggregate([
{$group: { _id: "$sku", n:{$sum:1},
max90:{$max:"$delinq.d90"} }}
,{$sort: {max90:-1}}
,{$limit: 2}
]);
{ "_id" : "GD652", "n" : 14, "max90" : 80 }
{ "_id" : "AC775", "n" : 27, "max90" : 20 }](https://image.slidesharecdn.com/learnmdbmug20160107-160108020149/85/Introduction-to-MongoDB-33-320.jpg)
![34
$lookup: “Left Outer Join++”
Step 4: $lookup to product collection and assign to new field
> db.leases.aggregate([
{$group: { _id: "$sku", n:{$sum:1},
max90:{$max:"$delinq.d90"} }}
,{$sort: {max90:-1}}
,{$limit: 2}
,{$lookup: { from: "products", localField: "_id", foreignField:
"productSKU", as:"productData"}}
]);
{ "_id" : "GD652”, "n" : 14, "max90" : 80,
"productData" : [
{
"_id" : ObjectId("5642559e0d4f2076a43584b5"),
"productType" : "rigidDumptruck",
"productSKU" : "GD652",
"properties" : {
"model" : "TR45",
"payload" : {
"std" : 45,
"unit" : "UStons"
},](https://image.slidesharecdn.com/learnmdbmug20160107-160108020149/85/Introduction-to-MongoDB-34-320.jpg)
![35
$lookup: “Left Outer Join++”
Step 5: Trim excess data away, leaving just type
> db.leases.aggregate([
{$group: { _id: "$sku", n:{$sum:1},
max90:{$max:"$delinq.d90"} }}
,{$sort: {max90:-1}}
,{$limit: 2}
,{$lookup: { from: "products", localField: "_id",
foreignField: "productSKU", as:"productData"}}
,{$project: { _id:1, n:1, max90:1, type:
"$productData.productType"}}
]);
{"_id”:"GD652”,"n”:14,"max90”:80,"type”:[”dumptruck”]}
{"_id”:"AC775”,"n”:27,"max90”:20,"type”:["loader”]}](https://image.slidesharecdn.com/learnmdbmug20160107-160108020149/85/Introduction-to-MongoDB-35-320.jpg)
Uploaded byMongoDB
Introduction to MongoDB
The document presents an introduction to MongoDB by Buzz Moschetti, outlining its features as a leading NoSQL database, including high performance, scalability, and its document data model. It covers various use cases such as big data, mobile apps, and security, along with deployment instructions and examples in different programming languages. Additionally, it highlights MongoDB's advancements, such as enhanced document validation and the $lookup feature for database queries.
More Related Content
Similar to Introduction to MongoDB
![MongoDB .local San Francisco 2020: Powering the new age data demands [Infosys]](https://cdn.slidesharecdn.com/ss_thumbnails/315pminfosysfinalsfoversionvocalpart1-200120221508-thumbnail.jpg?width=640&height=640&fit=bounds)
Introduction to MongoDB
- 1. Intro To MongoDB BuzzMoschetti Enterprise Architect, MongoDB buzz.moschetti@mongodb.com @buzzmoschetti
- 2. Who is TalkingTo You? • Yes, I use “Buzz” on my business cards • Former Investment Bank Chief Architect at JPMorganChase and Bear Stearns • Over 30 years of designing and building systems • Big and small • Super-specialized to broadly useful in any vertical • “Traditional” to completely disruptive • Advocate of language leverage and strong factoring • Inventor of perl DBI/DBD • Not an award winner for PowerPoint • Still programming – using emacs, of course
- 3. Agenda • What isMongoDB? • What are some good use cases? • How do I use it? • How do I deploy it?
- 4. MongoDB: The LeadingNoSQL Database Document Data Model Open- Source Fully Featured High Performance Scalable { name: “John Smith”, pfxs: [“Dr.”,”Mr.”], address: “10 3rd St.”, phones: [ { number: “555-1212”, type: “land” }, { number: “444-1212”, type: “mobile” } ] }
- 5. 5 The best wayto run MongoDB Automated. Supported. Secured. Features beyond those in the community edition: Enterprise-Grade Support Commercial License Ops Manager or Cloud Manager Premium Encrypted & In-Memory Storage Engines MongoDB Compass BI Connector (SQL Bridge) Advanced Security Platform Certification On-Demand Training MongoDB Enterprise Edition
- 6. Company Vital Stats 500+employees 2000+ customers Over $311 million in funding Offices in NY & Palo Alto and across EMEA, and APAC
- 7.
- 8. RDBMS MongoDB Database Database TableCollection Index Index Row Document Column Field Join Embedding & Linking & $lookup Terminology
- 9. { _id: “123”, title: "MongoDB:The Definitive Guide", authors: [ { _id: "kchodorow", name: "Kristina Chodorow“ }, { _id: "mdirold", name: “Mike Dirolf“ } ], published_date: ISODate(”2010-09-24”), pages: 216, language: "English", thumbnail: BinData(0,"AREhMQ=="), publisher: { name: "O’Reilly Media", founded: 1980, locations: ["CA”, ”NY” ] } } The Data Is The Schema
- 10. > db.authors.find() { _id: ”X12", name:{ first: "Kristina”, last: “Chodorow” }, personalData: { favoritePets: [ “bird”, “dog” ], awards: [ {name: “Hugo”, when: 1983}, {name: “SSFX”, when: 1992} ] } } { _id: ”Y45", name: { first: ”Mike”, last: “Dirolf” } , personalData: { dob: ISODate(“1970-04-05”) } } Treat Your Data More Like Objects
- 11. // Java: maps DBObjectquery = new BasicDBObject(”publisher.founded”, 1980)); Map m = collection.findOne(query); Date pubDate = (Date)m.get(”published_date”); // java.util.Date List locs = (List)m.get(”locations”); // Javascript: objects m = collection.findOne({”publisher.founded” : 1980}); pubDate = m.published_date; // ISODate year = pubDate.getUTCFullYear(); # Python: dictionaries m = coll.find_one({”publisher.founded” : 1980 }); pubDate = m[”pubDate”].year # datetime.datetime Documents Natively Map to Language
- 12. 12 Traditional Data Design •Static, Uniform Scalar Data • Rectangles • Low-level, physical representation
- 13. 13 Document Data Design •Flexible, Rich Shapes • Objects • High-level, business representation
- 14. Agenda • What isMongoDB? • What are some good use cases? • How do I use it? • How do I deploy it?
- 15. 15 MongoDB 3.0 SetThe Stage… 7x-10x Performance, 50%-80% Less Storage How: WiredTiger Storage Engine • Same data model, query language, & ops • 100% backwards compatible API • Non-disruptive upgrade • Storage savings driven by native compression • Write performance gains driven by – Document-level concurrency control – More efficient use of HW threads • Much better ability to scale vertically MongoDB 3.0MongoDB 2.6 Performance
- 16. 16 MongoDB 3.2 : EfficientEnterprise MongoDB • Much better ability to scale vertically + • Document Validation Rules • Encryption at rest • BI Connector (SQL bridge) • MongoDB Compass • New Relic & AppDynamics integration • Backup snapshots on filesystem • Advanced Full-text languages • $lookup (“left outer JOIN”) More general-purpose solutions
- 17. 17 MongoDB Sweet SpotUse Cases Big Data Product & Asset Catalogs Security & Fraud Internet of Things Database-as- a- Service Mobile Apps Customer Data Management Single View Social & Collaboration Content Management Intelligence Agencies Top Investment and Retail Banks Top Global Shipping Company Top Industrial Equipment Manufacturer Top Media Company Top Investment and Retail Banks Complex Data Management Top Investment and Retail Banks Embedded / ISV Cushman & Wakefield
- 18. Agenda • What isMongoDB? • What are some good use cases? • How do I use it? • How do I deploy it?
- 19.
- 20. 20 Unpack and StartThe Server $ tar xf mongodb-osx-x86_64-enterprise-3.2.0.tgz $ mkdir -p ~/mydb/data $ mongodb-osx-x86_64-enterprise-3.2.0/bin/mongod > --dbpath ~/mydb/data > --logpath ~/mydb/mongod.log > --fork about to fork child process, waiting until server is ready for connections. forked process: 6517 child process started successfully, parent exiting
- 21. 21 Verify Operation $ mongodb-osx-x86_64-enterprise-3.2.0/bin/mongo MongoDBshell version: 3.2.0 connecting to: 127.0.0.1:27017/test Server has startup warnings: 2016-01-01T12:44:01.646-0500 I CONTROL [initandlisten] 2016-01-01T12:44:01.646-0500 I CONTROL [initandlisten] ** WARNING: soft rlimits too low. Number of files is 256, should be at least 1000 MongoDB Enterprise > use mug switched to db mug MongoDB Enterprise > db.foo.insert({name:”bob”,hd: new ISODate()}); MongoDB Enterprise > db.foo.insert({name:"buzz"}); MongoDB Enterprise > db.foo.insert({pets:["dog","cat"]}); MongoDB Enterprise > db.foo.find(); { "_id" : ObjectId("5686cef538ea4981e63111dd"), "name" : "bob", "hd" : ISODate("2016-01-01T19:09:41.442Z") } { "_id" : ObjectId("5686…79d5"), "name" : "buzz" } { "_id" : ObjectId("5686…79d6"), "pets" : [ "dog", "cat" ] }
- 22. 22 The Simple JavaApp import com.mongodb.client.*; import com.mongodb.*; import java.util.Map; public class mug1 { public static void main(String[] args) { try { MongoClient mongoClient = new MongoClient(); MongoDatabase db = mongoClient.getDatabase("mug”); MongoCollection coll = db.getCollection("foo"); MongoCursor c = coll.find().iterator(); while(c.hasNext()) { Map doc = (Map) c.next(); System.out.println(doc); } } catch(Exception e) { // ... } } }
- 23. 23 Compile and Run! $curl -o mongodb-driver-3.0.4.jar https://oss.sonatype.org/content/repositories/releases/org /mongodb/mongodb-driver/3.0.4/mongodb-driver-3.0.4.jar $ javac –cp mongo-java-driver-3.0.4.jar:. mug1.java $ java –cp mongo-java-driver-3.0.4.jar:. mug1 (logger output) Document{{_id=5686cef538ea4981e63111dd, name=bob, hd=Fri Jan 01 14:09:41 EST 2016}} Document{{_id=5686c71338ea4981e63111d6, name=buzz}} Document{{_id=5686c71938ea4981e63111d7, pets=[dog, cat]}}
- 24. 24 The Same Appin python from pymongo import MongoClient client = MongoClient() db = client.mug coll = db.foo for c in coll.find(): print c $ python mug1.py {u'_id': ObjectId('5686cef538ea4981e63111dd'), u'name': u'bob', u'hd': datetime.datetime(2016, 1, 1, 19, 9, 41, 442000)} {u'_id': ObjectId('5686f54b38ea4981e631124c'), u'name': u'buzz'} {u'_id': ObjectId('5686f55138ea4981e631124d'), u'pets': [u'dog', u'cat']}
- 25. 25 …and, as expectedin Perl… $ perl -MMongoDB -MData::Dumper –e 'my $c = MongoDB::MongoClient->new()->get_database("mug")- >get_collection("foo")->find(); while($c->has_next()) { print Dumper($c->next()); }’ $VAR1 = { '_id' => bless( {'value' => '5686cef538ea4981e63111dd’}, 'MongoDB::OID' ), 'hd' => bless( { 'local_rd_secs' => 68981, 'rd_nanosecs' => 442000000, // etc }, 'DateTime' ), 'name' => 'bob' }; $VAR1 = { '_id' => bless( {'value' => '5686c71338ea4981e63111d6’}, 'MongoDB::OID' ), 'name' => 'buzz' }; $VAR1 = { 'pets' => [ 'dog’,'cat’], '_id' => bless( {'value' => '5686c71938ea4981e63111d7’}, 'MongoDB::OID' ) };
- 26.
- 27. Document Validation: StrongerThan Schema…? > db.createCollection(”contacts", { "validator": { $or: [ { $and: [ { “vers": 1}, { ”customer_id": {$type: “string”} } ] }, { $and: [ { "vers": 2}, { ”customer_id": {$type: “string”} }, { $or: [ { ”name.f": {$type: “string”}, ”name.l": {$type: “string”}} , { ”ssn": {$type: “string”}} ] } ] }]});
- 28. A Slightly BiggerExample Relational MongoDB { vers: 1, customer_id : 1, name : { “f”:"Mark”, “l”:"Smith” }, city : "San Francisco", phones: [ { number : “1-212-777-1212”, dnc : true, type : “home” }, { number : “1-212-777-1213”, type : “cell” }] } Customer ID First Name Last Name City 0 John Doe New York 1 Mark Smith San Francisco 2 Jay White Dallas 3 Meagan White London 4 Edward Daniels Boston Phone Number Type DNC Customer ID 1-212-555-1212 home T 0 1-212-555-1213 home T 0 1-212-555-1214 cell F 0 1-212-777-1212 home T 1 1-212-777-1213 cell (null) 1 1-212-888-1212 home F 2
- 29. 29 MongoDB Queries AreExpressive SQL select A.did, A.lname, A.hiredate, B.type, B.number from contact A left outer join phones B on (B.did = A.did) where b.type = ’home' or A.hiredate > '2014-02-02'::date MongoDB CLI db.contacts.find({"$or”: [ {"phones.type":”home”}, {"hiredate": {”$gt": new ISODate("2014- 02-02")}} ]}); Find all contacts with at least one home phone or hired after 2014-02-02
- 30. 30 MongoDB Aggregation IsPowerful Sum the different types of phones and create a list of the owners if there is more than 1 of that type > db.contacts.aggregate([ {$unwind: "$phones"} ,{$group: {"_id": "$phones.t", "count": {$sum:1}, "names": {$push: "$name"} }} ,{$match: {"count": {$gt: 1}}} ]); { "_id" : "home", "count" : 2, "names" : [ { "f" : "John", "l" : "Doe" }, { "f" : "Mark", "l" : "Smith" } ] } { "_id" : "cell", "count" : 4, "names" : [ { "f" : "John", "l" : "Doe" }, { "f" : "Meagan", "l" : "White" }, { "f" : "Edward", "l" : "Daniels” } { "f" : "Mark", "l" : "Smith" } ] }
- 31. 31 $lookup: “Left OuterJoin++” > db.leases.aggregate([ ]); { "_id" : ObjectId("5642559e0d4f2076a43584fc"), "leaseID" : "A5", "sku" : "GD652", "origDate" : ISODate("2010-01-01T00:00:00Z"), "histDate" : ISODate("2010-10-28T00:00:00Z"), "monthlyDue" : 10, "vers" : 11, "delinq" : { "d30" : 10, "d60" : 10, "d90" : 60 }, "credit" : 0 } // 66 more …. Step 1: Get a sense of the raw material
- 32. 32 $lookup: “Left OuterJoin++” Step 2: Group leases by SKU and capture count and max value of 90 day delinquency > db.leases.aggregate([ {$group: { _id: "$sku", n:{$sum:1}, max90:{$max:"$delinq.d90"} }} ]); { "_id" : "AC775", "n" : 27, "max90" : 20 } { "_id" : "AB123", "n" : 26, "max90" : 5 } { "_id" : "GD652", "n" : 14, "max90" : 80 }
- 33. 33 $lookup: “Left OuterJoin++” Step 3: Reverse sort and then limit to the top 2 > db.leases.aggregate([ {$group: { _id: "$sku", n:{$sum:1}, max90:{$max:"$delinq.d90"} }} ,{$sort: {max90:-1}} ,{$limit: 2} ]); { "_id" : "GD652", "n" : 14, "max90" : 80 } { "_id" : "AC775", "n" : 27, "max90" : 20 }
- 34. 34 $lookup: “Left OuterJoin++” Step 4: $lookup to product collection and assign to new field > db.leases.aggregate([ {$group: { _id: "$sku", n:{$sum:1}, max90:{$max:"$delinq.d90"} }} ,{$sort: {max90:-1}} ,{$limit: 2} ,{$lookup: { from: "products", localField: "_id", foreignField: "productSKU", as:"productData"}} ]); { "_id" : "GD652”, "n" : 14, "max90" : 80, "productData" : [ { "_id" : ObjectId("5642559e0d4f2076a43584b5"), "productType" : "rigidDumptruck", "productSKU" : "GD652", "properties" : { "model" : "TR45", "payload" : { "std" : 45, "unit" : "UStons" },
- 35. 35 $lookup: “Left OuterJoin++” Step 5: Trim excess data away, leaving just type > db.leases.aggregate([ {$group: { _id: "$sku", n:{$sum:1}, max90:{$max:"$delinq.d90"} }} ,{$sort: {max90:-1}} ,{$limit: 2} ,{$lookup: { from: "products", localField: "_id", foreignField: "productSKU", as:"productData"}} ,{$project: { _id:1, n:1, max90:1, type: "$productData.productType"}} ]); {"_id”:"GD652”,"n”:14,"max90”:80,"type”:[”dumptruck”]} {"_id”:"AC775”,"n”:27,"max90”:20,"type”:["loader”]}
- 36. Agenda • What isMongoDB? • What are some good use cases? • How do I use it? • How do I deploy it?
- 37. 37 • Single-click provisioning •Scaling & upgrades • Admin tasks • Monitoring with charts • Dashboards and alerts on 100+ metrics • Backup and restore with point-in- time recovery • Support for sharded clusters MongoDB Ops/Cloud Manager
- 38.
- 39. 39 MongoDB High Availability PRIMARY Application DRIVER secondary secondary TheReplica Set • 1 Primary • 2 – 48 Secondaries • Greatest failure isolation: Locally attached storage (spinning or SSD) • Less failure isolation: SAN, FLASH
- 40.
- 41. 41 HA and DRAre Isomorphic PRIMARY Application DRIVER secondary secondary Dual Data Center HA/DR Replica Set secondary Arbiter (DC3 or cloud) Data Center 1 Data Center 2
- 42. 42 MongoDB Scalability PRIMARY Application DRIVER secondary secondary What If: 1.Workload bottlenecks network or disk? 2. Data footprint starts to get large (e.g. 5TB)? 3. Regulations demand physical domicile of data in-region? 4. Growth profile uncertain? 5. Budget prohibits buying capacity up-front?
- 43. 43 Horizontal Scalability ThroughSharding PRIMARY Application DRIVER secondary secondary PRIMARY secondary secondary PRIMARY secondary secondary mongos Three Sharding Models: 1. Range 2. Tag 3. Hash … Shard 1 Symbols A-D Shard 2 Symbols E-H Shard n Symbols ?-Z
- 44. 44 For More Information ResourceLocation Case Studies mongodb.com/customers Presentations mongodb.com/presentations Free Online Training education.mongodb.com Webinars and Events mongodb.com/events Documentation docs.mongodb.org MongoDB Downloads mongodb.com/download Additional Info info@mongodb.com
- 45.
- 46.
Editor's Notes
- #2 HELLO! This is Buzz Moschetti at MongoDB, and welcome to today’s webinar entitled “Thinking in Documents”, part of our Back To Basics series. If your travel plans today do not include exploring the document model in MongoDB then please exit the aircraft immediately and see an agent at the gate Otherwise – WELCOME ABOARD for about the next hour.
- #3 Let’s talk about some the terms. JOINS: RDBMS uses Join to stich together fundamentally simple things into larger, more complex data. MongoDB uses embedding of data within data and linking to produce the same result
- #4 There are three themes that are important to grasp when Thinking In Documents in MongoDB and these will be reinforced throughout the presentation. First, great schema design…. I’ll repeat it: great… This is not new or something revolutionary to MongoDB. It is something we have been doing all along in the construction of solutions. Sometimes well, sometimes not. It’s just that the data structures and APIs used by MongoDB make it much easier to satisfy the first two bullet points. Particularly for an up-stack software engineer kind of person like myself, the ease and power of well-harmonizing your persistence with your code – java, javascript, perl, python – is a vital part of ensuring your overall information architecture is robust. Part of the exercise also involves candidly addressing legacy RDBMS issues that we see over and over again after 40 years, like schema explosion and field overloading and flattening Boils down to success = “schema” + code
- #5 Let’s talk about some the terms. JOINS: RDBMS uses Join to stich together fundamentally simple things into larger, more complex data. MongoDB uses embedding of data within data and linking to produce the same result
- #6 Very briefly, a little bit about the person talking to you today over the net.
- #7 Yep!
- #8 Let’s talk about some the terms. JOINS: RDBMS uses Join to stich together fundamentally simple things into larger, more complex data. MongoDB uses embedding of data within data and linking to produce the same result
- #9 Let’s talk about some the terms. JOINS: RDBMS uses Join to stich together fundamentally simple things into larger, more complex data. MongoDB uses embedding of data within data and linking to produce the same result
- #10 A document is not a PDF or a MS word artifact. A document a term for a rich shape. Structures of structures of lists of structures that ultimately at the leaves have familiar scalars like int, double, datetimes, and string. In this example we see also that we’re carrying a thumbnail photo in a binary byte array type; that’s natively supported as well. This is different than the traditional row-column approach used in RDBMS. Another important difference is that In MongoDB, it is not required for every document in a collection to be the same shape; shapes can VARY With the upcoming release of 3.2, we will be supporting documentation validation so in those designs where certain fields and their types are absolutely mandatory, we’ll be able to enforce that at the DB engine level similar to – but not exactly like – traditional schemas. Truth is in most non-trivial systems, even with RDBMS and stored procs, etc. plenty of validation and logic is being handled outside the database.. Now here is something very important: For the purposes of the webinar, we will be seeing this “to-string” representation of a document as it is emitted from the MongoDB CLI. This is easy to read and gets the structural design points across nicely. But make no mistake: you want most of your actual software interaction with MongoDB (and frankly any DB) to be via high fidelity types, not a big string with whitespaces and CR and quotes and whatnot.
- #11 This is a very, very exciting part of MongoDB. No need to come up with userDefined column 1, column 2, etc. We see here that Kristina and Mike have very different substructures inside the personalData field. We call this polymorphism: the variation of shape from document-to-document within the same collection. The library application logic only is looking for a field called “personalData”; actions will be taken dynamically based on the shape and types in the substructure! For example, It is a very straightforward exercise to recursively “walk” the structure and construct a panel in a GUI – especially if you are using AngularJS and the MEAN stack (MongoDB / Express / Angular / Node.js ) No need to use XML or blobs or serialized objects. It’s all native MongoDB -- and documents are represented in the form most easily natively manipulated by the language Every field is queryable and if so desired, indexable! Documents that do not contain fields in a query predicate are simply treated as unset.
- #12 Drivers in each language represent documents in a language-native form most appropriate for that language. Java has maps, python has dictionaries. You deal with actual objects like Dates, not strings that must be constructed or parsed. Another important note: We’ll be using query functionality to kill 2 birds with one stone: To show the shape of the document To show just a bit of the MongoDB query language itself including dotpath notation to “dig into” substructures Note also that in MongoDB, documents go into collections in the same shape they come out so we won’t focus on insert. This is a very different design paradigm from RDBMS, where, for example, the read-side of an operation implemented as an 8 way join is very different than the set of insert statements (some of them in a loop) required for the write side.
- #13 Let’s get back to data design. … Traditional data design is characterized by some of the points above, and this is largely because the design goals and constraints of legacy RDBMS engines heavily influence the data being put into them. These platforms were designed when CPUs were slow and memory was VERY expensive. Perhaps more interesting is that the languages of the time – COBOL, FORTRAN, APL, PASCAL, C – were very compile time oriented and very rectangular in their expression of data structures. One could say rigid schema combined with these languages was in fact well-harmonized. Overall, the platform is VERY focused on the physical representation of data. For example, although most have been conflated, the legacy types of char, varchar, text, CLOB etc. to represent a string suggest a strong coupling to byte-wise storage concerns.
- #14 Documents, on the other hand, are more like business entities. You’ll want to think of your data moving in and out as objects. And the types and features of Document APIs are designed to be well-harmonized with today’s programming languages – Java, C#, python, node.js, Scala , C++ -- languages that are not nearly as compile-time oriented and offer great capabilities to dynamically manipulate data and perform reflection/introspection upon it.
- #15 There are three themes that are important to grasp when Thinking In Documents in MongoDB and these will be reinforced throughout the presentation. First, great schema design…. I’ll repeat it: great… This is not new or something revolutionary to MongoDB. It is something we have been doing all along in the construction of solutions. Sometimes well, sometimes not. It’s just that the data structures and APIs used by MongoDB make it much easier to satisfy the first two bullet points. Particularly for an up-stack software engineer kind of person like myself, the ease and power of well-harmonizing your persistence with your code – java, javascript, perl, python – is a vital part of ensuring your overall information architecture is robust. Part of the exercise also involves candidly addressing legacy RDBMS issues that we see over and over again after 40 years, like schema explosion and field overloading and flattening Boils down to success = “schema” + code
- #16 Some quick logistics. In the last 5 to 10 mins today, we will answer the most common questions that have appeared in the webinar.
- #17 Some quick logistics. In the last 5 to 10 mins today, we will answer the most common questions that have appeared in the webinar.
- #18 Customer Data Management (e.g., Customer Relationship Management, Biometrics, User Profile Management) Product and Asset Catalogs (e.g., eCommerce, Inventory Management) Social and Collaboration Apps: (e.g., Social Networks and Feeds, Document and Project Collaboration Tools) Mobile Apps (e.g., for Smartphones and Tablets) Content Management (e.g, Web CMS, Document Management, Digital Asset and Metadata Management) Internet of Things / Machine to Machine (e.g., mHealth, Connected Home, Smart Meters) Security and Fraud Apps (e.g., Fraud Detection, Cyberthreat Analysis) DbaaS (Cloud Database-as-a-Service) Data Hub (Aggregating Data from Multiple Sources for Operational or Analytical Purposes) Big Data (e.g., Genomics, Clickstream Analysis, Customer Sentiment Analysis)
- #19 There are three themes that are important to grasp when Thinking In Documents in MongoDB and these will be reinforced throughout the presentation. First, great schema design…. I’ll repeat it: great… This is not new or something revolutionary to MongoDB. It is something we have been doing all along in the construction of solutions. Sometimes well, sometimes not. It’s just that the data structures and APIs used by MongoDB make it much easier to satisfy the first two bullet points. Particularly for an up-stack software engineer kind of person like myself, the ease and power of well-harmonizing your persistence with your code – java, javascript, perl, python – is a vital part of ensuring your overall information architecture is robust. Part of the exercise also involves candidly addressing legacy RDBMS issues that we see over and over again after 40 years, like schema explosion and field overloading and flattening Boils down to success = “schema” + code
- #20 Today we’ll explore data structures and schema for a library management application Good example because in general most of you have some familiarity with the entities involved and we can explore some 1:1, 1:n and other design elements
- #21 Today we’ll explore data structures and schema for a library management application Good example because in general most of you have some familiarity with the entities involved and we can explore some 1:1, 1:n and other design elements
- #22 Today we’ll explore data structures and schema for a library management application Good example because in general most of you have some familiarity with the entities involved and we can explore some 1:1, 1:n and other design elements
- #23 Today we’ll explore data structures and schema for a library management application Good example because in general most of you have some familiarity with the entities involved and we can explore some 1:1, 1:n and other design elements
- #24 Today we’ll explore data structures and schema for a library management application Good example because in general most of you have some familiarity with the entities involved and we can explore some 1:1, 1:n and other design elements
- #25 Today we’ll explore data structures and schema for a library management application Good example because in general most of you have some familiarity with the entities involved and we can explore some 1:1, 1:n and other design elements
- #26 Today we’ll explore data structures and schema for a library management application Good example because in general most of you have some familiarity with the entities involved and we can explore some 1:1, 1:n and other design elements
- #27 Today we’ll explore data structures and schema for a library management application Good example because in general most of you have some familiarity with the entities involved and we can explore some 1:1, 1:n and other design elements
- #28 We’ll close with something really cool – document validation that adapts to change over time. Assuming you “soft version” your documents by including a logical version ID ( in this case, a simple integer in field v) , you can maintain multiple different shapes of documents in one collection, each of them validation enforced to the version rules appropriate at the time. And again, because it is at the DB engine level, enforcement is guaranteed through all drivers. SUPER POWERFUL!
- #30 Today we’ll explore data structures and schema for a library management application Good example because in general most of you have some familiarity with the entities involved and we can explore some 1:1, 1:n and other design elements
- #31 Today we’ll explore data structures and schema for a library management application Good example because in general most of you have some familiarity with the entities involved and we can explore some 1:1, 1:n and other design elements
- #32 Today we’ll explore data structures and schema for a library management application Good example because in general most of you have some familiarity with the entities involved and we can explore some 1:1, 1:n and other design elements
- #33 Today we’ll explore data structures and schema for a library management application Good example because in general most of you have some familiarity with the entities involved and we can explore some 1:1, 1:n and other design elements
- #34 Today we’ll explore data structures and schema for a library management application Good example because in general most of you have some familiarity with the entities involved and we can explore some 1:1, 1:n and other design elements
- #35 Today we’ll explore data structures and schema for a library management application Good example because in general most of you have some familiarity with the entities involved and we can explore some 1:1, 1:n and other design elements
- #36 Today we’ll explore data structures and schema for a library management application Good example because in general most of you have some familiarity with the entities involved and we can explore some 1:1, 1:n and other design elements
- #37 There are three themes that are important to grasp when Thinking In Documents in MongoDB and these will be reinforced throughout the presentation. First, great schema design…. I’ll repeat it: great… This is not new or something revolutionary to MongoDB. It is something we have been doing all along in the construction of solutions. Sometimes well, sometimes not. It’s just that the data structures and APIs used by MongoDB make it much easier to satisfy the first two bullet points. Particularly for an up-stack software engineer kind of person like myself, the ease and power of well-harmonizing your persistence with your code – java, javascript, perl, python – is a vital part of ensuring your overall information architecture is robust. Part of the exercise also involves candidly addressing legacy RDBMS issues that we see over and over again after 40 years, like schema explosion and field overloading and flattening Boils down to success = “schema” + code
- #47 On behalf of all of us at MongoDB , thank you for attending this webinar! I hope what you saw and heard today gave you some insight and clues into what you might face in your own data design efforts. Remember you can always reach out to us at MongoDB for guidance. With that, code well and be well.