I'm an unabashed fan of MongoDB, the only NoSQL database just about everyone has heard of. Clients of my consultancy like MongoDB a lot because it performs well and scales out using commodity servers. Developers love it because it supports a flexible data model that makes building apps much easier than with SQL databases.
It's no shock, then, that I flew up to New York last week for the first-ever MongoDB World event. I walked away impressed at how MongoDB has grown up.
[ Do Twitter analysis the easy way with MongoDB | Work smarter, not harder -- download the Developers' Survival Guide from InfoWorld for all the tips and trends programmers need to know. | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
I expected to see startups and tech companies giving presentations about using MongoDB -- in the tech industry, other tech companies are always the early adopters. But when it was time for the case studies, out rolled Citibank, Verizon, Ticketmaster, the Gap, Forbes, Medtronic, and the British government. Sure, there were the usual innovators as well, such as LinkedIn, eHarmony, Amazon, and Expedia. But the big names stole the show.
Next came ecosystem announcements from Red Hat, IBM, and Teradata. You may think of the last one as a staid data-warehousing technology vendor that would ignore the likes of MongoDB, but Teredata announced both connector support for MongoDB through its QueryGrid technology and native support for a JSON datatype. I even interviewed Tereadata vice president Chris Twogood and MongoDB's Vijay Vijayasankar, on camera. I didn't skip the hard questions, such as where Teradata fits in with the brave new world of Hadoop and what MongoDB brings to the Teradata table and vice versa.
OMG, document locking at last
The biggest show-stealer, however, was the much-anticipated announcement of a core feature: document-level locking.
MongoDB, despite its reputation for Web scale (warning: video contains explicit language), also has a reputation for being persnickety at scale due to its locking semantics -- that is, write operations lock the entire database and/or shard. Now you can lock at the document level, a huge concurrency win. Without document-level locking, if you need some assurance of both consistency and scale, you're going to get (at best) random hiccups where the system just locks things. With the right data set and design, you can relax this, but you'll suffer data inconsistency or even data loss if you're wrong.
This is worse than a few years back where SQL Server 6.5 and DB2 did page locking and your only other choice was "dirty reads." From a system architecture standpoint, you would be stuck with seemingly random entire nodes of data locking.
Document-level locking is essentially the same deal as row-level locking in an RDBMS. It's not exactly the same, because a document can contain more data than a row in an RDBMS, but let's call it the same or better in most cases. In an RDBMS, multitable locks -- where you create a different table for one-to-many semantics -- can be less consistent than document-level locks when sub-attributes are also locked with the containing document. Row locking can also be less consistent, because it depends on when you locked the row, and in one-to-many relationships there's a difference between row and range locks. Let's stick to the same or better and call it a day.
During some of the sessions, various MongoDB engineers alluded to a future where multiple documents might be able to written with ACID consistency, at least "locally" to one shard. For more info, check out my video interview with MongoDB CTO and founder Eliot Horowitz about document locking among other matters.
The secret of MongoDB's success
The biggest MongoDB World news wasn’t really document locking, it was the maturity and the ecosystem that have evolved.
Started in 2007, the company has in some ways followed a typical startup path: It failed in its first incarnation as a platform-as-a-service play, then discovered that the database technology it had created offered the most value. Next, the company picked up VC funding and early technology-driven adopters. From there, small departments in big companies discovered MongoDB solved real Web-scale problems. Now big enterprises are catching on at a higher level.
Entering the big leagues carries some risks. Ops people start complaining that your stuff doesn't integrate with their monitoring tools, Linux package management, byzantine security products, and so on. On the one hand, you need to support all this to grow and tap deep pockets. On the other hand, the more you support, the more complex you become -- and risk losing your core constituency. Fail to stay cool and relevant, and you'll quickly discover that IT is fad-driven, not problem- or user-driven.
This is a critical time for MongoDB and it has a narrow course to steer. But as of this moment, it's also clearly the most successful NoSQL database out there. If you've been looking for an operational database that speaks JSON, but were holding off until a NoSQL solution reached "maturity," now's the time to give MongoDB a spin.
This article, "MongoDB grows up -- and shows off its enterprise cred," was originally published at InfoWorld.com. Keep up on the latest news in application development and read more of Andrew Oliver's Strategic Developer blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.