With any new technology comes a wave of marketing happy talk, which in turn leads to inexperienced developers "jumping on the train" of a new fad. Inevitably, these newbies find themselves disappointed that the technology doesn't deliver on their inflated expectations.
A case in point is the NoSQL movement, which has been the darling of the software world for the past year. The backlash is already in full swing. Just this past week or so, the blogs have been abuzz with hate for MongoDB in particular. On the face of it, these critiques appear to be scathing indictments not only of MongoDB but also, possibly, the very idea of a document databases or even the whole NoSQL/big data movement.
[ Also check out "Flexing NoSQL: MongoDB in review." | Discover what's new in business applications with InfoWorld's Technology: Applications newsletter. | Keep up with the latest approaches to managing information overload and compliance in InfoWorld's Enterprise Data Explosion Digital Spotlight. ]
Dig deeper, however, and I'm not sure these self-appointed critics are holding the screwdriver from the right end. Here are some excerpts from several recent posts -- and my responses.
Repeating the same mistake only bigger
In "Why I migrated away from MongoDB," Siddharth Sharma felt MongoDB failed to live up to his expectations for his project, which he described thusly:
digiDoc is all about converting paper documents like receipts and business cards into searchable database, and so a document database seemed like a logical fit(!).
Document databases are not at all ideal for complicated big data analytics and gigantic map-reduce jobs. Yes, you can. Yes, people do. In general, no, you shouldn't.
MongoDB is not a search engine. While it offers search, if search really is your business, then maybe you need a search engine like Solr/Lucene. Sharma continues:
I completed a migration to Postgres yesterday. Very happy. Aggregation is a breeze, search is a breeze, and we've built some pretty powerful tag search and management features that do not even bear thinking about in MongoDB.
Wha? Exsqueeze me? PostgreSQL is a search engine? Sure, PostgreSQL offers search, but compare PostgreSQL search to something like Solr. It's hard to see why you'd drive that screw into a wall with a hammer.
In short, people are continuing to make the same mistakes they made with their RDBMSes, only in a bigger way. In an RDBMS, you should not seek to have "one holy schema" that is ideal for both your operational system and your analytical system. In the world of NoSQL, you shouldn't necessarily seek to have the same database for both your operational and analytical systems. Sharma wraps up with:
What was I getting in return for dealing with all this? Web scale doesn't interest me so much. digiDoc is tiny and RDBMS have proven themselves to work at whatever scale we're likely to achieve.
Therein lies the issue. You were familiar with an RDBMS and you didn't have the kind of problem that makes you need to think about a problem in a different way. So you tried to use a document database as you would have used your RDBMS. Yet if you're working on a tiny application that doesn't have high scalability requirements and you're familiar with PostgreSQL, why not use PostgreSQL?
Be very circumspect when turning your back on 40 years of computer science. Graph theory, document databases, and so on are nothing new to computer science. Lotus Domino used a document database decades ago.
The lesson to be learned here is: Don't solve a simple problem with a completely unfamiliar technology and apply it to use cases it isn't especially appropriate for. In short, dude, you're holding it wrong.
But Google said...
Now let's turn our attention to a post by Todd Hoff on the High Scalability blog. He interprets a paper on the Google Research site about Google's new globally distributed database, Spanner, as a signal that the company is veering away from NoSQL:
Reading the Spanner paper I felt it had that chiseled in stone feel that all of Google's best papers have. An instant classic.
So you read a paper from Google Research on Spanner. I had a different reaction: "Is Google so flush with cash that no one ever says, 'Why don't we use an existing solution?'" Dude, this is the same architecture as VMWare's Gemfire (formerly Gemstone and over a decade old) and Red Hat's Infinispan. There are several others out there. Of Spanner's architecture, Hoff asks:
What was the cost? It appears to be latency, but apparently not of the crippling sort, though we don't have benchmarks. In any case, Google thought dealing with latency was an easier task than programmers hacking around the lack of transactions. I find that just fascinating. It brings to mind so many years of RDBMS vs NoSQL arguments it's not even funny.
Yeah, so Google is a big company with many types of problems and many people solving those problems in different ways with loose coordination. "Loose coordination" is a redundant way to describe the way most big companies devvelop stuff; only Apple at least seems to move in cult like lock-steps, even off of a cliff.
What Google probably realizes, and most of its fanboys do not, is that it needs multiple types of databases. The "one size fits all" approach did not scale or perform well; we just beat it with a bigger hammer each year and suffered the consequences. There will never be one NoSQL database to destroy them all.
Basic unfamiliarity
Diego Basch goes right after MongoDB with some rather specific accusations:
Sure enough, my database had reached 2GB in size, and the inserts started failing silently. WTF zomg LOL zombie sandwiches!
OK, so 2005 called and they want their computers back. The fact that that 32-bit processes are limited to 2GB to 4GB (depending on OS and page size) is common knowledge. It's baffling why anyone would deploy a "Web scale" database on 32-bit hardware. Did your dad loan you his old office computer? On the other hand, Basch says:
If you tell a database to store something, and it doesn't complain, you should safely assume that it was stored.
You got me there. I agree that the default MongoDB settings are probably not well chosen. Also, although I don't have a 32-bit OS or machine available to run my own tests, something tells me there is a log file with your name on it that you missed.
Something also tells me that you don't have a particularly good use case for a document database or the kinds of traffic that makes these decisions "have to's" instead of "because I read a blog on it." In short, "MongoDB doesn't run on my netbook" doesn't mean that it sucks.
Anonymous says...
Much of the recent anti-buzz sounds like the same stuff from about a year ago when some dude who courageously posted anonymously on pastebin said:
Our team did serious load on MongoDB on a large (10s of millions of users, high profile company) userbase, expecting, from early good experiences, that the long-term scalability benefits touted by 10gen would pan out. We were wrong, and this rant serves to deter you from believing those benefits and making the same mistake we did. If one person avoids the trap, it will have been worth writing. Hopefully, many more do.
What follows is a scathing indictment of MongoDB. However, the CTO of 10gen refuted it all -- and shortly afterward, the poster confessed he was a troll spreading misinformation.
The right tool for the job
Last week I gave a talk at CouchConf in San Francisco. It was basically a 40-minute live version of my "Which freaking database should I use?" article introducing people to the NoSQL landscape. I was afraid it would be lightly attended, since I assumed everyone at a conference on CouchBase (also a document database) would be familiar with the different types of databases and their use cases. But the talk was not only well attended, lots of folks were there taking notes and pictures. My concern is that a number of people are trying NoSQL databases and reaching disillusionment without either understanding the proper use case for the type of database they are choosing or without the help they need in changing their development paradigm.
As David Mytton said on the Server Density blog, "What we're really seeing is the hype cycle in action rather than everyone hating MongoDB." Also, as the pastebin troll revealed:
My intention was to troll as many hipsters as possible and make them a little more aware of how easy to manipulate they are, without even providing the slightest bit of evidence. It cracks me up that there are startups out there right now, making foolish architecture decisions based on the FUD I'm spreading. Start thinking for yourself!
In other words, take these blogs with a bucket of salt and make sure you understand the technology before using it on a critical project. If you don't heed this advice, some writer for Infoworld on a short deadline in a slow news week might decide to ridicule you!
This article, "Ill-informed haters go after MongoDB ," was originally published at InfoWorld.com. Follow the latest developments in business technology news and get a digest of the key stories each day in the InfoWorld Daily newsletter. For the latest developments in business technology news, follow InfoWorld.com on Twitter.