MongoDB in my photostre.am
Time to blog about the reasons why I’ve migrated my photostre.am application from MySQL to MongoDB. I hope by this I can give a few people arguments to do the same.
Document based
photostre.am is powered by Ruby, a dynamic and fully object oriented programming language (well, except for blocks). MySQL isn’t that far off when using ruby, you can’t stack data rows into other rows but any decent database adapter will do those relations for you. But if you heart dynamic functionality as much as I do there’s no future for you in a schema database and the schema-less ones your best option.
Arrays
Arrays are a wonderful data structure to work with, e.g. for tags, but if you want to access single elements from an array in a mySQL database you most likely end up creating at least one more table, where you store each single element of your array, and query on that. I know, there are workarounds but MongoDB stores it’s data in BSON format which offers you exactly that in the straightmost way. I couldn’t be more happy to store my tags right inside a photo and retrieving photos that match a tag is only one query. For photostre.am it also allowed me to add new features, for example the Website model stored a domainhost and in the MySQL database I was too lazy for this second table as it wasn’t a much important feature but in MongoDB it has become very quick and easy to add with no loss in performance (and for an object that’s queried with every request that is important.
Embedded objects
This is one of the most amazing features and completes my object oriented programming experience. With MongoDB you can store whole objects inside a parent objects. For example the Website in photostream stores albums and pages which are of course models in my rails application and have all the functionality a regular model would have except the don’t need another collection (table in sql speak). The old database had more than 10 tables, the new one only three collections. It helped me to reduce the number of queries and it just feels natural.
No more SQL
I know SQL quite well. Learned it the hard way in the early 2000s and I always prefer the console over phpMyAdmin and similar. With MongoDB I have a great console, with all modern features and as a bonus it’s all javascript which is a great language and much undervalued by most people but as powerful as ruby.
Sharding
Not yet a feature that I need but photostre.am is close to 200 users now and they all come with around 1000 photos (respectively just the data about those photos) and the database must grow faster in the future if I want to make any money with it. MongoDB with it’s sharding will allow me to split the database horizontal over several small instances and I won’t have to upgrade a single DB server with more RAM and CPUs like you would need with a mySQL database.

September 20th, 2010 at 10:58 AM
Very nice post…
FYI: http://photostre.am/ is down…
November 22nd, 2010 at 07:50 PM
I’m looking at MongoDB for an images and tags application but I am concerned about backup administration. Are you happy that you’re only choice is a full database dump to a .bson file?
September 9th, 2011 at 03:48 AM
Very nice post, But I still have a question about the picture storage. Did u guys store the picture binary data inside the MongoDB or just store the pic path in mongo and store the pic data in the file system?