NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



SQL: All content tagged as SQL in NoSQL databases and polyglot persistence

Aster Data SQL-MapReduce Technology Patent

From a Teradata PR announcement:

SQL-MapReduce® is a framework which enables fast, investigative analysis of complex information by data scientists and business analysts. It enables procedural expressions in software languages (such as Java, C#, Python, C++, and R) to be parallelized across a group of linked computers (compute cluster) and then activated for use (invoked) with standard SQL.  

The closest open source solution I can think of is Pig , created and open sourced by Yahoo! (PDF).

Original title and link: Aster Data SQL-MapReduce Technology Patent (NoSQL database©myNoSQL)

Tunning SQL, No Need for NoSQL

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)


Translating SQL to Pig Latin

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

SQL to Pig Latin

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


MongoDB Map Reduce: Yet another tutorial

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)


RavenDB: Emulating Group By Using MapReduce

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)


SQL vs NoSQL: Twinkle, Twinkle, NoSQL!

Story and script by Latha Annur Subramaniam:

In case you have a hard time reading it:

RDBMS (SQL) was worried when the news about a new technology called NoSQL

SQL: Oh, he is this new NoSQL guy. People say he is here to beat me out. Hmm. I just hate him!

NoSQL: Howdy, senior SQL. How are you?

SQL: um… uh… oh Hi young man. Looks like you are new to this place?

NoSQL: Oh yeah! Just out of the ‘Latest computing trends’ school.

SQL: He is just a fresher. But I am his great grand senior. He can never take me down.

SQL: Hey, your name NoSQL sounds strange. Sounds like you are an anti-SQL guy.

NoSQL: Hm… true. I fell so unfortunate of my name. But I am never al alternate to you. In short, I am a new solution for the fresh new problems of this computing era… the “WEBSCALE” era.

SQL: (Hey he sounds modest. Am kinda like this guy) Oh. Am hearing this term for the first time. What is this W-E-B SCALE thing all about?

NoSQL: Interestingly, these days humans lead a much active social life on the WEB only.

NoSQLL Just like in their real life, people always need more and more of everything. Tweet, Search, Maps, Blog… their needs never end ;-)

SQL: Hmmm. Now I get it. I’ve been the darling for the enterprises for their data storage needs. But maybe they will abandom me and choose you, when they need more scale?!?!

NoSQL: Partially true. I can help them in scaling massively. But you are still the best in a lot of things.

NoSQL: For example, you are the Superstar when it comes to ‘transaction based apps’. I can never beat you in your ACID qualities

NoSQL: Also, I am still not the best for ‘Reporting’ requirements. While my ‘schemaless’ quality helps dynamically add different types of data, it causes the drawback of not being helpful for reporting.

SQL: I fell you are the right fit for the modern social apps.

NoSQL: You are the right bet for the critical business apps… soon until I catch up with you


SQL: Yup. I wish you good luck, young man.

NoSQL: Thank you, senior. Btw, my name doesn’t mean a NO to SQL!!! It is only that I am NOT only SQL :-)

SQL: and so I dedicate this song to you buddy:

Twinkle, twinkle NoSQL
Was wondering who you are
Out into this computing world,
I wish you success all around!!!

Definitely not as good as MongoDB is web scale.

Original title and link: SQL vs NoSQL: Twinkle, Twinkle, NoSQL! (NoSQL databases © myNoSQL)

NoSQL Is ... SQL at Scale

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)


Redisql: Redis with Extensive SQL Flavor

So I wrote Redisql which is an extension of redis that also supports a large subset of SQL. […] Redisql supports all redis data types and functionality (as it’s an extension of redis) and it also supports SQL SELECT/INSERT/UPDATE/DELETE (including joins, range-queries, multiple indices, etc…) -> lots of SQL, short of stuff like nested joins and Datawarehousing functionality (e.g. FOREIGN KEY CONSTRAINTS). So using a Redisql library (in your environment’s native language), you can either call redis operations on redis data objects or SQL operations on relational tables, its all in one server accessed from one library.

This might actually be the beginning of the future polyglot persistence. Indeed future complete polyglot persistence systems will need to provide simple sets of knobs and engines for different data models.

Original title and link: Redisql: Redis with Extensive SQL Flavor (NoSQL databases © myNoSQL)