HNHacker News
TopNewBestAskShowJobs

_benedict

684 karma · joined June 13, 2014

submissionscomments
_benedict··on Made.com furniture website on brink of collapse
Swoon editions
_benedict··on Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB
Yes, Cassandra will still not be suitable for all workloads.
_benedict··on Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB
> when doing range scan query

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.

_benedict··on Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB
It will exist next year. Cassandra is getting HA ACID transactions (depending how you define C; we won't be getting foreign key constraints by then) that will be fast. Typically as fast (in latency terms) as a normal eventually consistent operation. Depending on the read/write balance and complexity, they may even result in a reduction in cluster resource utilisation. For many workloads there will be additional costs, but it remains to be discovered exactly how much. I hope it will be on that sort of scale.

>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)

_benedict··on Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB
No, it won’t. Successfully written does not mean what you think it means. If there is “newer” (by timestamp) data on disk or in memtable then it will not be returned to a client, regardless of which order that data arrived. It is unlikely even to be written to disk (except the commit log).

Since at least one of those nodes has the “newer” value, only one node can serve this “older” value

_benedict··on Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB
A timeout is pretty much always an unknown outcome. Cassandra does have dedicated exceptions for failed writes (which should have a certain outcome of not applied) but this is much rarer in practice.

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.

_benedict··on Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB
Client B’s write will only be successfully read from 1 of the nodes it wrote to, and read-repair only runs on QUORUM reads. So, no, it will not be possible to read value 2 for 5m - it will never be visible to operations at QUORUM.

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.

_benedict··on Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB
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.

_benedict··on Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB
No, that is literally impossible.

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.

_benedict··on Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB
They are not a different category. This is a distributed database, network errors and node failures are a fundamental part of its function.

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.

_benedict··on Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB
> LWTs

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.

_benedict··on Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB
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.

_benedict··on Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB
No, you wrote that you have to write and wait several minutes for data to replicate. This is straight-up false.

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.

_benedict··on Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB
Nothing bad? That’s the whole point of quorum reads and writes. You write to at least two, and read from at least two (one typically being a digest-only to corroborate the result).

This is all done for you by Cassandra

_benedict··on Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB
Your statement about data propagation in that linked comment is at least misleading. A write at quorum will always be visible instantly to a read at quorum.
_benedict··on Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB
I’m sure Scott’s talk went into detail about this, but I can safely say that his team contributes a great deal to Cassandra
_benedict··on Virtual Threads: New Foundations for High-Scale Java Applications
Well, whatever each of our perceptions about the utility of selecting an LTS, there are realities we all occupy - and LTS releases are a part of Cassandra's reality for the time being. Perhaps that will change in future, but I do not anticipate it very soon.

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.

_benedict··on Virtual Threads: New Foundations for High-Scale Java Applications
Well, it is not just Oracle that has adopted the LTS designations. AdoptOpenJDK and others are also selecting the same LTS versions to provide longer term support promises for, including security and other improvements.

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.

_benedict··on Virtual Threads: New Foundations for High-Scale Java Applications
Conversely, some applications would like a leaky abstraction they have some control over. Some caching will likely remain beneficial to link to a carrier thread.

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.

_benedict··on Pre-exposure to mRNA-LNP inhibits adaptive immune responses in mice
No, they then followed up with an influenza vaccine delivered by mRNA. This study assessed the relative quality of immune response in those that had previously received a sham vaccine delivered by LNP, or no prior vaccine (or LNP).

> Two weeks later, the mice were injected in the same area with 2.5 μg of mRNA-LNP coding for PR8 influenza hemagglutinin (HA)

_benedict··on Collapse of emergency healthcare in England may be costing 500 lives every week
Hmm, this seems to have been attached to the wrong parent comment, and I am now unable to delete it ¯\_(ツ)_/¯
_benedict··on Collapse of emergency healthcare in England may be costing 500 lives every week
I think perhaps their point is that, if some of the patients not discharged are consuming a nurse budget that isn’t required (because they are healthy and can be discharged), then this nurse budget could be redeployed to those waiting in admissions. Not sure how reasonable this is, I’m sure the hospitals will have thought of it themselves. But it does seem particularly silly to have the paramedics stuck in place and unable to serve anybody who may be even more critically ill.
_benedict··on I Choose Optimism
I’m really not sure what point you’re making. Where has anyone proposed a climate solution by using all of the world’s helium?

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.

_benedict··on I Choose Optimism
Who knows is exactly the problem. Hand waving this away for future generations to deal with is exactly the problem. If we can’t imagine how we’ll solve it, we should probably strive not to create the mess.
_benedict··on I Choose Optimism
https://www.helium-one.com/helium-market/

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.

_benedict··on I Choose Optimism
Millions of years of what? We have maybe a few hundred years of helium if we’re generous with our assumptions and we’re literally squirting that into balloons and letting it float away into the atmosphere and off into space. It’s literally an unrecoverable loss.

This is just one of the many resource limits we’re facing as a species, and this is how we address it today.

_benedict··on Silent crisis of soaring excess deaths in Britain is only tip of the iceberg
Your GP surgery is privately run, so in this case the issue is likely very much an issue of the supply of available doctors, and how your GP surgery chooses to operate its appointment system.

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.

_benedict··on Silent crisis of soaring excess deaths in Britain is only tip of the iceberg
The UK spends less per capita (PPP) than most other equivalent country's health system [1,2]? I never quite understand the "cost effective" arguments against the NHS. These costs include all of our private health care expenditure, which are surprisingly significant.

https://en.wikipedia.org/wiki/List_of_countries_by_total_hea... https://www.ons.gov.uk/peoplepopulationandcommunity/healthan...

_benedict··on Silent crisis of soaring excess deaths in Britain is only tip of the iceberg
The Independent is owned by Lebedev. It is part of the aforementioned oligarchy, literally.
_benedict··on Silent crisis of soaring excess deaths in Britain is only tip of the iceberg
You are not paying twice over. Your private insurance is dramatically cheaper than it would be if it covered everything covered by the NHS.

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.

← PreviousPage 4 of 11Next →