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

Cassandra vs MongoDB For Time Series Data

relistan.com

Post reply on HN
Print view View original

31–40 of 82 posts

Re: Cassandra vs MongoDB For Time Series Data

#31

Post by mnutt »

My company made the same switch from MongoDB to Cassandra, a little over a year ago. We were storing analytics counters in Mongo and wanted better consistency guarantees.

What we found when we switched was that Cassandra had better consistency with similar performance to MongoDB. Then a few months later, as we accumulated more data, performance started to take a nosedive. Counter increments began impacting other database operations and the nodes would become unresponsive. Eventually we moved all of the counters to an in-memory aggregator that flushed to Postgres a couple of times a second.

Counters were introduced in 0.8 (when we started using them) and are pretty half-baked. There has been some good discussion about overhauling counters, though I'm not sure when they're scheduled to land.

Re: Cassandra vs MongoDB For Time Series Data

#32

Post by francesca »

arohner wrote: post #22
mtkd wrote: post #7

Earlier quoted context omitted.

A pattern I've seen on a lot of the negative Mongo articles has been people using it for things they probably shouldn't. I've yet to use it for any load, and am struggling to triangulate from all the articles I read on whether it does/doesn't scale efficiently. All the issues I have hit so far have been self-inflicted, it is still one of the best new technologies I've used in years - but is has taken a while to stop…

> whether [Mongo] does/doesn't scale efficiently It doesn't. Three words: "global write lock". Writes block reads, reads block writes. Implications: if you run a query in production that doesn't hit an index, all traffic stops. The notablescan setting is a very, very good idea. This also means all queries must have an index, so Mongo ends up with more indexes than say, postgres would. It's impossible to configure a c…

The global lock was removed in 2.2

https://blog.serverdensity.com/goodbye-global-lock-mongodb-2...

Now locking is on the database level.

Re: Cassandra vs MongoDB For Time Series Data

#33

Post by foobar1988 »

arohner wrote: post #22
mtkd wrote: post #7

Earlier quoted context omitted.

A pattern I've seen on a lot of the negative Mongo articles has been people using it for things they probably shouldn't. I've yet to use it for any load, and am struggling to triangulate from all the articles I read on whether it does/doesn't scale efficiently. All the issues I have hit so far have been self-inflicted, it is still one of the best new technologies I've used in years - but is has taken a while to stop…

> whether [Mongo] does/doesn't scale efficiently It doesn't. Three words: "global write lock". Writes block reads, reads block writes. Implications: if you run a query in production that doesn't hit an index, all traffic stops. The notablescan setting is a very, very good idea. This also means all queries must have an index, so Mongo ends up with more indexes than say, postgres would. It's impossible to configure a c…

You could say the same about multi-master environments. Those are prime opportunities for losing data (eventually consistent does not mean consistent, it means data loss)

Re: Cassandra vs MongoDB For Time Series Data

#35

Post by gigq »

mnutt wrote: post #31

My company made the same switch from MongoDB to Cassandra, a little over a year ago. We were storing analytics counters in Mongo and wanted better consistency guarantees. What we found when we switched was that Cassandra had better consistency with similar performance to MongoDB. Then a few months later, as we accumulated more data, performance started to take a nosedive. Counter increments began impacting other data…

The company I work for had a similar experience with Cassandra. We were running it back in the 0.6 days. Once any of our nodes got around 500GB on them the performance would tank.

