January Mongo LA conference

Back in the mid-1990s my professional software development career started in relational databases. Periodically though I interacted with NoSQL databases. In 1999 I heard about ObjectStore. In 2003 I played with a few XML databases. With XML databases of the time, I found all you got out of them was a lot of complexity bolted onto a SQL based system. In 2006 I was introduced to ZODB, the Zope stack's object oriented database. ZODB has some fascinating traits, but the hard schemas used by Plone and Zope made it as rigid/stable as SQL systems but without as many useful tools. In 2008 I played a bit with Google's BigTable via appengine, where my impression was that of a relational database without indexes.

Since then, a lot of new NoSQL solutions that have embraced the idea of schema-less architectures have presented themselves. I've glanced at them but until recently nothing on my plate really justified their use and taking the time to learn how to use them. Recently I've come across a project that justifies the whole document store approach used in systems like MongoDB, CouchDB, and others. However, because users of NoSQL tend to be such heavy kool-aid drinkers, I've been a bit shy.

Well, last night Media Temple laid out an awesome spread for Mongo Los Angeles. The agenda was clearly a kool-aid fountain of information, but at least they weren't trying to sell me a timeshare, right? Plus, it gave me a chance to hang with awesome python folk like Audrey Roy and Brian Luft.

Most of the talks were will implemented, I've picked out two presentations out for being just plain well done:

Building your first MongoDB Application
Antoine Girbal delivered a talk that was a great, elegant introduction to MongoDB. In thirty minutes he gave a solid introduction to why Mongo was created, how the data is structured, how to call data, how to index it, and more. And yet it didn't feel like a firehose of information. This is how it should be done for any introduction to any open source project.

Beyond Logging: Using MongoDB to Power a Private Social Network
This was the pièce de résistance of the evening, a presentation on mating MongoDB with an existing relational database design. It was incredibly informative and demonstrated that with a bit of moderation and discipline you can make the very difficult rather easy. Plus the presenter, Justin Jenkins educates via learnmongo.com.

Have I drunk the kool-aid?
So what did I get out of these introductory talks? Well, it appears that MongoDB is exactly what I need for an upcoming Django project. The downside is that if I use MongoDB for all the persistence for this Django project then I lose the chief advantage of working with Django. I'm not talking about the admin and ORM themselves cause I know django-nonrel and mongoengine exists, I'm talking about the multitude of efforts that support the relational database roots of Django.

Also, this project involves quite a bit of information best stored in a relational database. Not everything is a document! And I know from a lot of experience that trying to fit a spiffy square peg into a round hole is dangerous. So what I'll probably do is use PostGreSQL for the accounting information and user management. The documents will be stored in MongoDB, with one of the indexes for said documents being on the username attribute of each document.

Simplicity itself, right?