34. Challenges
• user data in Postgres
• legacy Rails app expects to find user data in
Postgres
• we want Gilt’s customer facing application code
to retrieve user data from MongoDB
35. Solution
• keep user data in both MongoDB and
Postgres
• replicate table changes from Postgres to
MongoDB
37. Use case #2:
feature configuration
Goal
manage the release of new features on gilt.com
How
feature configuration persisted in MongoDB
38. Rolling out a new feature
1. deploy new application code to production
2. enable feature for Gilt Tech employees
3. ... then enable for all Gilt employees
4. ... then enable for a subset of users
5. gradually ramp up to 100% of users
59. Best practices
Use caution when creating new indexes
“creating a new index on a production mongo server can
basically cause it to stop working while it builds the index”
(source: Gilt production incident report)
60. Minimizing impact of
building a new index
• remove one secondary from replica set
• create/rebuild index on this instance
• rejoin replica set
• repeat on all remaining secondaries
• run rs.stepDown() on primary member
http://docs.mongodb.org/manual/administration/indexes/#index-building-replica-sets
61. Best practices
use short names for fields to avoid wasted space
{ {
city: “Portland”, ci: “Portland”,
state: “Oregon”, vs st: “Oregon”,
country: “US” co: “US”
} }
http://christophermaier.name/blog/2011/05/22/MongoDB-key-names
63. Best practices
use caution when choosing a shard key
“It is generally not a good idea to use the default
ObjectId as the shard key”
source: http://stackoverflow.com/questions/9164356/sharding-by-objectid-is-it-the-right-way
70. Gilt tech talks
• Apache Camel and MongoDB @ Gilt
http://bit.ly/OYO37K
• Deploying new features @ Gilt
http://slidesha.re/OoCYfd
• Voldemort @ Gilt
http://bit.ly/b9Qhib
