views
Henry Robinson Profile picture
Dec 11, 2017 10 tweets 2 min read Read on X
Ok, perhaps let's pump the brakes for a second. Systems and database engineering isn't dead; this paper didn't just replace Postgres with a GPU and a copy of the deep learning book. (1/n)

arxiv-vanity.com/papers/1712.01…
I mean, what's been done here is fascinating (partly in its simplicity). Replacing B-Trees - which are functions from keys to ranges on disks - with a learned function is kind of cool.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Henry Robinson

Henry Robinson Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @HenryR

Sep 17, 2020
A few things I think were done right in that Snowflake paper in 2016 (reporting on 4-year old work!):

1. They got the ergonomics of the cloud early (for the space). Elasticity is a core feature. Storage is no longer a 'you' problem. Cost is compute-as-you go.
2. They had ACID out-of-the-box. This was a huge step forward over the state-of-the-art MPP analytical engines. It helps to have some of the best database engineers in the world on your founding team.
3. They understood that SaaS was the right model and weren't constrained trying to build a solution that worked well for on-prem, unmanaged cloud and managed cloud customers (subtweeting myself of five-plus years ago).
Read 8 tweets
Apr 22, 2019
Buried in the "deploy on Friday!!" argument is an interesting generalisation of 'crash-only' software; the idea that you should design features to fail *fast* so that you can detect and react close to deploy time.

I don't think this is actually possible in the general case.
Infrastructure software can go wrong sloooowwwwly, in ways that are triggered only by prod traffic. Wiithout any data, I suggest that for this class of bugs maybe 80% of them could be caught within three days, whereas only 30% of them might show up in the first 8-10 hours.
That's not a systematic problem, so much as it's endemic to software that manages resources. Not deploying on Friday just means that you want to keep your expected number of weekend bugs below a minimum, because weekends are _different_, which seems fine to me.
Read 4 tweets
Feb 9, 2019
This turned into a great discussion. I was looking for resources I could give to someone designing their first few systems; advice and suggestions about how to structure their thoughts, critique their designs, and iterate.

Some of the highlights below.

Several people mentioned the, new to me, discipline of Non-Abstract Large System Design as practiced at Google.

Is it possible?
Can we do better?

Then

Is it feasible?
Is it resilient?

landing.google.com/sre/workbook/c…

(Say what you want about how Google sometimes acts like they've solved all of engineering, at least it's an ethos.)
Read 8 tweets
Oct 20, 2017
Great questions! Let me see if I can answer without making a hash of things. See thread below.
1. For CAP, we're considering only one object. In that case, serializability is a weaker property than linearizability (Not 'real-time').
2. 'Strict serializability', for one object, is the same as linearizability.
Read 7 tweets
Feb 14, 2017
0. Just a reminder for anyone seeing claims that Cloud Spanner beats the CAP theorem:
1. CAP has always said only one thing: that there is always a particular network failure that forces you to give up either C or A.
2. It has nothing at all to do with how likely that failure mode is. The failure is system-specific.
Read 10 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(