In a recent blog post, I chided the NoSQL movement for naming itself after the absence of something. But not only is this naming approach for a broad market category rather silly, it?s also somewhat off-topic, since the story really isn?t simply about rejecting SQL. After all, the NoSQL movement essentially consists of a family of nonrelational database management systems. ?But I guess nonrelational just didn?t have the same buzziness as NoSQL.
Be that as it may, the NoSQL movement also eschews SQL itself?the venerable Structured Query Language, invented in the 1970s for relational databases and standardized in 1986. Yes, SQL is long in the tooth. It?s probably older than 90% of the people reading this post. And SQL is for relational databases. NoSQL databases are nonrelational, so we need to replace SQL. Fair enough. The question of the day, of course, is what to replace it with.
There is no shortage of contenders. Many of the NoSQL databases support their own query language, like CQL (Cassandra Query Language) for Cassandra, Pig for Hadoop, ECL (Enterprise Control Language) for HPCC, and GQL for the Google App Engine datastore. Graph databases also have their own query languages. Even though graph databases fall into the NoSQL bucket, they?re quite different from their document-centric brethren, and thus you would expect to query them differently. Graph-centric query languages include Neo4j Cypher.
But what everybody really wants is one query language to rule them all?or at least, one for the document-centric engines and one for the graph-centric alternatives. Filling this void are UnQL (pronounced uncle) and Gremlin, respectively. Couchbase, Microsoft, and SQLite are spearheading UnQL, while DEX, Infinigraph, and Neo4j are among the many names who support Gremlin. Left out in the cold as far as a standard query language, at least for now: name-value pair centric database engines like Cassandra, HBase, and Riak.
Clearly, the dust has yet to settle on the NoSQL query language marketplace. But the variety of contenders is only part of the problem. A larger issue, one the market has yet to tackle, is that most of these query language alternatives are intentionally similar to SQL. They all tend to have SELECT, INSERT, and UPDATE statements, for example, and some of them even have JOINs. The reasoning behind this approach is to support people who know SQL. Theoretically, a SQL expert would be able to transition to a NoSQL query language without much trouble.
I challenge that conclusion. Throwing out the gauntlet here?how about we create one or more NoSQL query languages that look nothing at all like SQL, but are rather designed from the ground up to support the architectural context for NoSQL databases? In other words, what should a Cloud-centric NoSQL query language look like? Perhaps we haven?t even begun to explore the true meaning of NoSQL.
?
