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

21–30 of 55 posts

Re: MongoDB and DataStax, In the Rearview Mirror

#21

Post by cnlwsu »

skjhn wrote: post #16
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.

Really? ... Really? I didn't know my local file server that I SCP things too is better architected than S3.

Re: MongoDB and DataStax, In the Rearview Mirror

#23

Post by danws6 »

devanti wrote: 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.

At my previous company we experimented with a 12 node cluster (128GB per node) used as a datastore. At one point we had over 1 billion keys. This was back in the 1.x version where they persisted data into sqlite files so each file would have 100+ million rows in it. Persisting data took forever. Rebalancing took forever.

When it worked, it was very fast. When you lost a node, things went bad. The java client would lose it's mind trying to cope with an outage. We ended up writing a connection pool were we could just recreate our connections when we detected a node went out.

That said, it was the best distributed NoSQL solution we tried and might have improved a lot since I last used it.

Re: MongoDB and DataStax, In the Rearview Mirror

#24

Post by andrewvc »

Oh boy, this is rich. From the original source: It is always part of our process to invite vendors to provide configuration suggestions prior to testing and to share our methodology and preliminary results with each of them before we write conclusions. We will add any updates here should there be any before the final report is released. http://blog.thumbtack.net/new-benchmark-preliminary-results/

It's pretty irresponsible of Couchbase to post this on their blog given that statement. The benchmark is EXTREMELY limited in scope. Crucially, it's mostly about raw speed in a fairly artificial set of use cases. They only used one size of record for for christ's sake.

I'd say more, but I'll hold off till the final report.

Re: MongoDB and DataStax, In the Rearview Mirror

#26

Post by antirez »

Benchmarks are almost always not able to really provide a generally useful picture. When you see the actual database performance difference, is in your company, fighting for latency, in a given, specific use case, with a given writes durability and safety requirement. Every developer that really tried hard to optimize an application latency or performance knows how you end hitting the details, and very specific and database-dependent tradeoffs. TL;DR: pick databases after doing tests and simulations for your specific use case.

Re: MongoDB and DataStax, In the Rearview Mirror

#28

Post by jbellis »

jamieb wrote: post #27

A response from Jonathan Ellis, via jancona: http://www.datastax.com/dev/blog/how-not-to-benchmark-cassan...

(That was a response to a different benchmark, also done by Thumbtack, but it looks like it applies just as well to this one. See my comment at https://news.ycombinator.com/item?id=7944226.)

Re: MongoDB and DataStax, In the Rearview Mirror

#29

Post by skjhn »

jbellis wrote: post #20
skjhn wrote: post #15

Earlier quoted context omitted.

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 sys…

As can Cassandra. It depends on how much data is still in the page cache. I do agree both systems can be configured for immediate durability. However, we went with the default values as most people (and most databases) do not sync on every write. It is too much of a performance cost.

Re: MongoDB and DataStax, In the Rearview Mirror

#30

Post by jbellis »

skjhn wrote: post #29
jbellis wrote: post #20

Earlier quoted context omitted.

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 sys…

As can Cassandra. It depends on how much data is still in the page cache. I do agree both systems can be configured for immediate durability. However, we went with the default values as most people (and most databases) do not sync on every write. It is too much of a performance cost.

Cassandra cannot lose more than 10s of data because it will slow down writes as necessary to make sure it does not. That's why comparing to a system that allows arbitrarily high data loss is unfair.

People can and do run Cassandra with full durability. When people understand the tradeoff between performance and data loss on power failure, you'd be surprised how often they'll chose real durability. (And by batching concurrent writes into the same fsync, the penalty isn't nearly as high as it would be in a naive implementation.)

Post reply on HN