Merck Moving Beyond Passwords: FIDO Paris Seminar.pptx
Practical Ruby Projects with MongoDB - Ruby Midwest
1. PRACTICAL
PROJECTS WITH
Saturday, July 17, 2010
2. WHO AM I?
Alex Sharp
Lead Developer at OptimisDev
@ajsharp (on the twitters)
alexjsharp.com (on the ‘tubes)
github.com/ajsharp (on the ‘hubs)
Saturday, July 17, 2010
3. MAJOR POINTS
• Brief intro to MongoDB
• Practical Projects
• Making the case for Mongo (time permitting)
Saturday, July 17, 2010
8. SCHEMA-LESS
• Great for rapid, iterative, agile development
Saturday, July 17, 2010
9. SCHEMA-LESS
• Great for rapid, iterative, agile development
• Makes things possible that in an rdbms are either
a. impossibly hard
b. virtually impossible
c. way harder than they should be
Saturday, July 17, 2010
11. DOCUMENT-ORIENTED
• Mongo stores documents, not rows
• documents are stored as binary json
Saturday, July 17, 2010
12. DOCUMENT-ORIENTED
• Mongo stores documents, not rows
• documents are stored as binary json
• Allows for a rich query syntax
Saturday, July 17, 2010
13. DOCUMENT-ORIENTED
• Mongo stores documents, not rows
• documents are stored as binary json
• Allows for a rich query syntax
• Embedded documents eliminate many modeling headaches
Saturday, July 17, 2010
15. BIG DATA
• Built to scale horizontally into the cloudz
Saturday, July 17, 2010
16. BIG DATA
• Built to scale horizontally into the cloudz
• Auto-sharding
• set a shard-key, a cluster of nodes, go
• still in alpha, but production-ready soon
Saturday, July 17, 2010
18. FAST WRITES
• Mongo writes are “fire-and-forget”
• you can get a response with getLastError()
Saturday, July 17, 2010
19. FAST WRITES
• Mongo writes are “fire-and-forget”
• you can get a response with getLastError()
• In-place updates
Saturday, July 17, 2010
20. FAST WRITES
• Mongo writes are “fire-and-forget”
• you can get a response with getLastError()
• In-place updates
• Lot’s of db commands for fast updates
Saturday, July 17, 2010
21. AGGREGATION
Map/reduce for aggregation
Saturday, July 17, 2010
22. READS FAST TOO
Optimize reads with indexes, just like an rdbms
Saturday, July 17, 2010
33. THE OBJECT MODEL
• Each ledger line item belongs to a ledger
Saturday, July 17, 2010
34. THE OBJECT MODEL
• Each ledger line item belongs to a ledger
• Each ledger line item has two ledger entries
• must have at least one credit and one debit
• credits and debits must balance
Saturday, July 17, 2010
35. THE OBJECT MODEL
• Each ledger line item belongs to a ledger
• Each ledger line item has two ledger entries
• must have at least one credit and one debit
• credits and debits must balance
• These objects must be transactional
Saturday, July 17, 2010
45. LESSONS
• Simplified, de-normalized data model
• Objects modeled differently in Mongo than SQL
Saturday, July 17, 2010
46. LESSONS
• Simplified, de-normalized data model
• Objects modeled differently in Mongo than SQL
• Simpler data model + no transactions = WIN
Saturday, July 17, 2010
47. LOGGING WITH
CAPPED
COLLECTIONS
Saturday, July 17, 2010
48. BASELESS STATISTIC
95% of the time logs are NEVER used.
Saturday, July 17, 2010
49. MOST LOGS ARE ONLY USED
WHEN SOMETHING GOES
WRONG
Saturday, July 17, 2010
50. CAPPED COLLECTIONS
• Fixed-sized, limitedoperation, auto age-out collections
(kinda like memcached, except persistent)
• Fixed insertion order
• Super fast (faster than normal writes)
• Ideal for logging and caching
Saturday, July 17, 2010
51. GREAT. WHAT’S THAT MEAN?
We can log additional pieces of arbitrary data
effortlessly due to Mongo’s schemaless nature.
Saturday, July 17, 2010
64. BLOGGING APPLICATION
A post has an author
A post has many tags
Saturday, July 17, 2010
65. BLOGGING APPLICATION
A post has an author
A post has many tags
A post has many comments
Saturday, July 17, 2010
66. BLOGGING APPLICATION
A post has an author
A post has many tags
A post has many comments
Instead of JOINing separate tables,
we can use embedded documents.
Saturday, July 17, 2010
68. MONGOMAPPER
•MongoDB “ORM” developed by John Nunemaker
Saturday, July 17, 2010
69. MONGOMAPPER
•MongoDB “ORM” developed by John Nunemaker
•Very similar syntax to DataMapper
Saturday, July 17, 2010
70. MONGOMAPPER
•MongoDB “ORM” developed by John Nunemaker
•Very similar syntax to DataMapper
•Declarative rather than inheritance-based
Saturday, July 17, 2010
71. MONGOMAPPER
•MongoDB “ORM” developed by John Nunemaker
•Very similar syntax to DataMapper
•Declarative rather than inheritance-based
•Very easy to drop into rails
Saturday, July 17, 2010
72. MONGOMAPPER
require 'mongo'
connection = Mongo::Connection.new.db("#{Rails.env}_app")
class Post
include MongoMapper::Document
belongs_to :author, :class_name => "User"
key :title, String, :reuqired => true
key :body, String, :required => true
key :author_id, Integer, :required => true
key :published_at, Time
key :published, Boolean, :default => false
key :tags, Array, :default => []
timestamps!
end
Saturday, July 17, 2010
75. REPORTING IS HARD
• Synchronization
• Data, application API, schema
• Schema synchronization is the hard one
Saturday, July 17, 2010
76. WHY MONGO?
• Aggregation support with Mongo’s map/reduce support
• Mongo is good (and getting better) at handling big data sets
• Schemaless is perfect for a flattened data set
Saturday, July 17, 2010
77. Amazon EC2 Rackspace
Transform
MongoDB Server
Reporting App
WAN Main App
MySQL
Saturday, July 17, 2010
78. CLIENT REQUESTS Amazon EC2
MongoDB Server
map/reduce
Reporting App
User requests
Client request GET /reports/some_report
Saturday, July 17, 2010
79. TRANFORMATION
Data needs to extracted from the the main app,
transormed (i.e. flattened) into some other form,
and loaded into the reporting app for
aggregation
Saturday, July 17, 2010
80. TRANSFORMATION
Rackspace Amazon EC2
1. GET /object_dependencies
Transform MongoDB Server
{ :visit => [ :insurances, :patients ] }
2. read from
active record
MySQL
2. write to mongo Reporting App
Main App
Saturday, July 17, 2010
83. A BRIEF HISTORY OF SQL
• Developed at IBM in early 1970’s.
• Designed to manipulate and retrieve data stored in relational
databases
Saturday, July 17, 2010
84. A BRIEF HISTORY OF SQL
• Developed at IBM in early 1970’s.
• Designed to manipulate and retrieve data stored in relational
databases
this is a problem
Saturday, July 17, 2010
111. But we can do much, much better.
Saturday, July 17, 2010
112. NEEDS FOR A PERSISTENCE
LAYER:
Saturday, July 17, 2010
113. NEEDS FOR A PERSISTENCE
LAYER:
1. To persist the native state of our objects
Saturday, July 17, 2010
114. NEEDS FOR A PERSISTENCE
LAYER:
1. To persist the native state of our objects
2. Should NOT interfere w/ application development
Saturday, July 17, 2010
115. NEEDS FOR A PERSISTENCE
LAYER:
1. To persist the native state of our objects
2. Should NOT interfere w/ application development
3. Provides features necessary to build modern web apps
Saturday, July 17, 2010
117. USING MONGO W/ RUBY
• Ruby mongo driver
• MongoMapper (github.com/jnunemaker/mongomapper)
• MongoID (github.com/durran/mongoid)
• Many other ORM/ODM’s
• mongo-sequel (github.com/jeremyevans/sequel-mongo)
• moneta (github.com/wycats/moneta)
Saturday, July 17, 2010
118. MONGOMAPPER
• DataMapper-like API
• good for moving from a sql schema to mongo
• easy to drop into rails
• works with rails 3
Saturday, July 17, 2010
119. MONGOID
• DataMapper-like API
• uses ActiveModel, so familiar validation syntax
• more opinionated embedded docs
• easy to drop into rails
• rails 2 - mongoid 1.x
• rails 3 - mongoid 2.x
Saturday, July 17, 2010