684 karma · joined June 13, 2014
Yes, but probably not initially. The design supports them, it’s just not very pressing to implement since most users today use hash partitioners. There will be a lot of avenues in which to improve transactions after they are delivered and it is hard to predict what will get the investment when.
Proper global indexes are likely to follow on the heels of transactions, as they solve most of the problem. Though transactions being one-shot and needing to declare partition-keys upfront means there’s some optimistic concurrency control required. Interactive transactions supporting pessimistic concurrency and without needing to declare the involved keys will also hopefully follow, at which point indexes are very trivial, but the same caveat as above applies.
>It also has some, terribly slow, lightweight transactions
FWIW, LWTs are much (2x) faster in 4.1 (which has been very slowly making its way out the door for a while now... the project is mostly already more focused on 4.2, so pushing 4.1 out the door is tortuous for procedural reasons)
Since at least one of those nodes has the “newer” value, only one node can serve this “older” value
Cassandra does today inform you on timeout how many replicas have been successfully written to, if it was insufficient to reach the requested level of durability, which many years ago it did not. But this is no guarantee the write is durable, as this will represent a minority of nodes - and they may fail, or be partitioned from the remainder of the cluster. So the write remains in an unknown state until successfully read at QUORUM, much like a timeout during COMMIT for any database.
This would have been a valid criticism of LWW (and there are other more contrived examples), but I think (or hope) this is an explicit trade off made by anyone using Cassandra in eventual consistency mode. There are strategies to prevent this being a problem for workloads where it matters, some discussed elsewhere in the thread.
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.
If value 2 is newer than value 1, value 1 will never overwrite value 2. If a client reads value 2 at QUORUM then it will always be seen by all future queries.
Fundamentally every distributed protocol has a moment where it may have to tell the client it has abandoned the operation, but already has in flight messages to remote replicas that would result in a decision to complete the operation.
Before that operation is answered by the replicas, the operation is in an unknown state. It is fundamental. Some slower approaches to reaching decisions may mask this problem more often, but it is there whether you realise it or not.
Single partition only. Poorly named, sure. Feature-wise though pretty comparable to peer offerings. Fortunately general purpose transactions are coming next year.
> material views. Added, removed, readded, deprecated.
No; added, then marked experimental. Never removed or deprecated, though they may be superseded before long.
> error handling is asinine
Fundamental distributed systems problem that is just more apparent with eventual consistency. Failure does not have a certain outcome.
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.
Yes, if you mix consistency levels incorrectly you will do it wrong and maybe get stale data, but that is a different criticism. I agree that it is easy for unsophisticated users to incorrectly use consistency levels in complex topologies, and I hope we will introduce mechanisms to prevent users making such mistakes in future. But that was not your claim, and in my experience users do understand consistency levels just fine.
There are lots of valid criticisms to point at various use cases with Cassandra, but this was just incorrect.
This is all done for you by Cassandra
But, I will be pushing for the adoption of virtual threads once they become more useful for the community (which I think the previously mentioned improvements predicate). So, whatever the realities JEP425 operates within, I do hope these improvements land by Java 21, so that my job is made easier.
Either way, really excited about the work, whenever it transpires that we can use it. Thanks for your efforts delivering it so far.
A major project like Cassandra that is non-trivial to upgrade (but is desirable to upgrade, and to have security fixes for) simply cannot hop Java version every year and impose that additional burden on our users, and nor can we pick a Java version that is not guaranteed security updates past some near term horizon. So we pick versions that people are expected to have available them for the lifetime of that release in their environment.
Honestly I’m not sure what you’re upset about, I am a bit surprised at the vehemence of your response to that element of my comment. Also a little disappointed you didn’t engage with the rest of my comment; I hope that doesn’t mean I also end up disappointed with the near future of virtual threads.
As a member of the Cassandra community I’m super excited to get my hands on virtual threads come the next LTS (and Cassandra’s upgrade cycle), as it will permit us to solve many outstanding problems much more cheaply.
I hope by then we’ll also have facilities for controlling the scheduling of virtual threads on carrier threads. I would rather not wait another LTS cycle to be able to make proper use of them.
> Two weeks later, the mice were injected in the same area with 2.5 μg of mRNA-LNP coding for PR8 influenza hemagglutinin (HA)
What we do use helium for today are things like MRI machines that are medically invaluable, and we do so wastefully potentially denying future generations this technology.
Even if we eventually find alternatives, it may be inferior or we may otherwise deny them technological advantages of similar importance that would be more accessible through access to helium.
The problem is that today Helium is cheap enough we’re happy to boil an MRI machine’s worth off into space for a child’s birthday party.
Climate change is simply another face of the same coin of indifference to the costs we confer on others.
Apparently 8%. But all of these industries waste it unnecessarily, due to our failing to price in or consider the future scarcity.
Helium as a waste product of fusion reactors is such a pipe dream, and will produce such tiny volumes should that ever happen, that it is not a remotely realistic solution to the problem.
This is just one of the many resource limits we’re facing as a species, and this is how we address it today.
I believe appointments are now run more efficiently due to the backlog and changes in processes due to Covid, with the reason for an appointment usually submitted digitally first, followed by an efficient telephone consultation that is well prepared based on your submitted reason for needing an appointment, and a follow-up consultation as necessary. Perhaps your GP surgery in particular is struggling, or you are perhaps not engaging with the new approach.
I have been surprised at just how well functioning the health service is right now despite the incredible pressures on it, but perhaps my local area is coping better than others.
Importantly, however, this issue was broadly not present 10 years ago when the NHS was better funded to meet its needs, and was still cheaper than other countries. So the issue is not the NHS, but funding, which is also corroborated by our relatively low level of health spending.
https://en.wikipedia.org/wiki/List_of_countries_by_total_hea... https://www.ons.gov.uk/peoplepopulationandcommunity/healthan...
You do have overlapping cover, but the most expensive cover (GP, long term chronic conditions, emergency care) are provided by the NHS. It’s far from clear that you would pay less if you had to cover the whole through a private policy.