Remember how useful it was to see how MapReduce translates to SQL? In a similar vein, Andrés Taylor dives into Cypher, the Neo4j querying language introduced in Neo4j 1.4, explaining it from the perspective of an SQL person:

Unlike SQL which operates on sets, Cypher predominantly works on subgraphs. The relational equivalent is the current set of tuples being evaluated during a SELECT query.

Original title and link: Neo4j Querying for SQL People (NoSQL database©myNoSQL)

via: http://systay.github.com/blog/2011/11/06/cypher---a-view-from-a-recovering-sql-dba/

Stephen O’Grady:

It is too early to handicap the probable outcomes for these various query language projects. Nor is it certain that NoSQL will achieve the same consolidation the relational market did around a single approach; the differing approaches of the various NoSQL projects argue against this, in fact.

If by consolidation we mean having a query language that pseudo-works (by imposing tons of limitations, like GQL), I think we’ll be better of with custom query languages that take full advantage of their underlying NoSQL database engine.

Programming languages are not unified. Nor are file systems. And we are still using them to take full advantage of their unique features.

Original title and link: NoSQL: It’s Beginning to Look a Lot Like SQL (NoSQL database©myNoSQL)

via: http://redmonk.com/sogrady/2011/08/05/nosql-to-sql/

The most common complaint against NoSQL is that if you know how to write good SQL queries then SQL works fine. If SQL is slow you can always tune it and make it faster.

Let’s keep in mind two things:

1. performance is not equivalent to scalability
2. most NoSQL databases have been created to deal with scalability issues. And they offer a different, non-relational, data model.

A NoSQLite might counter that this is what key-value database is for. All that data could have been retrieved in one get, no tuning, problem solved. The counter is then you lose all the benefits of a relational database and it can be shown that the original was fast enough and could be made very fast through a simple turning process, so there is no reason to go NoSQL.

There’s the third thing too: you shouldn’t always obey the Law of the instrument. Polyglot persistence is a viable option.

Original title and link: Tunning SQL, No Need for NoSQL (NoSQL databases © myNoSQL)

via: http://highscalability.com/blog/2011/5/2/stack-overflow-makes-slow-pages-100x-faster-by-simple-sql-tu.html

We had a SQL to MapReduce translation table, now we have a basic SQL to Pig Latin:

Original title and link: Translating SQL to Pig Latin (NoSQL databases © myNoSQL)

via: http://www.riccomini.name/Topics/DistributedComputing/Hadoop/HadoopPigDocumentation/

As the title says, this is yet-another-tutorial on Map Reduce using MongoDB. But two things that are different here:

1. A problem solving approach is used, so we’ll take a problem, solve it in SQL first and then discuss Map Reduce.
2. Lots of diagrams, so you’ll hopefully better understand how Map Reduce works.

If MapReduce still didn’t click, you could try this SQL to MongoDB MapReduce guide.

Original title and link: MongoDB Map Reduce: Yet another tutorial (NoSQL databases © myNoSQL)

via: http://blog.mongovue.com/2010/11/03/yet-another-mongodb-map-reduce-tutorial/

Basic, but clear example with everything you need to get this working:

RavenDB is a document database, and unlike a relational database (like say Microsoft SQL Server) – you can’t do your usual group-by type queries quite as simply. […] For RavenDB instead I need to use a Map-Reduce query. The basics of this are that the first part (the Map) runs over the documents, and finds the matches. The reduce then takes the found matches, and summarises (reduces) the result set.

Original title and link: RavenDB: Emulating Group By Using MapReduce (NoSQL databases © myNoSQL)

via: http://will.hughesfamily.net.au/20101212/ravendb-map-reduce-indexes-and-how-to-install-them/

Cannot wonder what happened to Benjamin Black since it’s only a couple of weeks since “yelling”: “NoSQL took away the relational model and gave nothing back”. But it looks like he came up with the answer:

This is SQL at scale: radically simple schema, extremely narrow interface, asynchronous writes, and application-layer management of data distribution and query aggregation. These are also the properties of many non-relational databases. At this scale, most of the advantages of a relational database — ACID semantics and complex, ad-hoc queries — are traded for other advantages: operational simplicity, linear performance scaling, geographic distribution, and extreme fault tolerance.

And I’d say this is only from the perspective of scale. Others to consider: data (as in format, importance, etc.), operational costs.

Original title and link: NoSQL Is … SQL at Scale (NoSQL databases © myNoSQL)

via: http://gigaom.com/cloud/nosql-is-for-the-birds/