Live data from Hacker News

MongoDB and DataStax, In the Rearview Mirror

blog.couchbase.com

1–10 of 55 posts

Re: MongoDB and DataStax, In the Rearview Mirror

#5
My problems with Couchbase:

- Completely opaque administration. The company charges for support ($5k per production node per year!), so perhaps unsurprisingly the log output is unreadable (similar to a binary stacktrace). Forget about diagnosing cluster issues on your own.

- Bizarre failover behavior. In every test scenario I've tried, if any single node goes down my application becomes unresponsive (even if it can see other nodes that are up). This could be a problem with the .NET driver, but it's hard to tell.

- Weird performance. Usually Couchbase is fast, but sometimes my application will go into what looks like a busywait loop and consume 100% CPU while trying to contact the Couchbase cluster. Again, possibly (probably?) a driver issue, but it makes me hate dealing with Couchbase.

- Ten bucket limit. Ostensibly for performance reasons, but cannot be over-ridden. Even if I'm running a non-production cluster where performance isn't critical.

At this point we're looking at switching to Redis. At least it's widely used and easier to administer.

Re: MongoDB and DataStax, In the Rearview Mirror

#8
post #6

Does anyone know if Couchbase can be used as a TB sized data warehouse? Seems a bit difficult since it seems all keys must be stored in memory.

It can and it is, but it might have to be scaled out.

http://www.couchbase.com/liveperson http://www.couchbase.com/paypal

Re: MongoDB and DataStax, In the Rearview Mirror

#9
Given that Couchbase is very aware of my criticism of the last time Thumbtack benchmarked C* vs Couchbase, it's significant that no mention is made of efforts to have both systems do durable writes. It looks like they made the same mistake a second time: http://www.datastax.com/dev/blog/how-not-to-benchmark-cassan...

(Update: the Couchbase pdf says that they used "the fastest consistency and durability modes available for the particular database" as cover for benchmarking different things... but even that wasn't done right; no mention is made of setting durable_writes=false in Cassandra.)

Post reply on HN