Development Blog: Viget Labs

I wanted to clear up a couple of misconceptions about NoSQL that I've seen much too often lately (what can I say – I watch the Twitter results for 'nosql' obsessively).

Scalability/Performance

NoSQL is just about scalability and/or performance.

This is a particularly attractive claim for the traditionalists because it allows for the hope that these alternatives could be made obsolete in the future by making your RDBMS of choice faster or more scalable.

Unfortunately (for the traditionalist), there's a lot more to NoSQL than just performance and scaling. Most importantly (for me, at least) is that NoSQL DBs often provide better substrates for modeling business domains. I've spent more than two years struggling to map just part of the comic book business onto MySQL, for instance, where something like a graph database would be a vastly better fit.

Database Types

NoSQL is just document databases, or key-value stores, or ...

Most of the anti-NoSQL articles I've seen have addressed only document-oriented databases or key-value stores (though recently, column-oriented databases have started to show up as well). Good arguments can be made against each of those solutions for specific circumstances, but those are arguments against a specific type of storage engine. The problem with pointing to those articles as rebutting the utility of NoSQL in general is that the label is much broader than traditionalists usually understand.

"NoSQL" covers a vast set of applications, from Redis all the way up to Neo4J. Any argument that shows that, say, document-oriented databases fail in a set of situations may very well not apply to key-value stores or graph databases, and the further arguments required to make those cases are rarely (if ever) provided.

FriendFeed & MySQL

I can do NoSQL just as well in a relational database.

Well, sure, you can (and FriendFeed did, apparently) – but you shouldn't. I could roll my own relations in MongoDB, but that doesn't make it a good idea. Different applications are good for different things; relational databases are great for relational data, but why would you want to use them for non-relational data?

Never SQL

NoSQL is a wholesale rejection of relational databases.

Happily, this claim is becoming less common; many proponents of NoSQL have softened their rhetoric, and the traditionalists have become a little less defensive. It seems that we're moving towards a pluralistic approach to storing our data, and that's a good thing. I've suggested 'polyglot persistence' for this approach (though I didn't coin the term), but I also like Ezra Zygmuntowicz's 'LessSQL' as a label, too.

As part of our NoSQL exploration, I’ve spent some time lately with MongoDB. MongoDB bills itself as a “schema-free document-oriented database.” In using MongoDB, I’ve found it to be an easy transition from RDBMS’s because of the way it organizes document-based data. Here’s the basics:

• MongoDB has collections of data, not tables. Unlike CouchDB, which is also a document-oriented DB, Mongo has namespaces for data. These are schema-less, so any data could go in each namespace. In my practice, I’ve persisted objects of one class into each collection, not unlike ActiveRecord with MySQL or any other RDBMS.

• MongoDB has indexes. Even though each collection has no schema, you can still index the data in a collection based off a field. Not all documents in a collection have to have this field.

• MongoDB has a query language and query profiling. While you can use JavaScript to search through a collection, like CouchDB, you also have access to a rich query language that can filter based on fields, like SQL, and filter based on the contents of embedded documents, which proves to be totally freaking awesome. Instead of a complex join, you can query for all documents in the posts collection that have an embedded comment in the last month.

Continue reading "Getting Started with MongoDB & MongoMapper"

In my introductory post, I explained what Garb was, and how it could be useful to those wishing to get access to their Google Analytics data. In this post, I would like to introduce the latest version of Garb (0.2.1 as of this writing) and explain the many changes and new ways to use Garb to get at your data.

Getting sessions and profiles is still exactly the same.

  Garb::Session.login('username', 'password')
  profile = Garb::Profile.all.first

What's new in 0.2.1 is the way in which reports are built and results are retrieved. Check it out:

As a Report Class

  class Exits
    include Garb::Resource

    metrics :exits, :exit_rate
    dimensions :request_uri
  end

Getting the Results with a Class

  Exits.results(profile, :limit => 10,
                         :offset => 20,
                         :start_date => (Date.today - 30),
                         :end_date => Date.today)

  # With Filtering and Sorting

  Exits.results(profile) do
    filter :request_uri.contains => 'fun', :exits.gte => 1000
    sort :exit_rate
  end

One-off Report

  report = Garb::Report.new(profile)
  report.metrics :exits, :exit_rate
  report.dimensions :request_uri

  # With Filtering and Sort

  report.filter :request_uri.contains => 'fun'
  report.filter :exits.gte => 1000
  report.sort :exit_rate.desc

  # Getting Results

  report.results(:limit => 10,
                 :offset => 20,
                 :start_date => (Date.today - 30),
                 :end_date => Date.today)

The results returned from Garb will be OpenStructs with methods for each of the metrics and dimensions in an array.

  results.exits       #=> 1234
  results.exit_rate   #=> 0.20423810234
  results.request_uri #=> '/some/fun/url/to/a/page'

Overall, we feel that the improvements are solid and make more sense. Be warned: if you've used a previous version of Garb, then updating to the latest version will very likely break most of what was done previously. I hope everyone can find a use for this, and I encourage all to check out the project on Github and to read the documentation in the Wiki.

Since Google announced that they would be releasing an API for their de-facto analytics tools I was pained with the effort to contain my excitement. The results were a reporting tool and a new gem: Garb.

Continue reading "Introducing Garb: Access the Google Analytics Data Export API with Ruby"

I’ve been enthusiastic about the Scala programming language for a few months now, and this week’s been very exciting for the Scala community. A new Scala book from the Pragmatic Programmers was announced today, and Alex Payne from Twitter gave a presentation at C4 that strongly indicates Twitter’s writing part of their platform in Scala. Given this week’s news, I thought I’d explain why I’m using Scala, and what that means for the Lab.

Continue reading "Scala: The Adventure Begins!"