Great overview of the technology choices and how they interact. I really appreciate when important companies reveal some of the inner workings of their sites. It gives something for the rest of us to go on. It can help inform our judgement when we make similar choices. This happens all too rarely. Many thanks!
I'd love to see you go deeper into devops. How are changes pushed? How often do you push changes? How are changes tested? How do you performance test at scale? How do you recover if something goes wrong?
Some parts of it are a bit outdated --we don't use Selenium tests for pre-testing all commits-- but overall it should give some idea of how deployment works at Digg.
You think this diagram is complex? You should see the one that describes the full details. Things I missed out include the tiny Java bit. No Ruby though.
True, and it isn't the full story of system dependencies. Data dependencies aren't really shown here and they are also tricky, although Cassandra is the the primary ("source of truth") for most things. So for example, if a user does something on the site such as Digg a story, you mainly write Cassandra (several times) but in some cases have to write Redis, as well as flush some caches. Meanwhile async jobs can be writing to HDFS and ultimately MySQL.
Why are you using so much data stores? is it due to some legacy? I understand why you need MySQL (because some key algorithms are based on jointures), but why have at the same time Redis and Casandra? you also mention that you'll maybe replace MySQL by HBase? why?
You also mention that the MapReduce jobs inputs are some flat logs (i suppose that those logs are stored in HDBS) so are you using any API to write in HDBS from RabbitMQ?
Boy, a lot of questions. I already mentioned that the different stores have different features. I wouldn't see Redis or Cassandra replacing each other for anything. HBase is a potential replacement for bigger MySQL-like things such as big joins across all user data, actions. M-R inputs are logs in HDFS, copied from scribe. RabbitMQ isn't involved in logging those.
Thanks for the answers.
I know, a lot of questions: this is because we are architecturing our plateform and having a detailled help from a successful website is very helpfull.
22 comments
[ 3.1 ms ] story [ 64.6 ms ] threadhttp://about.digg.com/blog/continuous-deployment-code-review...
Some parts of it are a bit outdated --we don't use Selenium tests for pre-testing all commits-- but overall it should give some idea of how deployment works at Digg.
Looking forward to see the next article.
Thanks again.