Most of this is relatively straightforward and unsurprising. But the one part that grabbed me is about "jittering". They insert random delays into timed events (the example given is cache expiration) to prevent a thundering herd problem when all the parts of the distributed system see the event at the same time (and for popular content, presumably repopulate the cache from the backend simulteously). This is simple en…
7 Years Of YouTube Scalability Lessons In 30 Minutes
51–60 of 77 posts
Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes
#52"They wrote their own BSON implementation which is 10-15 times faster than the one you can download." Curious to hear more about that one. If true, I hope they open source it, because that could potentially make MongoDB a lot faster for everyone. EDIT: It's apparently in their vitess code. Relevant code: http://code.google.com/p/vitess/source/browse/#hg%2Fgo%2Fbso...
Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes
#53I love the part on faking data. I take the viewpoint that only software testers care that the comment count is exactly correct in the majority of system. Users don't care.
Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes
#54I fully agree with Youtube faking data. However, I reckon they are faking a bit too much. Many times I would see 2000 likes and the video having 1700 views (Viral videos that is). I knew the view counter wasn't propagated but the likes were and I was like: "Damn this is Youtube, kinda disappointing..." I guess if both were propagated at the same time I wouldn't mind.
I honestly don't understand why they simply don't use out of sync data. You could have nodes periodically send aggregates of likes & views, and then add those in to the total ever N heartbeats. Why bother fudging the in-between.
Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes
#55Most of this is relatively straightforward and unsurprising. But the one part that grabbed me is about "jittering". They insert random delays into timed events (the example given is cache expiration) to prevent a thundering herd problem when all the parts of the distributed system see the event at the same time (and for popular content, presumably repopulate the cache from the backend simulteously). This is simple en…
The Adblock Plus blog details the thundering herd problems they faced. Their ad blocking lists checked for updates every 5 days. Eventually, many users' update schedules would converge on Mondays because office computers did not run over the weekend. Updates that had been scheduled for Saturday or Sunday would spill over to Monday. https://adblockplus.org/blog/downloading-a-file-regularly-ho...
Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes
#56I love the part on faking data. I take the viewpoint that only software testers care that the comment count is exactly correct in the majority of system. Users don't care.
LOL users care and they notice a LOT..Probably something like 5% of videos have a comment about how the view count is inaccurate.
Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes
#57Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes
#58> The number of videos has gone up 9 orders of magnitude and the number of developers has only gone up two orders of magnitude.
2 orders of magnitude means at the very least, going from 9 to 100 developers, which is a huge increase, but it could mean way more. I wonder how big the team really is, and what the changing team dynamics are like on that scale at that pace.
Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes
#59I fully agree with Youtube faking data. However, I reckon they are faking a bit too much. Many times I would see 2000 likes and the video having 1700 views (Viral videos that is). I knew the view counter wasn't propagated but the likes were and I was like: "Damn this is Youtube, kinda disappointing..." I guess if both were propagated at the same time I wouldn't mind.
Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes
#60Most of this is relatively straightforward and unsurprising. But the one part that grabbed me is about "jittering". They insert random delays into timed events (the example given is cache expiration) to prevent a thundering herd problem when all the parts of the distributed system see the event at the same time (and for popular content, presumably repopulate the cache from the backend simulteously). This is simple en…
On this topic, an interesting paper from 1994 on adding randomization to network traffic sources: http://ee.lbl.gov/papers/sync_94.pdf