Hacker News Reader

Comment by druiid | Hacker News Reader

Whenever I see articles come up like this one mentioning MongoDB, I wonder not why people decided to go with Mongo, but why they didn't go with some of the alternatives out there? For my part, we use Couchbase to great success and it fixes many of the complaints against MongoDB. Then there's Riak and countless others with well established quality installations. To me MongoDB seems the buzzword NoSQL engine that gets used for 'play' projects, but not much in the way of real-world implementations. Thoughts?

View on HN

I do not see any of those other NoSQL databases as really being equivalent. MongoDB intends to be a general-purpose application database. It has many of the features developers expect from MySQL/Postgres, such as arbitrary numbers of indexed fields, partial record updates, aggregation queries (simpler than Map/Reduce) and many others. Couchbase may be much closer in feature-set but its developers claim they do not really compete with Mongo.

I do not see Riak or Cassandra as competing at all. In fact I would expect most applications that use Riak or Cassandra are also using a general-purpose database as well (such as MySQL or Mongo). You could use some of those databases as a general purpose database but it would be more work for little benefit. It makes more sense to me to use Riak or Cassandra for use-cases that really need high-throughput and unlimited write-scalability and use an app database for things like user accounts and preference management and all the little things that can take up a lot of development time but will never have really demanding runtime requirements (for 99.99% of internet apps).

Good points for sure. I think though I'd personally look at the different solutions on both an architectural and feature basis. A good number of the reasons that the original article listed as issues they came across, were outside the realm of features available in the actual MongoDB system (more or less) such as problems with logging, monitoring, backups, etc and were more architectural issues. To be certain, these can (and probably will) be issues with other systems to investigate.

So, if someone asked you why they should use "Riak and countless others" and not MongoDB, what would you really say? Also, you seemed to imply that Riak was a go-to solution (my wording) while implying that MongoDB was more of a fringe "buzzword" technology ... when, counting features, I think most would acknowledge MongoDB as being more mainstream.

There are a large number of well-established and quality installations of MongoDB. It works really well at both small and large scale and with a bit of tweaking (like any technology), can perform nicely.

I would say that (and I suppose this is a bit of a weasel words style answer) each is going to have their benefits and drawbacks and they would have to investigate each for their particular use-case to determine which would best work for them. I think it's pretty true though. I didn't mean to imply that Riak is a go-to solution at all. It was more to give a couple 'options' to explore if you were to start a list along with MongoDB.

I agree and I do think that often times people will select a technology and think it should work like some other technology, become frustrated when it doesn't and then, in turn, blast the technology on only the merits they understand.

There are certainly reasons for using Riak, HBase, Cassandra, etc. and there are reasons for using MongoDB. It is when people seem to act confused when their hammer isn't acting like a screwdriver that we get these blog posts.

You can't currently change only a single field in couchbase (ex:increment this field) in neither couchbase nor riak.

Range sharding (for saas,shard by client_id).

No sorting by value on couchbase indexes? And many other small features.

On the other hand i love about couchbase: no mongos,all servers equal.

Thanks, all good points.

I'm curious on the index sorting though, do you mean in terms of specifying what to sort on, or that you can't sort at all? As far as I understood the new indexing capabilities allow at the very least to sort on numeric values and similar.

You can't sort the results of a view by value:

http://www.couchbase.com/forums/thread/how-do-you-sort-resul...

Did you read the article? His main reason had nothing to do with Mongo itself.

Yes, yes I did. My question is why it was selected in the first place, rather than a period of exploration of the benefits and drawbacks of the different NoSQL solutions (which perhaps might have stopped this particular test-case from being a failure). The article doesn't mention those details though.

Also, we DO implement a two DB setup... Couchbase and MySQL. They both have their place.

I don't think you read it very carefully; the second sentence links to the earlier article where they list the reasons they chose that tech over others.

> I wrote about what I was thinking at the time here [1]

[1] http://codeascraft.etsy.com/2010/05/19/mongodb-at-etsy/

Then you would know that they were doing this in 2010, before Couchbase.

Reply on news.ycombinator.com