Académique Documents
Professionnel Documents
Culture Documents
Before After
November
Before and After Architecture (2/4)
December
Before and After Architecture (3/4)
February
Before and After Architecture (4/4)
May
Advanced planning vs. fast response
“Rocket ship” “Driving”
• Are you sure you know • How do you know you will
what is going to happen? be able to fix the problem
in time?
• Are you sure you can
execute? • How can you be sure you
won't cause collateral
• Can you afford it? damage?
• Do you need feedback? • How can you be sure you
won't code yourself into a
corner?
Continuous Ship
• Deploy new software quickly
• At IMVU time from check-in to production = 20 minutes
• Don't have the same problem twice – fix the root cause of each
class of problems
• Incremental deploy
o Monitor cluster and business metrics in real-time
o Reject changes that move metrics out-of-bounds
Solution:
•Intercept and redirect queries based on SQL comments
• Move one table or sub-system at a time
• Our experience was one engineer horizontally partitions one table or
small sub-system in one week
db_query("/*shard customer://$customer_id */
INSERT INTO inventory (customers_id, products_id)
VALUES ($customer_id, $product_id)");
Solution:
•Intercept and cache queries based on SQL comments
db_query_cache(BUDDY_CACHE_TIME,
"/*shard customer://$customer_id */
/*cache-class customer://$customer_id/buddies */
SELECT friend_id, buddy_order FROM customers_friends
WHERE customers_id=$customer_id");
-----------------
db_query(“/*shard customer://$customer_id */
DELETE FROM customers_friends
WHERE customers_id = $customer_id
AND friend_id = $friend_id”);
db_flush_cacheclass("customer://$customer_id/buddies”);
Solution:
•Measure to find the real problems (harder than it sounds)
•Migrate to new design that takes advantage of sharding and/or
caching
Case Study: Steering Data Design
Case Study: Steering Data Design
Case Study: Steering Data Design
Problem: You can’t bulk move large frequently accessed data
Solution:
•Copy on read
–Use when you are read bound
–Reads check cache, new location, and copy to new location if missing
–Writes go to new location if data has been migrated, otherwise old
•Copy on write
–Use when you are write bound
–Reads check cache, new location, then old location
–Writes go to new location, copying to new location if missing
•Copy all
–Use when file system fills up
–Reads & writes go to new location, falling back to old location if missing
–Cron copies data a few records at a time
“Thank You for Listening!”