Stonebraker trapped in Stonebraker 'fate worse than death'
dom.as
dom.as
voltdb (Stonebraker's solution) is in-memory store, so are few other of all this new wave of solutions (e.g. you don't want active mongo dataset to fall out of memory, as well as hit any contention on r/w lock).
I didn't want to attack statistics or numbers in any way, as to have proper picture it is not enough to know number of servers or shards, one has to know also workload that has to happen there, as well as access distributions, etc.
I could point out that average write transaction at FB is at around 5ms timing, so argument about transactional cost is not that important, as RPC times add up to that quite a bit, and multi-cluster dbms wouldn't reduce the RPC costs.
Pretty much everything he wrote about state of FB environment is very uneducated narrative.
Oh well, I guess general audience prefers something that has no basis rather to insights that are based on working today in that industry.
I'd also add that it's bad form to ridicule the academics on whose shoulders your own career rests. Better to stick to the argument at hand rather than take things personally.
Every year or so Stonebreaker feels compelled to come down from his ivory tower to troll industry. Remember a few years ago when he co-authored the paper "MapReduce: A major step backwards" (http://databasecolumn.vertica.com/database-innovation/mapred...)? Nevermind that Google probably processes petabytes of data using MapReduce every day that ends up getting served on practically every Google property. How can he argue with results? Can't we just ignore him?
1) Stonebraker is an industry troll that likes to shamelessly advertise his current products while pointing 'problems' with the state of the art. And he usually emits clueless opinions about subjects he doesn't deal with.
2) In spite of Stonebraker, voltdb engineers are doing a serious job, and the product has its value;
3) It's virtually impossible (and high risky) to change the infrastructure of any company the size of Facebook/Google. As any software engineer research shows, it'll take years and lots of money to change a large code base and deploy other data management system. Of course, Facebook is using HBase now for new products, but the current MySQL based systems should account for millions of lines of code. It's worth to spend time developing new products or refactoring old code that is working?
4) Thousands of MySQL shards is a hell on earth, for sure. We should praise Facebook engineers for being able to manage it efficiently.