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

61–70 of 79 posts

Re: Almost every Cassandra feature has some surprising behavior

#61

Post by delluminatus »

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 necessarily what you get, and obviously it becomes harder to hand-write requests.

Of course, OP ended up using unprintable characters anyway, so I think they might as well use the ASCII ones. But even if you know about and use those characters, I think there is still a place for [CT]SV.

I'm glad you brought them up though, because I think the nonprintable ASCII characters occupy a very interesting place in computer science -- (almost) universally supported, but (almost) never used.

Re: Almost every Cassandra feature has some surprising behavior

#62

Post by serialpreneur »

I think you can sum up some of the grievances of the OP as "felt mislead by Cassandra/DataStax marketing". But, some of the criticism is not really the fault of Cassandra or DataStax at all IMO.

- CQL stands for Cassandra Query Language. As a user of C*, I don't remember anywhere in docs it claiming it conforming to the SQL standard. They do mention it to be "similar to SQL" which is a fair comparison.

As a counter-example of another somewhat similar database, AWS DynamoDB. The absence of a CQL like syntax really frustrates me.

- Data Modelling: Effective data modelling is difficult in all DB systems, inherently more so in NOSQL or non-ACID distributed DBs.

- Counters & Collections: I feel that criticism is legit. I felt similar pains too. I've learned the lesson there not to trust all marketing claims.

Re: Almost every Cassandra feature has some surprising behavior

#63

Post by gpvos »

nemothekid wrote: post #46
saurik wrote: post #7

Earlier quoted context omitted.

The one that is really irksome is the COMPACT STORAGE one, as it is explicitly disrecommended and deprecated by the Cassandra documentation. I have not yet gotten around to using Cassandra in any production environment, nor have I done any large-scale tests, and it has been a while since I delved deeply into the data model, but I remember looking at this part of the storage system and thinking it was "wrong", but won…

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

It wasn't 30x performance improvement; it was 30x less disk space used. Which is nontrivial at their scale.

Re: Almost every Cassandra feature has some surprising behavior

#64

Post by pixelmonkey »

nemothekid wrote: post #46
saurik wrote: post #7

Earlier quoted context omitted.

The one that is really irksome is the COMPACT STORAGE one, as it is explicitly disrecommended and deprecated by the Cassandra documentation. I have not yet gotten around to using Cassandra in any production environment, nor have I done any large-scale tests, and it has been a while since I delved deeply into the data model, but I remember looking at this part of the storage system and thinking it was "wrong", but won…

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.

Re: Almost every Cassandra feature has some surprising behavior

#65

Post by pixelmonkey »

IndianAstronaut wrote: post #57
pixelmonkey wrote: post #23

OP here. Surprised to find this article on the HN front page, a month after we originally posted it. Glad to answer questions. Ask me anything!

Are you using Cassandra for analysis? What is your analysis workflow like?

We use Cassandra for data grouping and ordering. Find our other blog post on "Mage", our time series engine, for more info.

Re: Almost every Cassandra feature has some surprising behavior

#66

Post by amelius »

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?

Re: Almost every Cassandra feature has some surprising behavior

#67

Post by baldfat »

samkone wrote: post #35
baldfat wrote: post #27

I still think of Cassandra as the tool the Digg engineers used to kill Digg as we all loved/hated it at it's time.

If a company blames its demise on a piece of tech, then they either need better engineers to change that tech. Or the product had no future at all. And Cassandra has changed a lot since then.

What I said still is true. Digg USED Cassandra to destroy itself. They changed business plans and removed the community with a ton of down time and a loss of data.

I agree it wasn't Tech fault for Kevin Rose allowing VCs to control Digg, but there were issues with Cassandra and especially during the SQL vs NoSQL debate at its highest levels.

Re: Almost every Cassandra feature has some surprising behavior

#69

Post by dvirsky »

chisleu wrote: post #38
dvirsky wrote: post #14

Earlier quoted context omitted.

We've moved most of our data to redis (which we were using way before cassandra), with a bit of classic MySQL for off-line data, and Redshift for analytics. Right now redis is not using cluster mode, but we'll switch to it eventually. It's a big move, but I find redis more predictable, and for our data sizes (10s of Gs), cheaper to maintain.

> We've moved most of our data to redis Redis is neet if your information fits in RAM, but that's not what Cassandra is for.

the dropping prices of RAM lead us to re-evaluate what we consider "data that fits in RAM". at 10Gs it's just more economic, and even if we go up one order of magnitude, the serving speed of redis still makes it economic for a lot of workloads.

Re: Almost every Cassandra feature has some surprising behavior

#70

Post by dvirsky »

fweespeech wrote: post #52
manishsharan wrote: post #20

Earlier quoted context omitted.

If you moved your data off Caasandra to Redis, I am going to assume you must be using a lot of Lua to maintain some relationships in data in Redis. How is the performance? I have been experimenting with Redis and my lua scripts are long and I have been wondering how they will fare under production level loads.

A Redis Hash is similar enough to Casandra's data structure I doubt they'd need that. row key = key column = field I know Lua is "an option" in Redis but I avoid it like the plague because under production loads, Redis hashes perform and are easy to maintain w/o Lua.

More or less this. Row = HASH key, sorted sets for secondary key indexing, and also for iterating primary key entries. I've built an abstraction layer on top of redis to automate all that and it works rather well.
Post reply on HN