Cassandra vs MongoDB For Time Series Data • Hacker News Board

Re: Cassandra vs MongoDB For Time Series Data

#41

Post by abalone » Wed, Aug 21, 2013, 9:48 PM UTC

I'm a little confused by the schema he describes. He says represent "periods" in columns and "records" in rows. Are these two different units of time?

For say stock data that is sampled every second, is he saying there'd be one row per symbol per minute (a "record"), with 60 columns holding the value for each second (a "period")?

If so, does that mean the data is buffered in memory for 1 minute before getting written to the DB?

"Cassandra is really good for time-series data because you can write one column for each period in your series and then query across a range of time using sub-string matching. This is best done using columns for each period rather than rows, as you get huge IO efficiency wins from loading only a single row per query. Cassandra then has to at worst do one seek and then read for all the remaining data as it’s written in sequence to disk.

We designed our schema to use IDs that begin with timestamps so that they can be range queried over arbitrary periods like this, with each row representing one record and each column representing one period in the series. All data is then available to be queried on a row key and start and end times."

Re: Cassandra vs MongoDB For Time Series Data

#42

Post by astral303 » Wed, Aug 21, 2013, 9:51 PM UTC

relistan wrote: post #19

astral303 wrote: post #15

I didn't see the size of the cluster described, but watch out for having timestamps as your row keys, for you are going to have hot spots (all timestamps in one token range). What is your replication factor and the size of the cluster? This might be improved with vNodes, though I'm not sure how granular and automatic the subnodes are. If they are just an even range (e.g. 256 vnodes across the same 00-ff range), then…

You're right. As I mention in the article, the row keys are not timestamps, the columns are timestamps. We use the RandomPartitioner for rows.

Sorry, I misread!

Re: Cassandra vs MongoDB For Time Series Data

#43

Post by Aaronontheweb » Wed, Aug 21, 2013, 9:56 PM UTC

ddorian43 wrote: post #28

Anyone uses cassandra with OrderedPartitioner and is it good ?(i know random is best)

OrderedPartitioner is definitely an expert-mode feature. You really have to have a good feel for the key proximity of reads and writes, or otherwise you can create some really nasty hotspots on individual nodes. We stick with Random.

Re: Cassandra vs MongoDB For Time Series Data

#44

Post by arohner » Wed, Aug 21, 2013, 10:01 PM UTC

snmaynard wrote: post #37

arohner wrote: post #22

Earlier quoted context omitted.

> 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-...

Mongo does have a global write lock. A per-db lock does me very little good when I only have one DB.

As to your linked doc, emphasis added:

> In some situations, read and write operations can yield their locks.

> Long running read and write operations, such as queries, updates, and deletes, yield under many conditions.

In practice, I've been bitten hard by this. A new feature rolls out, and users can't log in anymore, because a query is taking 2 minutes to run.

Re: Cassandra vs MongoDB For Time Series Data

#45

Post by kailuowang » Wed, Aug 21, 2013, 10:07 PM UTC

I am not sure if this is really an apple to apple comparison because from the article it seems that the data schema in Cassandra was carefully designed while it's not obvious whether it's the case for the MongoDB one("it was supposed to be a temporary one").

MongoDB has many many limitations. Data schemas have to be carefully designed taking them into consideration, otherwise they are going to have a huge impact to the performance.

Re: Cassandra vs MongoDB For Time Series Data

#46

Post by marshray » Wed, Aug 21, 2013, 10:42 PM UTC

abalone wrote: post #41

I'm a little confused by the schema he describes. He says represent "periods" in columns and "records" in rows. Are these two different units of time? For say stock data that is sampled every second, is he saying there'd be one row per symbol per minute (a "record"), with 60 columns holding the value for each second (a "period")? If so, does that mean the data is buffered in memory for 1 minute before getting written…

My dim understanding is that the term "column" in Cassandra doesn't mean what we think it means.

Re: Cassandra vs MongoDB For Time Series Data

#47

Post by VintageCool » Wed, Aug 21, 2013, 11:32 PM UTC

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…

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-...

Re: Cassandra vs MongoDB For Time Series Data

#48

Post by mh- » Wed, Aug 21, 2013, 11:56 PM UTC

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.

> I'd love to see [git-for-computer-scientists], but for every DB technology.

this is a fantastic idea. if someone gets this going I'll enthusiastically contribute.

Re: Cassandra vs MongoDB For Time Series Data

#49

Post by MichaelGG » Thu, Aug 22, 2013, 12:30 AM UTC

francesca wrote: post #32

arohner wrote: post #22

Earlier quoted context omitted.

> 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.

That sorta makes it sound worse, honestly, if databases in MongoDB are anything like you'd use the word for in any other datastore. A global lock across all databases is mind-bogglingly confusing; what's one DB got to do with another?

Couldn't you just work around that before by running a separate Mongo process per database?

Saying it's now on the database still means any single-database app is globally locked. Or does using Mongo imply you're going to be making lots of databases so this actually means anything?

Re: Cassandra vs MongoDB For Time Series Data

#50

Post by cbsmith » Thu, Aug 22, 2013, 12:35 AM UTC

snmaynard wrote: post #37

arohner wrote: post #22

Earlier quoted context omitted.

> 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-...

That's solves the contention problem, but just by virtue of yields on page faults being a big feature you can see where Mongo does have some scaling issue.