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

The road to ACID transactions in Cassandra 6

theconsensus.dev

Post reply on HN
Print view View original

11–20 of 26 posts

Re: The road to ACID transactions in Cassandra 6

#11

Post by kev009 »

361994752 wrote: post #8
kev009 wrote: post #7

Earlier quoted context omitted.

Wasn't ScyllaDB designed to be a drop in? The idea of running a Java or Golang DB sounds like fresh hell to me.

Why is java bad here...? Because of GC?

Directly and indirectly, there are a lot of other knock on effects. Value objects (only recently being added) help. You could treat it similar to an HFT application, having ephemeral workers that don't do GC and dies on heap exhaustion, with a NIO coordinator that tries to avoid all garbage creation. But why at this point, square peg round hole.

Re: The road to ACID transactions in Cassandra 6

#12

Post by kapperchino »

kev009 wrote: post #7
javier2 wrote: post #6

Earlier quoted context omitted.

I also run a large-ish cassandra cluster, and I dont really disagree, but then what else? I would not recommend starting new projects with it either, but what else will you use?

Wasn't ScyllaDB designed to be a drop in? The idea of running a Java or Golang DB sounds like fresh hell to me.

Issue is that it’s no longer open source

Re: The road to ACID transactions in Cassandra 6

#13

Post by farazbabar »

I see a few comments talking about the pain cassandra inflicts on ops, and that's fine, I agree with almost all of them. What the comments assume readers to know and understand is the absolute horror of foot guns, backup nightmares, data loss scenarios with seemingly safe choices around quorum and of course the performance purgatory lined with tombstones. Honestly, your workload is not big enough for postgres, trust me. It is like trying to do word count on a 5 TB file with flink, can you? should you though?

Re: The road to ACID transactions in Cassandra 6

#14

Post by cyberpunk »

rajman187 wrote: post #9
heipei wrote: post #4

Earlier quoted context omitted.

So what is the alternative? It took me a while to get around the data schema / modelling that a database like Cassandra imposed, but when it finally clicked it really clicked for me, so much so that I wish I could have the same performance footprint of consistent hashing / sharding with other databases. We are using ScyllaDB, but since they discontinued their Open Source version we're stuck on the last supported vers…

i'd say 99% of usecases will be served fine with Postgres, or a managed instance via AWS

We live in wildly different worlds, I think. How is postgres comparable to 6-12 nodes of cassandra? One really giant one with 200k worth of storage? Is there even a multi-master setup yet? every time i’ve looked it’s just around the corner. multigres from supabase seems promising, but im not touching it for at least a couple years…

I’d love to use postgres, and have in various times in the past and love it (it never broke) — but one machine isn’t nearly big enough for really any of my current applications.

Re: The road to ACID transactions in Cassandra 6

#15

Post by cyberpunk »

farazbabar wrote: post #13

I see a few comments talking about the pain cassandra inflicts on ops, and that's fine, I agree with almost all of them. What the comments assume readers to know and understand is the absolute horror of foot guns, backup nightmares, data loss scenarios with seemingly safe choices around quorum and of course the performance purgatory lined with tombstones. Honestly, your workload is not big enough for postgres, trust…

Yep, the pain is real. We don’t mention sstableloader in polite company. Add in kubernetes and getting your rf/racdc.properties right in a 3 az cluster so everything doesn’t just die on a netsplit with local_quorum (harder than it sounds) the joys of the ‘repair’ cronjob, backups, and commitlogs only occasionally not corrupting to the point the 8th out of the 15 nodes in your kube sts can’t restart after a bad exit() (e.g during worker upgrades —- good luck with this one!) …. yeah. hate.

Postgres isn’t the answer for my workload tho we really tried, i even wrote custom sharding for our postgres and it couldn’t handle the writes the cassandra setup shrugs off, but for sure this isn’t a ‘normal’ requirement most applications have.

Re: The road to ACID transactions in Cassandra 6

#16

Post by cyberpunk »

javier2 wrote: post #6
cyberpunk wrote: post #3

