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

Almost every Cassandra feature has some surprising behavior

blog.parsely.com

Post reply on HN
Print view View original

71–79 of 79 posts

Re: Almost every Cassandra feature has some surprising behavior

#71

Post by dang »

chisleu wrote: post #10

"We were actually hoping that Cassandra could store things more compactly than our raw data" Why in hell would you think that? CQL is not SQL? No shit. Actually, the docs pretty clearly spell that out. Anyone with even a cursory knowledge of Cassandra or any big data store would know you need to understand how the system works, and what it's limitations are before you model your data for the system. COMPACT STORAGE i…

Hey, it sounds like you know quite a bit about this topic, and passion for technical matters is something everyone here understands. But please follow the HN guidelines when commenting. It takes some effort, but it's effort we all need to make.

https://news.ycombinator.com/newsguidelines.html

Re: Almost every Cassandra feature has some surprising behavior

#72

Post by nemothekid »

pixelmonkey wrote: post #64
nemothekid wrote: post #46

Earlier quoted context omitted.

The GP is right, I started using Cassandra right before they got a hardon for "CQL" and the docs used to explicitly layout the data model when using the thrift interface. (The Thrift data model is basically what you get when you use COMPACT STORAGE, we still using CQL). Simply put, I bet the 30x increase in performance is not because they used COMPACT STORAGE, and is because Map/collections have terrible performance,…

You said: "they should have defined their schema upfront". We tried. It was not only less disk efficient, but also slower for queries. Wasn't the result we expected, but alas.

If thats the case, then thats something you should have highlighted that as well. Now that I think about it we decided to store blobs under one column using msgpack for a similar reason (although mine was "we had mongo eat up all our disk space because of field names, so now our code is littered with single character field names"). I've thought about fixing it, but if its the case I guess thats related to CASSANDRA-4175. The map solution makes it come across you weren't quite sure what you were doing.

However, I'm even more surprised at the "slower for queries" part. Maybe I'll do some tests with COMPACT STORAGE.

Re: Almost every Cassandra feature has some surprising behavior

#73

Post by Tloewald »

amelius wrote: post #66
Tloewald wrote: post #49

The thing about encoding multiple fields within a cell using \x01 somewhat bugs me -- not because it's a hack but because it's yet another example of needless reinvention of wheels. Good old ASCII has characters specifically devoted to separating fields, keys, etc. that no-one uses for anything else. Why not use them instead of inventing a new character that does the same thing? (By the same token, there was never an…

> Why not use them instead of inventing a new character that does the same thing? Perhaps because the fields could also be using these same characters internally?

How much would you care to wager?

Re: Almost every Cassandra feature has some surprising behavior

#74

Post by Tloewald »

delluminatus wrote: post #61
Tloewald wrote: post #49

The thing about encoding multiple fields within a cell using \x01 somewhat bugs me -- not because it's a hack but because it's yet another example of needless reinvention of wheels. Good old ASCII has characters specifically devoted to separating fields, keys, etc. that no-one uses for anything else. Why not use them instead of inventing a new character that does the same thing? (By the same token, there was never an…

I only found out about these recently because my company uses them in their custom RPC protocol, which was created about 15 years ago I think. IMO, there are ups and downs to using unprintable characters in your protocol. On one hand, yeah, you don't need to worry about someone putting a tab in a TSV field and messing up the format. On the other hand, it can make debugging a lot harder because what you see isn't nece…

You can make a case for CSV because it's text editor friendly, and tabs because it conceptually maps to typewriters, but we don't even have the option to use these characters. And arguing that typing escape sequences to represent common characters is better is pretty difficult to swallow.

Re: Almost every Cassandra feature has some surprising behavior

#75

Post by pixelmonkey »

nemothekid wrote: post #72
pixelmonkey wrote: post #64

Earlier quoted context omitted.

You said: "they should have defined their schema upfront". We tried. It was not only less disk efficient, but also slower for queries. Wasn't the result we expected, but alas.

If thats the case, then thats something you should have highlighted that as well. Now that I think about it we decided to store blobs under one column using msgpack for a similar reason (although mine was "we had mongo eat up all our disk space because of field names, so now our code is littered with single character field names"). I've thought about fixing it, but if its the case I guess thats related to CASSANDRA-4…

Might be specific to the Python driver, but it was slower for queries because most of the cputime was being spent decoding column structure/metadata and on type conversions. We also tested msgpack blobs, iirc, but the xsv format was the winner for query perf and for compactness on disk.

Would have gladly gone into more detail, but at 4,000+ words for the blog post already... :)

Re: Almost every Cassandra feature has some surprising behavior

#76

Post by skorgu »

rohansingh wrote: post #43
hobofan wrote: post #31

We used C* for a similar use case and encountered some of the same issues. The article doesn't even mention that there are a lot of places in the docs where it says: "If you configure a keyspace like this, your node will most likely crash". Not just degraded performance, any develeoper with some access might crash a node (and maybe the whole cluster) with a userspace error. The main lesson I took away from Cassandra…

> The main lesson I took away from Cassandra is that battle-tested@Netflix(/other bigcorp) doesn't mean resilient and might require a engineer on standby at all times to run correctly. This is entirely true. We are big users/consumers/fans of Cassandra at Spotify. We have approximately one crap-ton of Cassandra clusters with several metric crap-tons of data. But we have an entire team that provides support and toolin…

What would you use?

Re: Almost every Cassandra feature has some surprising behavior

#78

Post by rohansingh »

skorgu wrote: post #76
rohansingh wrote: post #43

Earlier quoted context omitted.

> The main lesson I took away from Cassandra is that battle-tested@Netflix(/other bigcorp) doesn't mean resilient and might require a engineer on standby at all times to run correctly. This is entirely true. We are big users/consumers/fans of Cassandra at Spotify. We have approximately one crap-ton of Cassandra clusters with several metric crap-tons of data. But we have an entire team that provides support and toolin…

What would you use?

Really depends on what the startup was. If it's a big data startup, then I'd put a lot of thought into based on the type of problem. If we were just building an app that needed some kind of data store, who knows, might even use something like Parse.

No need to prematurely optimize as long as you set yourself up to prevent lock-in.

Re: Almost every Cassandra feature has some surprising behavior

#79

Post by nemothekid »

pixelmonkey wrote: post #75
nemothekid wrote: post #72

Earlier quoted context omitted.

If thats the case, then thats something you should have highlighted that as well. Now that I think about it we decided to store blobs under one column using msgpack for a similar reason (although mine was "we had mongo eat up all our disk space because of field names, so now our code is littered with single character field names"). I've thought about fixing it, but if its the case I guess thats related to CASSANDRA-4…

Might be specific to the Python driver, but it was slower for queries because most of the cputime was being spent decoding column structure/metadata and on type conversions. We also tested msgpack blobs, iirc, but the xsv format was the winner for query perf and for compactness on disk. Would have gladly gone into more detail, but at 4,000+ words for the blog post already... :)

Hmm, so I tried converting a table we had from a standard table to one with COMPACT STORAGE. The space saving wasn't all that great (100GB -> 80GB), not near 30x.

I stand by my point that the mistake was using CQL maps when you should have just used a defined schema.

Post reply on HN