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

31–40 of 79 posts

Re: Almost every Cassandra feature has some surprising behavior

#31

Post by hobofan »

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 is that battle-tested@Netflix(/other bigcorp) doesn't mean resilient and might require a engineer on standby at all times to run correctly.

Re: Almost every Cassandra feature has some surprising behavior

#32

Post by samkone »

cassandranot wrote: post #26
dvirsky wrote: post #5

The thing is that contrary to many other tools, you can't run Cassandra with almost any of its default settings (maybe besides ports). In most tools you'll need to tweak a few defaults, with Cassandra you need to thoroughly read the docs on every little configuration in the server and schema definitions (especially if you're working in multiple DCs), you'll always find a little surprise if you skim through it. It's a…

We found cassandra to be too finicky and flakey and ended up using mongodb - simple to get going, admin, use and maintain. Cassandra was a huge pain in the ass, had to read all the source code just to get it running!

Here's laughing. I guess you chose convenience over performance or scalability, which is a valid choice. But We're running a 1000 Cassandra nodes to handle Millions of ops where mongo would simply require too much admin work. the whole clusters are managed by two guys. Mongo's simplicity comes at a cost at some point.

Re: Almost every Cassandra feature has some surprising behavior

#33

Post by samkone »

manishsharan wrote: post #19

Cassandra or most NoSQL databases seem to require a lot more internals knowledge than what a development or an ops team would have. Most sysops teams have a cadre of certified DBAs and administrators and they get on by without any surprises. The one thing Oracle got right was their certification program which ensures there are no gotchas -- most DBA can deliver smooth operations. I guess it is because these NOSQL pro…

Google doesn't offer a managed cassandra, rather a manager Bigtable with the HBase Api. But we run a huge Cassandra install in multi dacenters on GCP. And we're good. And yes it requires you to understand distributed storage systems, and the some of Cassandra internals.

Re: Almost every Cassandra feature has some surprising behavior

#34

Post by samkone »

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!

So are you still running Cassandra? And why rely on counters for analytics when it's wildly known to be a bad idea.

Re: Almost every Cassandra feature has some surprising behavior

#35

Post by samkone »

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.

Re: Almost every Cassandra feature has some surprising behavior

#36

Post by chisleu »

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…

Yeah we don't have that problem with MariaDB at all (joking.)

Bad users (read: developers) can break things. If you are worried about bad users, then put an api between users and the datastore to keep them from breaking things.

Re: Almost every Cassandra feature has some surprising behavior

#37

Post by robusto »

samkone wrote: post #32
cassandranot wrote: post #26

Earlier quoted context omitted.

We found cassandra to be too finicky and flakey and ended up using mongodb - simple to get going, admin, use and maintain. Cassandra was a huge pain in the ass, had to read all the source code just to get it running!

Here's laughing. I guess you chose convenience over performance or scalability, which is a valid choice. But We're running a 1000 Cassandra nodes to handle Millions of ops where mongo would simply require too much admin work. the whole clusters are managed by two guys. Mongo's simplicity comes at a cost at some point.

What are you using for managing those 1000 nodes? opscenter or something else?

Re: Almost every Cassandra feature has some surprising behavior

#38

Post by chisleu »

dvirsky wrote: post #14
frik wrote: post #11

Earlier quoted context omitted.

Given your experience: Have you considered a NewSQL db like MariaDB with one of its modern storage engines? Also Facebook moved from their Cassandra to Hadoop/Hive a long time ago (and the MySQL side was never touched).

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.

Re: Almost every Cassandra feature has some surprising behavior

#39

Post by chisleu »

arthursilva wrote: post #24

Bashing non-COMPACT storage is nonsense. non-COMPACT store by itself doesn't add any significant overhead (only 2 bytes per cell and even less after compressed). What really wastes space is using collections types. Even using that I doubt it will ever reach the 30x mark the author stated.

The article is full of nonsense and the OP is here so criticism is being downvoted.

Re: Almost every Cassandra feature has some surprising behavior

#40

Post by pixelmonkey »

samkone wrote: post #34
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!

So are you still running Cassandra? And why rely on counters for analytics when it's wildly known to be a bad idea.

We are still running Cassandra. It's used in a more restricted way than we originally thought we'd use it, but we're following the recommendations we wrote up in linked article.

We don't use counters -- at all. (This is discussed in one of the sections.) Counters are one of the few Cassandra features that can offer you some form of value aggregation inside the data store, but we decided they weren't worth it, due to the quirks.

What do you mean by, "when it's wildly known to be a bad idea?" What are you referencing? Lots of people use counters in Redis and MongoDB for analytics, for example.

Post reply on HN