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

61–70 of 82 posts

Re: Cassandra vs MongoDB For Time Series Data

#61

Post by hcarvalhoalves »

arohner wrote: post #3

One thing I always find interesting about these kinds of problems is that most DBs don't describe how they're implemented. It's easy to use the wrong tool, and then once you learn how e.g. Mongo is implemented, it's obvious, "oh, that's why things are slow". I'd love to see http://eagain.net/articles/git-for-computer-scientists/ , but for every DB technology.

+1

It would be useful to treat databases as those big data structures, knowing the best/average/worst case, cpu vs. memory trade-offs for search, etc.

Re: Cassandra vs MongoDB For Time Series Data

#62

Post by wcdolphin »

I find it strange that there is no discussion of the performance of writing data.

Cassandra and Mongo differ hugely in this respect, and I expect you will see huge performance gains in write performance. Mongo's write locking will mean that reads will be blocked while you are inserting data. Reads in Cassandra may trigger compaction and or require sequential IO if the table has not yet been compacted, so the tradeoff is interesting

Re: Cassandra vs MongoDB For Time Series Data

#63

Post by rbranson »

wcdolphin wrote: post #62

I find it strange that there is no discussion of the performance of writing data. Cassandra and Mongo differ hugely in this respect, and I expect you will see huge performance gains in write performance. Mongo's write locking will mean that reads will be blocked while you are inserting data. Reads in Cassandra may trigger compaction and or require sequential IO if the table has not yet been compacted, so the tradeoff…

Reads in Cassandra will never trigger a compaction. Compaction is only be triggered by writes. If the compaction queue gets behind due to overloaded CPUs / disks, reads will begin to slow down.

Re: Cassandra vs MongoDB For Time Series Data

#64

Post by Xorlev »

otterley wrote: post #18
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…

For what kind of application or workload is MongoDB superior to the alternatives?

The kind that lives on a single VPS and requires a rich query layer to bootstrap quickly.

Re: Cassandra vs MongoDB For Time Series Data

#65

Post by leif »

nasalgoat wrote: post #60
VintageCool wrote: post #47

Earlier quoted context omitted.

TokuMX. They ripped out the native MongoDB storage engine and replaced it with the TokuDB engine. http://www.xaprb.com/blog/2013/04/29/what-tokudb-might-mean-...

TokuDB doesn't currently have a drop-in replacement strategy, so you'd need to migrate your whole cluster. A daunting task with hundreds of shards!

Such a thing could never exist, because the point of tokumx is to change the storage system, so at some point you have to change the storage over and that's just going to be a rewrite of all your data. It sucks but that's the way it is.

Re: Cassandra vs MongoDB For Time Series Data

#66

Post by abalone »

nemothekid wrote: post #57
abalone wrote: post #55

Earlier quoted context omitted.

I see. From what I know about Cassandra, this is a much more expensive write than doing it as a new row. To do this he has to be using dynamic columns, and those are stored as one serialized blob per row. So the more data you have in the row, the more expensive the deserialization/reserialization is with each column you add. For very large series this could be an issue. But it sounds like this is tolerable for his ap…

1.) You do not have to use dynamic columns for this. Unfortunately I've found in my own experience, as Cassandra has matured over the last year, alot of terminology has fallen in and out of fashion and its hard to recognize what is actually current. Dynamic columns in CQL3 has nothing to do with the behavior OP is talking about and in dynamic columns are sort-of a deprecated feature in Cassandra 1.2. In CQL3, OP's us…

Thanks. I definitely need to read up on Cassandra wide rows now.

Re: Cassandra vs MongoDB For Time Series Data

#67

Post by gwu78 »

I'm assuming this website is being served from S3 based on the HTTP headers. As I'm typing this, I get an empty Content-type: header. Is that a configuration oversight or is this par for the course if serving web pages from S3?

Re: Cassandra vs MongoDB For Time Series Data

#68

Post by snowwindwaves »

rishid wrote: post #56

Isn't graphite designed specifically for time series data? Or is there another use case to use Cassandra over Graphite?

graphite's back end is called whisper and it is a rrdb type datastore which throws away data as it gets older. You can see a plot of your time series from three years ago with a datapoint per day, but not one data point every .5 seconds that you initially recorded at.

Re: Cassandra vs MongoDB For Time Series Data

#70

Post by Ecio78 »

snowwindwaves wrote: post #8

i work on scada systems which usually come with a time series database built in so that operators can do some basic plotting. Often these products have a 10 or 15 year legacy. The scada vendors seem to be careful to avoid making the time series database and plotting tools which come with the HMI packages too powerful, as this might cut in to their sales of Historian type products. If it wasn't a commodity already, th…

What about Graphite http://graphite.wikidot.com/faq ? I've never tried but it is described as "Scalable Realtime Graphing". It seems to use an internal database so maybe it's not ok for you..

EDIT: I read another comment from you, you said it's rrd-like so it gets rid of old data, not what you're looking for..

Post reply on HN