Throughout the 2000s, a huge number of website developers rejected the Enterprise Java or .NET platforms for web development in favor of the “LAMP” stack – Linux, Apache, MySQL and Perl/Python/PHP. Although the LAMP stack was arguably less scalable or powerful than the Java or .NET frameworks, it was typically easier to learn, faster in early stages of development - and definitely cheaper. When enterprise architects designed systems, they often chose commercial application servers and databases (Oracle, Microsoft, IBM). But, when web developers or startups faced these decisions, the LAMP stack was often the default choice.
However, we may be seeing in the web development community a tipping point away from MySQL and towards the NoSQL database MongoDB. Increasingly, I’m talking to web developers who see MongoDB as an attractive alternative to MySQL. This groundswell of adoption augurs well for the future of NoSQL in general, and MongoDB, specifically.
MongoDB is a document-oriented database that stores complex structures in JSON (JavaScript Object Notation) documents. It is open source, but commercially supported by the company 10gen, which offers services and support around the database. 10gen recently received an additional 42 million dollars in VC funding for a total of $73 million overall, reflecting an estimated company market valuation of somewhere around half a billion dollars!
MongoDB established an early lead in the NoSQL database space by providing a developer-friendly ecosystem and architecture. 10gen provides drivers and examples for each programming language, and the JSON format is very compatible with most object-oriented application models – resulting in cleaner application code than relational databases, which require objects to be normalized and de-normalized as they are stored and retrieved. As with most NoSQL alternatives, the ability to perform schema changes without disruption to database service is extremely attractive to websites that are evolving and mutating at rapid rates.
Early adoption of MongoDB was not without issue. Several MongoDB design decisions arguably favored performance over reliability, and so-called “single server durability” was absent by default in early releases. This meant that data needed to be replicated across multiple servers to avoid possible data loss if a server process failed. Restrictions on concurrent writes – the notorious “global server lock” which prevents contemporaneous write operations – also surprised and concerned many. A well-publicized 11-hour outage at Foursquare, following a MongoDB database failure, fueled these concerns.
Nevertheless, adoption of MongoDB has been rapid, and many of the technical issues have been resolved in recent releases. MongoDB still lacks some of the scalability and throughput capabilities of other NoSQL offerings, such as Cassandra or HBase, but, clearly, it has proved an ability to be the basis for a successful high-volume website.
MongoDB deployments at scale generally involve some compromises and careful consideration. Meticulous setup of replication and complex sharding schemes are typically employed to avoid durability and scalability concerns, and many sites require that each MongoDB instance fit within each server’s main memory to achieve consistent performance. Traditional BI tools do not yet integrate well with MongoDB, so for reporting and business analytics, export to RDBMS or some other store – often Hadoop – is required.
MySQL took off as part of the LAMP stack not because it was more functional, faster or reliable than alternatives such as Oracle. It was the ease of deployment, lower cost and simpler administration that appealed to the web developers of the previous decade. Likewise, MongoDB involves some compromises when compared to Oracle or another RDBMS. But like MySQL, it’s economical and developer-friendly. It is increasingly feeling like the “MySQL” of the NoSQL world.