This is worse than the first article. They seem to be conflating the use of a high-level, SQL-like language with the architecture of the system. Of course you

This is worse than the first article. They seem to be conflating the use of a high-level, SQL-like language with the architecture of the system. Of course you could layer a SQL-like language on top of a MapReduce-based storage and processing array, and for some queries that would be very user-friendly. If that is their whole point it is true but trivial. I think BigTable does have a limited join capability now. The real difference between a MapReduce-oriented system and typical SQL storage options is something like this. MR gives you assured scalability at the cost of limiting what kinds of queries you can do, and as the authors correctly point out, some queries get more and more onerous to create. Usually, SQL storage engines place ease of querying above all else, but have to go through painful and expensive procedures to scale well.