Skip to content
0:00 / 0:00

#acid#transactions#serializability

"Transactions: myths, surprises and opportunities" by Martin Kleppmann

Strange Loop Conference

88K subscribers • 114 videos on Hallway • Conference channel

YouTube
  • Recommended by 3 people: 2 on Hacker News and 1 curated list.
  • Presented by Martin Kleppmann, researcher and author

Intermediate. Assumes working knowledge.

84K views11 years ago3 recommendations

Databases and dataDistributed systemsDatabase internalsConsensus: Raft and PaxosReplication and consistency

Martin Kleppmann explains the history, myths, and modern performance of database transactions, weak isolation levels, and distributed consistency.

Back in the 1970s, the earliest databases had transactions. Then NoSQL abolished them. And now, perhaps, they are making a comeback... but reinvented. The purpose of transactions is to make application code simpler, by reducing the amount of failure handling you need to do yourself. However, they have also gained a reputation for being slow and unscalable. With the traditional implementation of serializability (2-phase locking), that reputation was somewhat deserved. In the last few years, there has been a resurgence of interest in transaction algorithms that perform well and scale well. This talk answers some of the biggest questions about the bright new landscape of transactions: What does ACID actually mean? What race conditions can you get with weak isolation (such as "read committed" and "repeatable read"), and how does this affect your application? What are the strongest guarantees we can achieve, while maintaining high availability and high performance at scale? How do the new generation of algorithms for distributed, highly-available transactions work? Linearizability, session guarantees, "consistency" and the much-misunderstood CAP theorem -- what's really going on here? When you move beyond a single database, e.g. doing stream processing, what are your options for maintaining transactional guarantees? Martin Kleppmann @martinkl Martin Kleppmann is a software engineer and entrepreneur, and author of the O'Reilly book Designing Data-Intensive Applications (dataintensive.net), which analyses the data infrastructure and architecture used by internet companies. He previously co-founded a startup, Rapportive, which was acquired by LinkedIn in 2012. He is a committer on Apache Samza, and his technical blog is at martin.kleppmann.com.

Why it's here

3 people recommend this

What people say. Frequently recommended as an exceptionally clear and deep explanation of database transactions, isolation levels, and consistency guarantees.

programming-talkscurated list on GitHubRecommends

Under “Databases”

Transactions: myths, surprises and opportunities 00:41:07 by **Martin Kleppmann** (2015)

geksillaon Hacker News • Recommends

On “Ask HN: What is your favourite tech talk?”

Rich Hickey - "simple made easy" link Rob Pike - "concurrency is not parallelism" link Uncle Bob Martin - "future of programming" link Martin Kleppmann - "transactions: myths, surprises and opportunities" link to this video Simon Brown - "software architecture vs code" link

redismanon Hacker News • Recommends

On “Ask HN: What overlooked class of tools should a self-taught programmer look into”

It's great. Incredibly dense with useful information and it just blows my mind how much knowledge Martin has about the topic. I recommend watching this talk from him to give a little glimpse of the book: link to this video This is just about a little part of one of the chapters.

u/rotuamiin r/ProgrammingLanguages • Mentions

On “Not sharing data at all?”

The point of immutability is that, because nobody can modify the object, you *can't tell* if an object is shared, so it's safe to do so. I want to also highlight some other very cool ways to safely share data: 1. Transactions. If your system takes snapshots and can undo changes to make things look consistent, then sharing isn't as dangerous. Note this can get subtle, and I highly recommend watching the talk "Transactions: myths, surprises and opportunities" by Martin Kleppmann for some inspiration on the matter. 2. Purely functional data structures. These are objects that are immutable, but exploit shared structure. 3. CRDTs (Conflict-free replicated data types). These are objects whic…

vvernon Hacker News • Mentions

On “Kafka Is Not a Database”

I mean, I hear you that people do that and it does allow you to avoid needing distributed transactions. When you're stuck with an underlying NoSQL database without transactions, this is the best thing you can do. This is the whole "invert the database" idea that ends up with 1. I'm arguing that that usage pattern was painful and that if you can have horizontally scalable transaction processing and a stream of events due to committed transactions downstream, you can use that to power correct and easy to reason about materializations as well as asynchronous task processing. Transact to change state. React to state changes. Prosper. 1 link to this video

gexahaon Hacker News • Mentions

On “UC Berkeley researchers set new visions for making CRDT data stores practical [pdf]”

jepsen.io has a neat diagram of various consistency models - link also, you can find talks of Martin Kleppmann on youtube about consistency guarantees, e. g., link to this video

u/rotuamiin r/ProgrammingLanguages • Mentions

On “Flogram: How should including other objects work?”

…wait for a response, so it requires synchronization. For the record, it seems Smalltalk generally dodges synchronization questions by only having a single execution thread. The problem of having multiple actors interface with a common resource is essentially database consistency. I love this talk, which made me really appreciate how thorny it is link to this video Edit: we could also try to take cues from how nature handles consistency. In the case of relativity, it’s by strong encapsulation (you can’t be causally related with anything outside your light cone) and in quantum physics, it’s by cheating (entanglement and nonlocal reality)! I love thinking about this though admittedly it’s getting into…