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

51–60 of 82 posts

Re: Cassandra vs MongoDB For Time Series Data

#51

Post by nemothekid »

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…

No, OP's wording can be confusing if you have never used Cassandra before.

You are right. There is one row per symbol. However with Cassandra any given row can have any number of columns, so when you want to write a new value, you just create a new column for that second (/period).

The writes are not buffered in memory.

Re: Cassandra vs MongoDB For Time Series Data

#52

Post by nemothekid »

kailuowang wrote: post #45

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

When it comes to timeseries data, there aren't a lot of ways to design your schema. In my experience when working with a write heavy load such as timeseries data, you are always fighting the writelock with MongoDB. AFAIK, there isn't much you can do about your schema to combat this.

Re: Cassandra vs MongoDB For Time Series Data

#53

Post by ericb »

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…

With something like Kairos, how do you segment the time series data? Like if I wanted to use it to keep track of stats for 2 different customers, how would that work?

Re: Cassandra vs MongoDB For Time Series Data

#55

Post by abalone »

nemothekid wrote: post #51
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…

No, OP's wording can be confusing if you have never used Cassandra before. You are right. There is one row per symbol. However with Cassandra any given row can have any number of columns, so when you want to write a new value, you just create a new column for that second (/period). The writes are not buffered in memory.

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 app because the writes are distributed over time in a predictable fashion.

I am a little surprised though at the author's claim that fetching a single big row results in "huge IO efficiency" over a range of small rows. I'd expect a small amount of overhead, but isn't it more or less the same amount of data being retrieved? What am I missing?

EDIT: I see the author mentioned that it reduces disk seeks because it's all serialized together already. Sort of like you're defragging the series data on every write. I guess that makes sense.

Personally I would probably look at using SSDs and keep the schema more "sane" and have more scalable writes, but that's just me.

Re: Cassandra vs MongoDB For Time Series Data

#57

Post by nemothekid »

abalone wrote: post #55
nemothekid wrote: post #51

Earlier quoted context omitted.

No, OP's wording can be confusing if you have never used Cassandra before. You are right. There is one row per symbol. However with Cassandra any given row can have any number of columns, so when you want to write a new value, you just create a new column for that second (/period). The writes are not buffered in memory.

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 use-pattern in actually hidden if you didn't know any better.

In short, there is no deserialization/reserializaion. OP's writes are append only. I have a similar use pattern to OP, and I haven't seen any performance issues with 100,000s of columns (on SSDs)

2.) The "huge IO efficiency" is similar to what you would see in any columnar data store. Wikipedia has a good walkthrough of it (http://en.wikipedia.org/wiki/Column-oriented_DBMS). The short story is now there is fewer meta data between his values.

--

In any case, it works out because Cassandra is far more well suited for this type use pattern than Mongo is. We migrated from MongoDB (on SSDs) to Cassandra for similar reasons. The perf-killer on Mongo in this scenario is the write lock.

Re: Cassandra vs MongoDB For Time Series Data

#58

Post by nasalgoat »

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

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…

It doesn't. MongoDB is a dog, and I know this because I run hundreds of instances of it in a production environment. I need to use 10x as many hosts as I should to support less than 30K queries per second.

The second I can migrate to another data store, I will. Unfortunately that kind of refactor isn't possible right now, but all new projects are using different tools.

Re: Cassandra vs MongoDB For Time Series Data

#59

Post by nasalgoat »

MichaelGG wrote: post #49
francesca wrote: post #32

Earlier quoted context omitted.

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

That's what we do - dozens of databases, containing one collection.

It's perverse.

Re: Cassandra vs MongoDB For Time Series Data

#60

Post by nasalgoat »

VintageCool wrote: post #47
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…

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!

Post reply on HN