Brian O’Neill:

In an effort to make Hadoop/MapReduce on Cassandra more accessible, we added a REST layer to Virgil that allows you to run map reduce jobs written in Ruby against column families in Cassandra by simply posting the ruby script to a URL. This greatly reduces the skill set required to write and deploy the jobs, and allows users to rapidly develop analytics for data store in Cassandra.

Smart: 10. Security: ?. Utility: 10.

Original title and link: Hadoop/MapReduce on Cassandra Using Ruby and REST (NoSQL database©myNoSQL)

via: http://brianoneill.blogspot.com/2011/12/hadoopmapreduce-on-cassandra-using-ruby.html

Russell Jurney describes the lifecycle of data/events in an analytic application:

EVENTS -> RUBY -> AVRO -> PIG -> VOLDEMORT -> SINATRA -> WEB BROWSER -> USER

The first step to building analytics applications with Hadoop is to plumb your application from end to end: from collecting raw data to displaying something on the users’ screen. This is important, because models can get complex fast, and you need user feedback plugged into the equation from the start.

Original title and link: Booting the Analytics Application (NoSQL database©myNoSQL)

via: http://datasyndrome.com/post/13707537045/booting-the-analytics-application-events-ruby

An old post from Santosh Kumar describes the sequence of steps to parallelize processing from single threaded apps to using Redis and Resque and going through forking and process pools. Santosh has written extensively about using Redis for concurrency or as a Message oriented middleware (MOM).

The next time you need to get some background job action going, stop yourself from just grabbing a library. Instead, toy around with redis lists a little. You’ll be surprised by how much you can accomplish with just straight redis primitives.

While I agree with the usefulness of Redis^[1], none of his posts say what comes after it. And that’s specialized solutions.

Original title and link: Parallelizing Work: From Single-Thread to Redis (NoSQL database©myNoSQL)

via: http://santosh-log.heroku.com/2011/07/24/parallelizing-work-with-redis/

Monty Williams (VMWare/GemStone) interviewed by Werner Schuster:

• MagLev VM takes full advantage of GemStone/S JIT to native code performance, distributed shared cache, fully ACID transactions, and enterprise class NoSQL data management capabilities to provide a robust and durable programming platform. It can transparently manage a much larger amount (terabytes) of data and code than will fit in memory.
• I don’t think of MagLev only as a Ruby VM that has an integrated NoSQL database. I think of MagLev as a NoSQL database that uses Ruby for its data manipulation language.
• The one thing I don’t think people have wrapped their heads around is MagLev provides a “single object space”. Nothing has to be sent/retrieved to/from a separate DB. All your code is executed “in the database.” You don’t even need to keep track of which objects have been modified so you can flush them to disk. MagLev handles that automatically. 
• You can store any Ruby object, even procs, lambdas, threads, continuations. Here is an example of stopping, copying, saving, and restarting Threads in a different VM than they originated in. blog.bithug.org/2011/09/maglev-debug
• MagLev persistence is akin to Image Persistence, i.e. objects are persisted to disk in the same format they are in shared cache. You don’t need to marshal them or convert them to JSON or another format.
• MagLev transactions are ACID, which means that multiple VM’s can interact with the same repository and share state, objects, and code while maintaining referential integrity.
• When you start a new MagLev VM, code loaded by another VM is likely to still be in the cache. So loading/requiring it can be quite fast.

Am I the only one confused by the mouthfullness of the above “NoSQL OODB” description?

Original title and link: MagLev NoSQL OODB With Smalltalk-Based Ruby VM (NoSQL database©myNoSQL)

via: http://www.infoq.com/news/2011/11/ruby-maglev-10

A bunch of Rails addons to enhance Mongoid mapped models timestamps, versioning, history, tagging, search, geo, tree, etc. — note how many of these libraries are calling themselves mapping tools or even ORMs and ask yourself if indeed there’s no impedance mismatch:

This is all made possible by the fact that MongoDB documents don’t need a schema and that mongoid has a very simple callback mechanism that can invoke your function when an object is created, modified or destroyed.

The reverse of the coin is that the more you add the more magic is happening behind the scenes. And magic doesn’t usually play well with performance.

Original title and link: Rails Extensions for MongoDB Mongoid (NoSQL databases © myNoSQL)

via: http://code.dblock.org/ShowPost.aspx?id=210

From Scotland Ruby 2011, Martyn Loughran:

I’ll tell three stories about the building of our web services Panda and Pusher. Three interesting problems which we solved simply and elegantly using eventmachine and Redis. I’ll show you real code, talk about writing elegant evented code, and hopefully inspire you to solve problems simply using these great tools.

Original title and link: Three stories about Redis and eventmachine (NoSQL databases © myNoSQL)

via: http://confreaks.net/videos/549-scotlandruby2011-three-stories-about-redis-and-eventmachine