Translate MySQL to MongoDB MapReduce [pdf] | Hacker News Reader

Translate MySQL to MongoDB MapReduce [pdf]

rickosborne.org

26 pointsJim_Neath15 comments

The SQL looks way easier (and shorter). I hope somebody will take it upon themselves to write an sql-to-mongo-mapreduce compiler.

That's one of the reasons why the whole 'NoSQL' thing is silly. No SQL picks the wrong battle. SQL just fine as a compact language for expressing certain things.

I don't think it's silly at all. If you give something a name, people can start talking and reasoning about it. The same thing happened with AJAX - the name was dumb (it doesn't have to be Asynchronous, it doesn't have to use XML and it doesn't even need to use JavaScript) but the term kicked off something of a revolution in web development just by giving people the vocabulary to discuss it. It feels to me like the term NoSQL is having the same kind of effect - for the first time in years, developers are talking and thinking critically about their choice of data persistence layer.

Bingo. That was exactly what we were shooting for.

Sure, if the querying is your only concern.

The trade off you make to get the performance attributes, scalability, schemaless flexibility, etc from a NoSQL storage solution is that you end up in a different query situation. Things like joins aren't as easy - but at the same time the cost of doing what in RDBMS land you'd consider "Denormalizing" (potentially duplicating data as needed) is much, much lower.

As for translation, the Mongo guys have produced a JDBC driver (for those of you stuck in java land, but at the least it's a code model for "Howto"; disclaimer: I haven't had a chance to use it yet) that supports some automatic translation of SQL statements to Mongo queries - http://github.com/erh/mongo-jdbc

They did - that's actually what this PDF is showing, but the submission links directly to the PDF rather than the article. Here's the original post:

http://rickosborne.org/blog/index.php/2010/02/19/yes-virgini...

I've submitted it here:

http://news.ycombinator.com/item?id=1166876

My bad. The pdf was linked to from a different article. I've upvoted your post with the original article.

On further inspection I was wrong - the PDF is from an older article on that blog, before he got the automatic SQL conversion to work.

Did that chart just tell me to go fuck myself?

In fairness, this chart plays directly to SQL's strengths by simply implementing built-in functions of SQL like SUM using MongoDB MapReduce. Clearly the MongoDB version will be more verbose in this case.

Because MapReduce is much more general than these few built-in functions, one could probably pick a task that would make the SQL version look horrendous compared to the MongoDB approach.

Agreed. And it certainly doesn't address the other trade-offs that make the whole SQL/Not-only-SQL discussion fascinating. I just couldn't resist referencing this: http://browsertoolkit.com/fault-tolerance.png

LOL, hadn't seen that before. Very apropos.

The example given is in the lower level imperative javascript you'd use to speak directly to MongoDB.

Often you'd layer a more expressive declarative language on top of that, which is what drivers like MongoMapper or Mongoid provide.

Even within the JavaScript interpreter you can be writing declaratively, like this jLINQ example:

http://somewebguy.wordpress.com/2010/02/14/jlinq-in-mongodb-...

SQL is really nice for querying sets. There's no reason Mongo has to go without its query capabilities, really.

They're both nice. Because the data modelling paradigms are so different, I don't see much point in trying to shoehorn SQL into MongoDB.

Consider the case where you're modelling blog posts with zero or more tags. In a relational database you'd typically have a posts table, a tags table, and a posts_tags join table. In MongoDB you'd have a posts collection with an indexed array key for the tags.

Searching for all the posts with the tag foo is just: db.posts.find({tags: 'foo'}).

Looks pretty nice to me. Why would I want to use a relational query language for a document-oriented database?

Reply on news.ycombinator.com