Live data from Hacker News

7 Years Of YouTube Scalability Lessons In 30 Minutes

highscalability.com

11–20 of 77 posts

Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes

#11
post #8
post #3

What's this? Python? Apache? MySQL? But I thought you had to be running beta-release key value stores, esoteric web servers, and experimental programming languages if you wanted to scale! /s

Got your experimental programming language: > Vitess - a new project released by YouTube, written in Go, it’s a frontend to MySQL. It does a lot of optimization on the fly, it rewrites queries and acts as a proxy. Currently it serves every YouTube database request. It’s RPC based.

Ah yes, but it's using a ~30 year old technology (RPC).

Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes

#12
post #5

I 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

#14
post #8

Earlier quoted context omitted.

Got your experimental programming language: > Vitess - a new project released by YouTube, written in Go, it’s a frontend to MySQL. It does a lot of optimization on the fly, it rewrites queries and acts as a proxy. Currently it serves every YouTube database request. It’s RPC based.

Ah yes, but it's using a ~30 year old technology (RPC).

Is RPC an actual technology? I thought it was more of a protocol design pattern.

Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes

#15

I 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.

I faked data for a client once. He had phpbb running and wanted a script that would slowly and randomly generate views on a specific topic.

Since this was just a field in a database, it involved some simple update code.

The results? More people are interested in anything that they think are popular (or they are curious as to why so many people viewed it).

My client got more actual hits overall on these topics.

Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes

#16
post #3

What's this? Python? Apache? MySQL? But I thought you had to be running beta-release key value stores, esoteric web servers, and experimental programming languages if you wanted to scale! /s

I know the rage is async & nonblocking, but putting Python behind Apache is a good way to get predictable performance without concerns for calls that block, since they're mitigated via threads.

Also, it helps to have money since this approach requires more boxes. But as I said, it's very reliable.

Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes

#17
post #9

Youtube started off as a dating website? This has to go down in history as one of the best pivot decisions ever made.

Originally ebay started out as "auction web" hosted on the same site that Pierre Omidyar used for hosting information about the ebola virus.

Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes

#19
post #14

Earlier quoted context omitted.

Ah yes, but it's using a ~30 year old technology (RPC).

Is RPC an actual technology? I thought it was more of a protocol design pattern.

Remote Procedure Call is a design paradigm for synchronous call-and-response network communication. The Sun RPC protocol is an actual technology defined in RFC1057: http://www.ietf.org/rfc/rfc1057.txt

It's not insane, though not terribly relevant in the modern world. The only common technology still using it is NFS.

Re: 7 Years Of YouTube Scalability Lessons In 30 Minutes

#20
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 enough when described, but is not a technique I've seen applied much in practice or discussed in the community. I'm wondering if it's something that gets reinvented for all the projects that need it or if it's secret sauce known only in youtube. Regardless, I thought it was pretty insightful.

Post reply on HN