Hacker News Reader

Comment by Luker88 | Hacker News Reader

"write will fail"...but the data will still be there (you can SELECT it normally) and will be replicated to the node that was down once it is up again.

Unless the node was down too much and could not fully catch up before a set time (DB TTL if I remember correctly), in which case the data might be propagated or not, and old deleted data might come up again and be repropagated by a cluster repair.

So much fun to maintain

View on HN

I know this is HN and people love to troll, but it makes me sad when I see you using falsehoods to take a steaming dump on a group of engineers that are obsessed with building a database that can scale while maintaining the highest level of correctness possible. All in Open Source... for free! Spend some time on the Cassandra mailing list and you'll walk away feeling much differently. Instead of complaining, participate. Some examples of the project's obsession with quality and correctness:

https://cassandra.apache.org/_/blog/The-Path-to-Green-CI.htm...

https://cassandra.apache.org/_/blog/Finding-Bugs-in-Cassandr...

https://cassandra.apache.org/_/blog/Testing-Apache-Cassandra...

https://cassandra.apache.org/_/blog/Introducing-Apache-Cassa...

sorry to disappoint you but there is a reason Cassandra tried to add LWT using paxos.

it mostly work but it’s extremely slow and still have many bugs.

https://www.datastax.com/blog/lightweight-transactions-cassa...

That blog was posted 9 years ago. Needless to say, a lot of improvement and engineering has happened since then. The limited use cases of LWTs will soon be replaced with general, ACID transactions.

https://thenewstack.io/an-apache-cassandra-breakthrough-acid...

This new « accord » thing look very promising! If this get merged into Cassandra this change everything!

A prototype has been developed that has demonstrated its correctness against Jepsen.io’s Maelstrom tool

LWTs were added for a very simple reason: stronger isolation where the performance trade-off makes sense. Nothing to do with the GP comment.

Until recently they were indeed slow over the WAN, and they remain slow under heavy contention. They are now faster than peer features for WAN reads.

However, the claim that they have many bugs needs to be backed up. I just finished overhauling Paxos in Cassandra and it is now one of the most thoroughly tested distributed consensus implementations around.

LWT is still the only way to guarantee your write don’t random disappear and that conditional update are really conditional.

LWT still have awful performance compared to a write request with same guarantee in any other database.

> and old deleted data might come up again and be repropagated

That pretty much describes iCloud.

Argh! Zombies!

iCloud has terrible syncing. Here’s an example. Synced bookmarks in Safari:

I use three devices, regularly; my laptop (really a desktop, most of the time), my iPad (I’m on it, now), and my iPhone.

On any one of these devices, I may choose to “favorite” a page, and add it to a fairly extensive hierarchy of bookmarks, that I prefer to keep in a Bookmarks Bar.

Each folder can have a lot of bookmarks. Most are ones that I hardly ever need to use, and I generally access them via a search.

I like to keep the “active” ones at the top of the folder. This is especially important for my iPhone, which has an extremely limited screen (it’s an iPhone 13 Mini -Alas, poor Mini. I knew him well).

The damn bookmarks keep changing order. If I drag one to the top of the menu, I do that, because it’s the most important one, and I don’t want to scroll the screen.

The issue is that the order of bookmarks changes, between devices. In fact, I just noticed that a bookmark that I dragged to the top of one of my folders, yesterday, is now back down, several notches.

Don’t get me started on deleting contacts, or syncing Messages.

I assume that this is a symptom of DB dysfunction.

This is a symptom of DB dysfunction only if you are using just one device.

Otherwise it's far more likely to be faulty sync algorithm.

You can only SELECT at QUORUM if you are guaranteed to be able to SELECT it again at QUORUM, ie it must be durable (and the QUORUM read will ensure it if the prior write did not).

If you are selecting at ONE then yes, you can expect stale replies if you contact a different node. That is what the consistency level means; that just one node has seen the write.

At application level, you’ll probably retry, and you’ll probably select with the same cl you’ve written with.

The other behaviour you’re talking about is hinted handoff.

“So much fun to maintain” -> cassandra has very specific use cases. And hosted versions exist.

Disclosure: I work at Aiven, which has an hosted cassandra offer.

Reply on news.ycombinator.com