Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MongoDB and DataStax, In the Rearview Mirror

blog.couchbase.com

Post reply on HN
Print view View original

11–20 of 55 posts

Re: MongoDB and DataStax, In the Rearview Mirror

#11

Post by nwenzel »

When are we going to be finished with raw speed tests? I get it that faster is better. But I've always been a believer that good design will get you farther than choosing one software/hardware/infrastructure over another.

Also, I get the comparison of MongoDB and Couchbase. But why Cassandra from DataStax? It's a completely different technology with entirely different strengths and weaknesses. There are certainly overlapping use cases, but it seems like an odd comparison.

The better comparisons would seem to be comparing Couchbase to vanilla CouchDB and Cloudant's version of CouchDB. I guess you could throw in MongoDB, but MongoDB and CouchDB have different strengths and weaknesses. Raw speed alone doesn't exactly leave any technology in the rearview mirror.

Re: MongoDB and DataStax, In the Rearview Mirror

#12

Post by ddispaltro »

threeseed wrote: post #3

That's odd. I was under the impression that DataStax Java drivers had knowledge of the cluster and so weren't sending requests to random nodes. http://www.datastax.com/doc-source/developer/java-apidocs/co...

I know the Astyanax driver from Netflix supports a "token aware" strategy. Here is a link to the docs:

https://github.com/Netflix/astyanax/wiki/Configuration

Depending on how the consistency level is set it could potentially save a "route" to the other host.

Re: MongoDB and DataStax, In the Rearview Mirror

#13

Post by rsvihla »

threeseed wrote: post #3

That's odd. I was under the impression that DataStax Java drivers had knowledge of the cluster and so weren't sending requests to random nodes. http://www.datastax.com/doc-source/developer/java-apidocs/co...

You actually have to use it though. TokenAware is one of many policies most of which can be layered on top of one another. Just depends on how they had the driver configured.

Re: MongoDB and DataStax, In the Rearview Mirror

#14

Post by jbellis »

rsvihla wrote: post #13
threeseed wrote: post #3

That's odd. I was under the impression that DataStax Java drivers had knowledge of the cluster and so weren't sending requests to random nodes. http://www.datastax.com/doc-source/developer/java-apidocs/co...

You actually have to use it though. TokenAware is one of many policies most of which can be layered on top of one another. Just depends on how they had the driver configured.

Token aware is the default now, but Thumbtack benchmarked with the two year old Thrift client instead.

Re: MongoDB and DataStax, In the Rearview Mirror

#15

Post by skjhn »

jbellis wrote: post #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 availabl…

Well, writes are not durable until fsync. That's true for MongoDB, Cassandra and Couchbase Server. That being said, Cassandra demonstrated great write latency. The issue was read latency.

Re: MongoDB and DataStax, In the Rearview Mirror

#16

Post by skjhn »

nwenzel wrote: post #11

When are we going to be finished with raw speed tests? I get it that faster is better. But I've always been a believer that good design will get you farther than choosing one software/hardware/infrastructure over another. Also, I get the comparison of MongoDB and Couchbase. But why Cassandra from DataStax? It's a completely different technology with entirely different strengths and weaknesses. There are certainly ove…

Performance is a reflection of architecture. Better performance, better architecture. That, and you can never downplay performance.

Re: MongoDB and DataStax, In the Rearview Mirror

#19

Post by vosper »

bkeroack wrote: post #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 s…

Hi, thanks a lot for posting this! I have been thinking about using Couchbase Server for a mobile project because I like the mobile client component they have. I'm particularly concerned about the "opaque administration" issue - have you had to actually pay the company [1] for support because the log output is so bad, or did it just slow down your debugging process.

[1] I have nothing against paying for support, but this is a personal project

Re: MongoDB and DataStax, In the Rearview Mirror

#20

Post by jbellis »

skjhn wrote: post #15
jbellis wrote: post #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 availabl…

Well, writes are not durable until fsync. That's true for MongoDB, Cassandra and Couchbase Server. That being said, Cassandra demonstrated great write latency. The issue was read latency.

Of course they are not durable until fsync; that is why having an upper bound on how long that will be is important.

Out of the box Cassandra defaults to an upper bound of 10s. Couchbase defaults to no upper bound at all -- you can lose arbitrary amounts of data on power loss. That's a huge difference.

Since Couchbase does not support a time bound on fsyncs, there are two ways to make a fair comparison: make both systems fsync before acknowledging any write (commitlog_sync: batch in Cassandra and persistTo: master in Couchbase) or give Cassandra an unlimited durability window like Couchbase (durable_writes=false at the keyspace level). Of the two, the former is a lot more reasonable in real world scenarios, but the latter is at least more defensible than apples-to-oranges.

Post reply on HN