chad_walters

MySQL may work well for this small data set (200GB). Start working with 10s of TBs of data and you will start to understand why NoSQL stores were built.

Likewise when they start heading to Silicon Valley in droves... Last time around was 2000 -- 'nuff said.

Please point out where in the article a solution is discussed at all.

This article is terrible -- it sets up a false dichotomy. The article actually refutes it's own conclusion in the paragraphs about what people view as the ideal income distribution. We don't want total equality but we do want less inequality than is actually present today in every 1st world country. So we should care about the current (and growing!) levels of inequality -- even if we don't want a perfectly equal distribution, we want one that is more equal.

I previously worked on Thirft and have overseen the development of Bond with Adam as the lead developer.

Your characterization of Thrift is accurate and Bond actually has some of the same architectural roots as Thrift. Those features of Thrift were ones that I wanted to preserve in Bond. But we also wanted to expand that plugability to allow for even more flexibility than the core Thrift architecture would allow for -- for example, the ability to support Avro-like "untagged" protocols within the same framework. I believe that the core innovation is in how that gets implemented. Also, we believe that performance is a feature -- our testing has shown that Bond noticeably outperforms Thrift and Protocol Buffers in most cases.

There is no conspiracy or intent to "ignore languages" -- we will release additional languages as they are ready and as we can support them as first-class citizens. We also welcome community involvement.

"After extensive experience working with Bigtable and other eventually consistent systems..."

This is not accurate -- Bigtable is not eventually consistent. The scope of transactions supported by a system is a different set of considerations from the level of consistency it provides. Bigtable is consistent but only allows for transactionality at the row level.

Optimistic concurrency control is nothing new and Percolator layered transactions on top of Bigtable years back. Furthermore, TrueTime -- allowing for comparatively low-latency update across a globally distributed set of DCs -- is the real innovation in Spanner, not the use of optimistic concurrency control.

Honestly, I am not sure what this article is trying to claim, except perhaps that per-node performance has been improved. AFAICT, most of this is due to the fact that RAM is cheaper than it was, SSDs have reached commoditization, and networks in the DC are faster than they used to be.

Your post mentions "single root IO virtualization" as a factor in maximizing network performance. I am wondering what the impact of this was in your sorting. Do you have data for runs where you didn't enable this?

The title is not just misleading -- it is just plain wrong.

NUMA was 15% better for Gmail and 20% better for the Web search frontends, as indicated by the reductions (improvements) in CPI for these workloads.

There were some workloads where NUMA did degrade performance, such as BigTable accesses (12% regression).

The amazing thing is that the "big bulge" that Evans referred to in the original graph is clearly the bulge on the left (low-income) side of the graph, while McArdle incorrectly focuses on the artifact on the right (high-income) side -- and then none of the follow-on posts seem to point this mistake out.

Full disclosure: I did some work on Thrift in 2007-2008.

I read the blog post you linked and I don't see any real evidence that their choice of Thrift was "grudging". They did say that there are differing requirements that might lead to others to make a different choice -- but AFAICT there is no indication in the article that they regret their choice.

WRT IDLs: YMMV of course, but the post you linked provides the following reasons why an IDL might be a good idea: "A more formal IDL and native code generation may help provide better long-term client stability, so the initial Thrift overhead for developers might be justified for some services that are concerned about client stability and longevity."

From the OP: "Our primary aim with this 'foolishness' is to create a solution that allows us to continue open sourcing parts of our stack without resorting to reinventing some of our internal wheels."

And: "we think C++ developers might find parts of this library interesting in their own right."

I think the key thing is that these are some basic pieces that a lot of FB's internal C++ code depends on. These pieces are being made available as a stepping stone to open sourcing more significant work.

I recommend that anyone interested in this topic look closely at the raw data provided in the deck on slides 38-41.

What are the universally accepted style rules for C/C++? Every organization I have worked in has had to develop their own guidelines around style in C/C++.

What really surprises me is that such a large number of people are quick to attack someone for writing legal code simply because they disagree with the style used. It feels awfully close to attacking someone for using a different bracing style from your preferred bracing style.