Ryan Angilly, Senior Developer, Punchbowl Software, gives some insights into his upcoming talk at the sold-out MongoSF about replacing MySQL with MongoDB at Punchbowl software titled, “Going from Zero to Mongo in About 2 Days”.

The discussion to deploy MongoDB was very anti-climactic.  I looked over at our Chief Architect, Blake Carlson, said “Hey I wanna use MongoDB for this.”  His reply was “Cool.”  I spent about half a day playing around with the Javascript Mongo shell, and then dove into getting things setup in a staging environment.  I had a Rails app talking to it (and to MySQL) with no problems by the end of day one.

Unexpected issues ran from the Ruby-specific: using a Hash to define a composite index when I should have been using an OrderedHash, to the SQL-generic: after a couple days in production, we realized I had simply forgot to add an index.  In the latter case, MongoDB really shined: mongod was at 100% CPU utilization for a day straight.  We added the index in 6 seconds with no downtime and CPU utilization fell off a cliff.  When something similar happened to Punchbowl in Feb ’09, we had to take the site down for 15 minutes to add an index on MySQL.

Q: Why did you decide to deploy MongoDB alongside your MySQL installation for the new application you launched at MyPunchBowl?

Ryan Angilly: We had a new application coming online (Vendor Connect) that had a certain set of requirements — stat tracking with “documenty” data — which seemed like a good candidate for a document store.  We’re pretty happy with MySQL in general, but migrations of large tables (adding columns or indexes) have started to become an issue.  Over the past couple years I’ve kept my eye on document-based storage engines, and MongoDB had been at the top of my list for a while.

Q: Are they still running side-by-side, or have you migrated entirely to MySQL?

Ryan Angilly: Completely replacing MySQL with MongoDB hasn’t ever been on the table.  While our growing user base is increasing the amount of time it takes to migrate certain tables, it hasn’t reached a critical mass.  We are going to start using Mongo for new features, and I could see some of our apps transitioning to MongoDB over time, but I don’t see that happening in the near future.

Q: Your talk is titled “Going from zero to Mongo in about 2 days”, did it take 2 days because it was easy to deploy MongoDB?

Ryan Angilly: Basically.  Getting MongoDB up and running took all of 5 minutes.  The documentation is fantastic.  The 1.0.0 release was plenty stable.  The title of the talk is more based on the fact that we pretty much just dove in and did it.  We didn’t have any huge debates.  I thought it looked cool and wanted to use it; the rest of the team trusted me, so off we went.  Some people have a vicious apprehension about using anything but an SQL database.  Some are worried about “all the work involved.”  This talk is mainly aimed at showing people it’s really not that big of a deal, and that, once you get started, having experience with a stable document-based database can be very useful.

Q: Do you think the same implementation using MySQL for a database/store would take the same amount of time?

Ryan Angilly: It would have taken less time to use MySQL, but that’s because of all my experience with SQL, MySQL & ActiveRecord.  Starting from scratch, you probably don’t get a huge advantage in terms of startup costs with MongoDB.  When you start to look at MongoDB as more than just a database, however, the landscape gets a lot more interesting.  We’re now evaluating using MongoDB to replace instances of Sphinx (full-text search, geo-spatial search) and memcached.  And compared to the time spent setting all that up, MongoDB would win.

Q: Would it yield the same amount of performance?

Ryan Angilly: I haven’t done any performance testing, but it’s hard to compare apples to apples.  MongoDB is certainly fast enough for everything we’ve thrown at it.  Anecdotally, I can say that it seems to add indexes much faster (without table locking like InnoDB) and the concept of migrating tables doesn’t even exist.

In the “list of things I like about MongoDB”, performance is on the list — but not near the top.  At the top of the list is the direction that 10gen is taking it.  You couple document-based storage, geo-spatial searching and full-text searching with master/slave replication, built-in map-reduce, and automatic sharding, and all of the sudden you have a lot more than just a place to store data.  You also have a solution for _using_ your data — that’s what excites me.

Stay tuned for upcoming Mongo(Your City Here) events by tuning into the 10Gen Web  site.