I'm sure for some workloads, cassandra is 'ideal' or at least was 10 years ago. What I can say though (as someone running thousands of cpus worth of cassandra at the moment); is that I deeply dislike this database. It's an operational nightmare, and I will not miss it even the slightest bit if it goes away forever. On the other hand, I'm sure glad to see a bit of life in cassandra dev, it seems to have been dormant f…

I also run a large-ish cassandra cluster, and I dont really disagree, but then what else? I would not recommend starting new projects with it either, but what else will you use?

These days if i need to scale sideways — mongo. I shifted most of the work my db was doing into my apps, and it’s… fine? It requires a different architecture tho for sure and has its own problems, but I’ll take those over the pain of cassandra gladly.

Re: The road to ACID transactions in Cassandra 6

#17

Post by isignal »

cyberpunk wrote: post #14
rajman187 wrote: post #9

Earlier quoted context omitted.

i'd say 99% of usecases will be served fine with Postgres, or a managed instance via AWS

We live in wildly different worlds, I think. How is postgres comparable to 6-12 nodes of cassandra? One really giant one with 200k worth of storage? Is there even a multi-master setup yet? every time i’ve looked it’s just around the corner. multigres from supabase seems promising, but im not touching it for at least a couple years… I’d love to use postgres, and have in various times in the past and love it (it never…

You can use a distributed database like yugabytedb or crdb. They are horizontally scalable, support postgres (yugabytedb has much better postgres compatibility). Yugabytedb also supports the Cassandra API.

Re: The road to ACID transactions in Cassandra 6

#18

Post by andriy_koval »

isignal wrote: post #17
cyberpunk wrote: post #14

Earlier quoted context omitted.

We live in wildly different worlds, I think. How is postgres comparable to 6-12 nodes of cassandra? One really giant one with 200k worth of storage? Is there even a multi-master setup yet? every time i’ve looked it’s just around the corner. multigres from supabase seems promising, but im not touching it for at least a couple years… I’d love to use postgres, and have in various times in the past and love it (it never…

You can use a distributed database like yugabytedb or crdb. They are horizontally scalable, support postgres (yugabytedb has much better postgres compatibility). Yugabytedb also supports the Cassandra API.

cocroach is also open source no anymore.

ydb is not clear if easier to maintain at scale.

Re: The road to ACID transactions in Cassandra 6

#19

Post by andriy_koval »

heipei wrote: post #4
cyberpunk wrote: post #3

I'm sure for some workloads, cassandra is 'ideal' or at least was 10 years ago. What I can say though (as someone running thousands of cpus worth of cassandra at the moment); is that I deeply dislike this database. It's an operational nightmare, and I will not miss it even the slightest bit if it goes away forever. On the other hand, I'm sure glad to see a bit of life in cassandra dev, it seems to have been dormant f…

So what is the alternative? It took me a while to get around the data schema / modelling that a database like Cassandra imposed, but when it finally clicked it really clicked for me, so much so that I wish I could have the same performance footprint of consistent hashing / sharding with other databases. We are using ScyllaDB, but since they discontinued their Open Source version we're stuck on the last supported vers…

> We are using ScyllaDB, but since they discontinued their Open Source version we're stuck on the last supported version

Do you think you are missing anything by being on scylla oss?

Re: The road to ACID transactions in Cassandra 6

#20

Post by misiek08 »

andriy_koval wrote: post #19
heipei wrote: post #4

Earlier quoted context omitted.

So what is the alternative? It took me a while to get around the data schema / modelling that a database like Cassandra imposed, but when it finally clicked it really clicked for me, so much so that I wish I could have the same performance footprint of consistent hashing / sharding with other databases. We are using ScyllaDB, but since they discontinued their Open Source version we're stuck on the last supported vers…

> We are using ScyllaDB, but since they discontinued their Open Source version we're stuck on the last supported version Do you think you are missing anything by being on scylla oss?

Second that question not only to OP/GP. Comparing Scylla and Cassandra - the choice is obvious, but current offering is a complete no-go.

Also Mongo is catching up in the use case we have and it’s even more scary. We are all the time at the exact edge of Mongo scalability and I’m talking about very good, few-years-invested-in setup on NMVe that is really delicate…

Post reply on HN