It seems that they later fixed the performance in 1.2 (http://www.datastax.com/dev/blog/performance-improvements-in...) but by that time we moved our data over to HBase and haven't had any regrets.

Re: Cassandra vs MongoDB For Time Series Data

#36

Post by koeninger »

cnlwsu wrote: post #30

For what its worth, we have been using Cassandra for storing time series for about 2 years now at ~2k writes a sec. I would say every issue was self-induced and Cassandra has been amazingly patient with us. It works amazing with this scenario. We experimented with MongoDB a lot initially (along with riak, hbase, etc) and found about the same thing. Turns out using a database in a way its designed to work turns out in…

I understand the nervousness, but I was able to convert a thrift/hector time series model to exactly equivalent CQL3 without too much trouble. The (perhaps non-obvious) options involved were "WITH COMPACT STORAGE" for wide rows and "WITH CLUSTERING ORDER BY (blah DESC)" for a reversed comparator.

http://www.datastax.com/documentation/cassandra/1.2/webhelp/...

Re: Cassandra vs MongoDB For Time Series Data

#37

Post by snmaynard »

arohner wrote: post #22
mtkd wrote: post #7

Earlier quoted context omitted.

A pattern I've seen on a lot of the negative Mongo articles has been people using it for things they probably shouldn't. I've yet to use it for any load, and am struggling to triangulate from all the articles I read on whether it does/doesn't scale efficiently. All the issues I have hit so far have been self-inflicted, it is still one of the best new technologies I've used in years - but is has taken a while to stop…

> whether [Mongo] does/doesn't scale efficiently It doesn't. Three words: "global write lock". Writes block reads, reads block writes. Implications: if you run a query in production that doesn't hit an index, all traffic stops. The notablescan setting is a very, very good idea. This also means all queries must have an index, so Mongo ends up with more indexes than say, postgres would. It's impossible to configure a c…

> Implications: if you run a query in production that doesn't hit an index, all traffic stops

Even if Mongo did have a global write lock, which it doesn't as has already been covered, it yields on page faults which means that other queries are minimally impacted. See: http://docs.mongodb.org/manual/faq/concurrency/#does-a-read-...

Re: Cassandra vs MongoDB For Time Series Data

#38

Post by bryanh »

It seems a bit out of the ordinary, but we've found ElasticSearch + facets to be wonderful ways to consume time series data. You can dump in a bunch of information about an event (for example, unix timestamp or even response time in ms) and then return a facet over the range and get bucket counts.

ES also has quite nice clustering abilities that make it pretty painless to scale out. If you are clever about your routing keys you can even go crazy pre-shard hundreds of shards very early on and not have any performance hit for map reductions, but the capacity to scale out with another node without reindexing.

We've been surprised at the swiss army knife like ability of ES.

Re: Cassandra vs MongoDB For Time Series Data

#39

Post by jbellis »

cnlwsu wrote: post #30

For what its worth, we have been using Cassandra for storing time series for about 2 years now at ~2k writes a sec. I would say every issue was self-induced and Cassandra has been amazingly patient with us. It works amazing with this scenario. We experimented with MongoDB a lot initially (along with riak, hbase, etc) and found about the same thing. Turns out using a database in a way its designed to work turns out in…

I sympathize with that perspective. I was a huge Thrift fan five years ago. But it became clear early on that, despite your experience and mine, most people had a really hard time wrapping their heads around Cassandra's Thrift API. Teaching CQL for the last 8 months has been a night and day difference. Ease of use does matter.

It doesn't hurt either that CQL is substantially more performant [1]. Perhaps that will sweeten the pill for you. :)

That said, while CQL may get the most publicity, we certainly haven't been neglecting the rest of the stack, e.g. [2], [3], [4], ...

[1] https://twitter.com/karbonized1/status/369472202015399936 [2] http://www.datastax.com/dev/blog/performance-improvements-in... [3] http://www.slideshare.net/jbellis/cassandra-summit-2013-keyn... [4] http://www.datastax.com/dev/blog/lightweight-transactions-in...

Re: Cassandra vs MongoDB For Time Series Data

#40

Post by trimbo »

relistan wrote: post #23
trimbo wrote: post #6

Earlier quoted context omitted.

You nailed it. I think the issue is that people don't know what questions to ask when gathering the requirements. I'd like to know more about how this part of the article came to be: "This choice was made early on and it was supposed to be a temporary one." HOW was that choice made. What requirements were out there. I think too many people choose Mongo because they believe it's "schemaless"[1] and faster for developm…

It was one of those, "we need to do something now and this will work" solutions. We had a really talented consultant working for us, writing some of the early code. He was familiar with Mongo and wanted to go that route. Early on I said we should use Cassandra for this, but it took us quite some time to get to the point of being able to migrate. A testament to his code and the "this will be temporary" foreknowledge i…

Cool, thanks for the info!
Post reply on HN