2. Agenda
• Designing your schema in MongoDB
• How to be MEAN
• Visualizing your MongoDB data in a MEANingful
way!
• Scalability &Availability
• DeploymentArchitectures & Operations
8. 8
Documents are Rich Data Structures
{
first_name: „Paul‟,
surname: „Miller‟,
cell: „+447557505611‟
city: „London‟,
location: [45.123,47.232],
Profession: [banking, finance, trader],
cars: [
{ model: „Bentley‟,
year: 1973,
value: 100000, … },
{ model: „Rolls Royce‟,
year: 1965,
value: 330000, … }
}
}
Fields can contain an array of
sub-documents
Fields
Typed field values
Fields can
contain arrays
9. 9
Document Model Benefits
• Agility and flexibility
– Data model supports business change
– Rapidly iterate to meet new requirements
• Intuitive, natural data representation
– Eliminates ORM layer
– Developers are more productive
• Reduces the need for joins, disk seeks
– Programming is more simple
– Performance delivered at scale
13. 14
Do More With Your Data
MongoDB
Rich Queries
• Find Paul’s cars
• Find everybody in London with a car
built between 1970 and 1980
Geospatial
• Find all of the car owners within 5km of
Trafalgar Sq.
Text Search
• Find all the cars described as having
leather seats
Aggregation
• Calculate the average value of Paul’s
car collection
Map Reduce
• What is the ownership pattern of colors
by geography over time? (is purple
trending up in China?)
{
first_name: „Paul‟,
surname: „Miller‟,
city: „London‟,
location: [45.123,47.232],
cars: [
{ model: „Bentley‟,
year: 1973,
value: 100000, … },
{ model: „Rolls Royce‟,
year: 1965,
value: 330000, … }
}
}
25. Mongoose
• Provides “elegant MongoDB object modeling for Node.js”
using Schemas and Models
• Each schema maps to a MongoDB collection
• Models can be instantiated based on a schema
• Instances of models represent documents in MongoDB
• Support for CRUD, aggregation, validation, pseudo-joins, rich
query builder + lots more!
• Install using npm
26. Mongoose (getting started)
• Require Node module
• Connect to MongoDB
• Define your schema in JSON
• Create the model object
28. Visualizing data
• D3.js – JavaScript library for manipulating
documents based on data – bring your data to life
• NVD3.js – reusable charts for d3.js
• Angularjs-nvd3-directives – Angular‟s way of
extending HTML to create new elements and
functionality
30. Real-time streaming charts
• Socket.IO (Node.js module)
– “aims to make realtime apps possible in every browser and mobile device”
• MongoDB Tailable Cursors
– requires a capped collection
• NVD3.js Event Listeners
– charts can be refreshed continuouslyas data is inserted/update in
MongoDB collection
32. City of Toronto – Open Data
• Data source: REST ServiceAPI
– To retrieve a list of service requestbetween Feb 1, 2012 to Feb 7, 2012
https://secure.toronto.ca/webwizard/ws/requests.json?start_date=2012-02-
01T00:00:00Z&end_date=2012-02-07T00:00:00Z&jurisdiction_id=toronto.ca
• Output format: JSON
• Refresh rate: continuously - real time refresh
33. Getting started with MEAN
• MEAN.io – ready to use MEAN stack boilerplate
• Yeoman – scaffolding tool for building modern web apps
– CommunityMEAN stack generators:
• https://github.com/wlepinski/generator-meanstack
• https://github.com/jrcryer/generator-mean
• https://github.com/chrisenytc/generator-meanis
36. 37
High Availability
• Automated replication and failover
• Multi-data center support
• Improved operational simplicity (e.g., HW swaps)
• Data durability and consistency
39. 40
Single Data Center
• Automated failover
• Tolerates server failures
• Tolerates rack failures
• Number of replicas
defines failure tolerance
Primary – A Primary – B Primary – C
Secondary – A Secondary – ASecondary – B
Secondary – BSecondary – CSecondary – C
40. 41
Active/Active Data Center
• Tolerates server, rack, data center failures, network
partitions
Data Center - West
Primary – A Primary – B Primary – C
Secondary – A Secondary – BSecondary – C
Data Center - East
Secondary – A Secondary – B Secondary – C
Secondary – B Secondary – C Secondary – A
Data Center - Central
Arbiter – A Arbiter – B Arbiter – C
45. For More Information
Resource Location
MongoDB Downloads mongodb.org/downloads
Free Online Training education.mongodb.com
Webinars and Events mongodb.com/events
White Papers mongodb.com/white-papers
Case Studies mongodb.com/customers
Presentations mongodb.com/presentations
Documentation docs.mongodb.org
Additional Info info@mongodb.com
Resource Location
Here we have greatly reduced the relational data model for this application to two tables. In reality no database has two tables. It is much more common to have hundreds or thousands of tables. And as a developer where do you begin when you have a complex data model?? If you’re building an app you’re really thinking about just a hand full of common things, like products, and these can be represented in a document much more easily that a complex relational model where the data is broken up in a way that doesn’t really reflect the way you think about the data or write an application.
Rich queries, text search, geospatial, aggregation, mapreduce are types of things you can build based on the richness of the query model.
