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.
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 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.
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.
It's interesting because the 5.1 specification doesn't say it is an error correction mechanism, it states: "For convenience, however, such semicolons may be omitted from the source text in certain situations".
I have never written a line of JS in my life, which hopefully qualifies me as an unbiased outsider, but I don't agree that that Crockford's position here on JSMin is the right thing to do.
Here is what I see:
@fat is not inserting "!" needlessly as a statement separator. The "!" is there for its proper purpose, as a "unary not" operation, which will short circuit the second operand of the "&&" when isActive is false.
Given that, @fat has left out a semicolon in a way that is perfectly legitimate based on this language specification, at least as described in the 5.1 version linked from here: http://inimino.org/~inimino/blog/javascript_semicolons).
Could @fat have written the code differently so that he would have been required to include the ";"? Perhaps -- but I don't see why that counterfactual has any particular bearing here.
Crockford's own page on JSMin <http://www.crockford.com/javascript/jsmin.html>; claims: "JSMin is a filter that omits or modifies some characters. This does not change the behavior of the program that it is minifying."
The fact is that @fat's code is legal code and JSMin is breaking it.
IMHO, Crockford is ignoring the technical matters at hand. @fat cannot be faulted for writing code that complies with the specification and for having a reasonable expectation that code minimizers will preserve the semantics of his legal code. Crockford (and others) may wish that the language specification did not include automatic semicolon insertion because it does hamper making changes in the language without breaking existing code -- but that does not make this piece of code "insanely stupid".
Yes, forward progress on the language would be better served if automatic semicolon insertion rules weren't in the specification. However, calling one particular piece of code that leverages those rules "insanely stupid" and refusing to acknowledge that JSMin is in fact breaking the semantics of the code is not productive. Refusing to fix this in JSMin does not somehow make the problem with the specification to go away.
That all supports the marketing effort. Mongo is optimized for a good out-of-the-box experience for developers. It is basically the MySQL model -- hook developers first, fix the fundamentals later. Caveat emptor.