Today in his tech blog, Bozho set out his view that NoSQL is probably not a good choice for startups that don’t know yet where their database and application bottlenecks are:

But an important downside of NoSQL solutions, which is mentioned by most sources (twitter, facebook, rackspace) is that in NoSQL (at least for Cassandra and HBase) you must know what will be the questions that you will be asking upfront. You can’t just query anything you like. … And I can bet that a startup does not yet know all the questions it is about to ask its data store.

I wrote a similar conclusion in a feature article in September’s php|architect. Relational data modeling is driven by data, and there are mathematical rules of normalization that guide this process. Whereas nonrelational data modeling has no formal rules. It’s driven by the queries you need to support. Either you define your schema up front, or you define your usage of data up front, or else you set yourself up for a lot of sub-optimal queries and laborious database refactoring. You find yourself writing lots of code to reinvent the wheels that SQL gives you for free, and before long you’ve unwittingly reinvented the relational database.

There were also a few high-profile walk-backs and failures associated with NoSQL adoption in 2010. The most dramatic was the implosion of Digg after it launched a ground-up rewrite, architected around Cassandra. It turns out that no secret sauce can compensate for bad business decisions.

And who can forget the instantly-classic viral video MongoDB is Web Scale?
A little knowledge is a dangerous thing — the more little, the more dangerous.

In spite of this, I’m sure in 2011 we’ll hear some new claims of a panacea that puts a “turbo button” on your web server, supposedly obsoleting quaint, old-fashioned habits like thoughtful architecture, design, testing, and monitoring. I wonder what the miracle technology will be this time?

The latest release of CouchDB has a long list of changes, including:

• Added support for building a Windows installer as part of “make dist”
• Added optional “raw” binary collation for faster view builds where Unicode collation is not important
• Improved view information objects
• Improved speed and concurrency of config lookups
• Various improvements to the Futon UI

CouchDB 0.11.0 is the first release of the software that does not carry the “alpha” or “beta” tag. Whether this means the product can be considered production-ready is up to you, but the CouchDB wiki lists quite a number of projects already using the software.

I recently sat down and started playing with CouchDB, trying to wrap my head around this new way of “doing databases.” The CouchDB Wiki is a good place to start, although I found that it seems to presume a decent amount of prior knowledge (a definite hindrance to me, since I lack some of that prior knowledge!).

There’s also an online version of O’Reilly’s CouchDB: The Definitive Guide, and I found this useful to get myself started—although you should note that a few places were a tad out-of-date relative to the latest release (at least, that’s how it appeared to me). Nothing critical, though.

If you haven’t yet tried CouchDB, I recommend you do so; it’s definitely a different way of doing things than traditional relational databases, and it takes some getting used to, but it feels very natural after a while. Of course, it’s not necessarily going to outright replace your existing SQL-based data stores, but for the right project, it’ll surely be useful.

You can download CouchDB 0.11.0 from the CouchDB downloads page. You’ll also find a list of the changes incorporated in 0.11.0 there.

For instance, some people say that NoSQL is obviously all about ACID (atomic, consistent, isolated, durable) vs. BASE (basically available, soft-state, easy). Other people say it’s all about scalability, whereas others say it’s all about distributing data, but not necessarily horizontal scaling. Some people say it’s not about scale at all, but to get away from modelling data as rows in a table.

It’s a recent “movement,” but databases that have been around for decades are claiming to be NoSQL along with the ones hacked together in the last few months. Databases that are no more complex than Memcached are grouped with those that could power every aspect of a complex website on their own. There are databases ready for production deployment and others that are still in beta, alpha, or haven’t even been released.

The people themselves also vary widely: some of the developers are brilliant geeks who know scaling inside and out. Others are DBA-types who have been dealing with MySQL issues for years. Others are conceited jerks who think that, because they read the Dymano/Bigtable/PNUTS paper, they’re the only ones who understand the issues.

As I have read the Dynamo/Bigtable/PNUTS paper, here are the main issues:

Horizontal scaling

This is a biggie but, as people who like relational databases always point out, you can scale relational databases. It’s just very difficult and sacrifices a lot of the features that make them useful to start out with. Some NoSQL databases just scale much more easily and naturally.

Multi-master

Again, you can run MySQL as multi-master, but it’s a pain. Many NoSQL databases list multi-master as a feature, but a lot of programmers who think they want multi-master probably won’t like the reality of it. A quick quiz: does your heart sing at the thought of programming conflict resolution logic for every possible stale data scenerio? Then multi-master may be for you. (I’m not a big fan of multi-master, someone else may want to defend this one.)

Data representation

Rows can model a lot, but unless you’re programming accounting apps, they’re unlikely to be a natural fit for your data. More often than not, data is much more interesting and complex than a row (such as a graph of friends, a tree of links, or overlapping timelines of events). Sometimes, data is very simple (e.g., a cookie used to look up a session). Sometimes it changes over time. Many NoSQL databases give you a more flexibile way of modelling data.

Speed

Relational databases are pretty heavyweight with all sorts of data safety guarantees, which is unnecessary overhead for a lot of applications. Some NoSQL databases can store things as fast as Memcached (although not when they flush to disk… they are limited by physical laws, despite what their developers might claim). If you have something like page statistics or logging, using a relational database might just be slowing you down.

At this point, NoSQL databases are huddled together against the overwhelming presence of relational databases. However, NoSQL is an unnatural and, in many cases, uneasy alliance.

Photo credit: Great Protest Signs by didbygraham

The most popular websites in the world are switching to or already use non-relational databases. Why? Scalability. This session will cover why, when, and how to use MongoDB: a fast, stable, easy-to-learn document database.

Date: 3/26/2010
Special Guest: Kristina Chodorow
Topic: Mongo Scale!
Register Now!

Join us as our guest speaker, Kristina Chodorow talk MongoDB.

Sponsored by:

 

Eliot feels that the team has accomplished about half of their grand view for the project and hopes to address a few areas he and others feel the project is lacking in the next 6–12 months. A few of the items on the list are better replication, production-ready sharding, more features for working with embedded documents, and full text search capabilities.

He goes on to explain that he has changed how he describes MongoDB to interested parties. He envisions the project being an improvement on some of the shortcomings of relational databases such as MySQL. He states that “there are a lot of things that work great in relational databases: indexes, dynamic queries and updates…and we haven’t changed much there,” and that, as one example, the project aims to keep the methods for designing indexes the same as a database administrator would employ on a MySQL or Oracle database, but give him or her the option of indexing an embedded field.

The team is excited about production over the next year and continues to appreciate the community for the support, advice, debugging and interest it gives.

You can download the latest stable and unstable version of the MongoDB project from the download page and follow the instructions in the quickstart or the getting started page to get up and running. There is a listing of community support channels including a mailing list, IRC channel on Freenode, and the project blog if you need help or wish to get involved.