leg

Anywhere Cache shines in front of a multi-regional bucket. Once the data is cached, there's no egress charges and there's much better latency. This is great for someone who looks for spot compute capacity to run computations anywhere in the multi-region. It will also improve performance in front of regional buckets but as a cache, you'll see the difference between hits and misses.

Rapid Storage will have all of your data local and fast, including writes. It also adds the ability to have fast durable appends, which is something you can't get from the standard buckets.

Anywhere Cache and Rapid Storage share some infrastructure inside of GCS and both are good solutions for improving GCS performance, but Anywhere Cache is an SSD cache in front of the normal buckets while Rapid Storage is a new type of bucket.

(I work on Google storage)

There's a detailed blog post about Rapid Storage now available, see https://news.ycombinator.com/item?id=43645309

(I work on Google storage)

I've played 100s of hours of if under Proton on Linux. Works great.

Many enterprise storage systems have the durability/availability tradeoff like these replicated disks when replicating outside of a single datacenter. (Oracle calls it "max availability": try to synchronously replicate, but if the remote side is offline, allow transactions to commit.) Real world banks run on these sorts of systems.

Users don't continuously check replication status. They rely on it being synchronous almost all the time.

3 way quorum replication is great, but you then need to send to more data centers, potentially affecting performance. There's a tradeoff.

(I work on GCP storage)

Regional Persistent Disk was in beta in 2019. Usability hiccups and other annoyances meant it only GA'd in 2023, but it's been used under CloudSQL for quite a while.

(I work on GCP storage)

std::quick_exit() also works, though you can decide if it's worthwhile to allow parts of the program to register functions to be called at quick exit time.

Linked investment account counts. You just need $2500 in a checking account, the rest can be in whatever ETF or stock you'd like.

It is true that Borgmon readability went away due to this video. It wasn't Sergey, it was an eng director.

Yeah, John is great. His Unicode handling in Cyrus was way ahead of it's time.

I left CMU & the project 14 years ago. It's nice to know that some code lives on.

etcd didn't implement leases; it just assumed that the last Raft election was still good.

You can elect a leader for a set period of time (say, 10 seconds) and serve strong reads for a lesser period of time (5 seconds) if you have reasonable assumptions of how good your local oscillators work and avoid jumps. If you don't trust your local clock to any level of accuracy, why do you trust your local CPU?

Cockroach DB does this correctly. https://github.com/cockroachdb/cockroach/blob/master/docs/de...

The performance penalty is on reads. If you elect a leader with a timeout you can do strong reads without re-establishing consensus.

Except that state and local governments are mostly more corrupt, more poorly run, and less well supervised by the voters.