MoreSQL is a cheeky idea Alex Tatiyants invented in NoSQL No More: Let’s double down with MoreSQL advocating that the cure for NoSQL is not less SQL, but even more SQL. Use SQL everywhere, for everything. This is of course creates yet another NewSQL. Hopefully we've exhausted all tasteful variants of the SQL motif.

While the post is ironic (I think), Google may be into MoreSQL in a big way, as described in a well written and exceptionally detailed paper: Tenzing - A SQL Implementation On The MapReduce Framework. If you are looking for the secrets of how to get back to the good old days of joins and aggregate operators using a SQL syntax, while enjoying the scalability of NoSQL, this paper is a must read.

Abstract:

Tenzing is a query engine built on top of MapReduce for ad hoc analysis of Google data. Tenzing supports a mostly complete SQL implementation (with several extensions) combined with several key characteristics such as heterogeneity, high performance, scalability, reliability, metadata awareness, low latency, support for columnar storage and structured data, and easy extensibility. Tenzing is currently used internally at Google by 1000+ employees and serves 10000+ queries per day over 1.5 petabytes of compressed data. In this paper, we describe the architecture and implementation of Tenzing, and present benchmarks of typical analytical queries.

Reader Comments (3)

No, 10,000 large, analytic queries per day on petabyte sized data is not in any way a trivial task. OLTP data loads where a small number of rows are emitted is an entirely different beast than DW OLAP queries.

Seriously, the relational model itself, and with it the SQL language, is really more a way of looking at data in the abstract, than any particular kind of database implementation. The fairly standard implementation of SQL databases is just a performance optimization for the kinds of problems they have traditionally been tasked to solve and the hardware they have traditionally run on. The fact that Google's line of business apps differ sufficiently from this in both respects to call for a different optimization, in now way invalidates the relational model as a way to view the resulting data collected.

The biggest problem a SQL interface could face in this setting, is that it very neatly hides potential implementation specific performance gotchas from the end user; but a combination of a decent custom query optimizer, and a user base of presumably well informed internal users, may well be all the workaround needed for that. Anyway, hats off to the optimizer team for pulling their part of this off!