Over this week I’ve been working on a proof of concept to see if it’s possible to use Clojure as the map/reduce language for Riak, in the same way now we can use Javascript and Erlang for that purpose. To accomplish that I needed a way to call Clojure code from Erlang. So I set up a very simple server in Clojure that runs as an Erlang node using Closerl.

Theoretically nice… practically I’d say there is a fundamental problem with this idea (different than the ones listed in the article). Map and reduce functions are supposed to run on the nodes hosting the data^[1]. If you need to wire this data is like implementing mapreduce on your application so the data locality property is lost. Not to mention that adding another variable to the equation (the JVM) your distributed system will become more sensible to failures.

Original title and link for this post: Riak Map/Reduce Queries in Clojure (published on the NoSQL blog: myNoSQL)

From installation to using the Clojure library for Riak ☞ clj-riak including MapReduce with Riak:

This brief introduction leaves many aspects of Riak unaddressed. For example, we have not looked at throughput, scalability, fault tolerance, conflict resolution, or production operations – all critical to a complete understanding of the datastore.

Quick Guide for Riak with Clojure originally posted on the NoSQL blog: myNoSQL

My fascination for Clojure and a bit of NoSQL flavor made me mention this basic sample app:

We’ll create a small Compojure^[1] application that will serve as a backend for the Todos application. The application data will be stored in MongoDB.

Code also available on ☞ GitHub.

A short intro to NoSQL data modeling, an important topic for the NoSQL space, by ☞ Andrew Glover:

When developers talk about non-relational or NoSQL databases, the first thing often said is that they require a change in mindset. In my opinion, that actually depends upon your initial approach to data modeling. If you are accustomed to designing applications by modeling the database structure first (that is, you figure out tables and their associated relationships first), then data modeling with a schemaless datastore like Bigtable will require rethinking how you do things. If, however, you design your applications starting with the domain model, then Bigtable’s schemaless structure will feel more natural.

Somehow related you may also find interesting the Clojure DSL for Google App Engine by ☞ Stefan Richter:

Modeling your data structures for a distributed key-value store for large-scale internet applications differs in several key aspects from ER-modeling: Forget normalization, optimizing for read-access, etc. As a result, we believe that using object-oriented persistence mapping can cause a developer to incorrectly abstract object relationships: You should not have complex object relationships in your datastore. In addition, since Clojure is a functional programming language, it makes less sense to use a persistence mechanism rooted in object oriented practices. In Clojure you are using structs (maps) and not “objects” to hold your data, which means that you already have simple key-value structured data at hand. There’s no need to use object persistence mapping anyway. The most natural way is to use the low-level API to the datastore directly.

I’ve already made the point that storing the data is just the start of the “adventure” and sooner than later you’ll have to put your NoSQL stored data to work.

Cascalog, introduced in the linked article, is a query language for Hadoop featuring:

• Simple – Functions, filters, and aggregators all use the same syntax. Joins are implicit and natural.
• Expressive – Logical composition is very powerful, and you can run arbitrary Clojure code in your query with little effort.
• Interactive – Run queries from the Clojure REPL.
• Scalable – Cascalog queries run as a series of MapReduce jobs.
• Query anything – Query HDFS data, database data, and/or local data by making use of Cascading’s “Tap” abstraction
• Careful handling of null values – Null values can make life difficult. Cascalog has a feature called “non-nullable variables” that makes dealing with nulls painless.
• First class interoperability with Cascading – Operations defined for Cascalog can be used in a Cascading flow and vice-versa
• First class interoperability with Clojure - Can use regular Clojure functions as operations or filters, and since Cascalog is a Clojure DSL, you can use it in other Clojure code.

While I do really like Clojure^[1] and its conciseness, I kind of agree with the point Kevin Weil from Twitter made during the nosql:eu conference:

I need less Java in my life, not more

in the sense that higher level tools are more productive. And that’s the reason Twitter is using PIG (nb: I’d strongly recommend checking Kevin Weil’s slides) and Cloudera Hadoop distribution will include PIG and Hive.

Q: Can you explain why is MongoDB a good choice for incanter (as opposed to Clojure more generally?) Everything that I work with (in R) that is not rectangular, is indexed …

A: Do you mean as opposed to SQL databases, or other schema-less databases?

MongoDB can easily persist arbitrarily deeply nested Clojure data structures, which makes it a convenient choice, but that’s not to say there are not many other options, all equally useful.

I’d speculate that for larger data sets, having Incanter to work with HBase or Hadoop (if it doesn’t already) would take it to the next level.

@liebke

What you get when you put together Clojure with Compojure and MongoDB with CongoMongo