"Transactions: myths, surprises and opportunities" by Martin Kleppmann
Strange Loop Conference2 HN recommenders · 2018–2023
84K views · talk · evergreen · Uploaded 2015-09-27
Martin Kleppmann's Strange Loop talk on database transactions, covering why they were dropped by NoSQL, their reputation for being slow, and newer algorithms that make serializable transactions perform and scale. It touches on consistency, linearizability and the CAP theorem.
Recommended as a compact preview of Kleppmann's data systems material, including from his book on the subject.
42:03The Soul of Erlang and Elixir • Sasa Juric • GOTO 2019
GOTO Conferences
40:20"Testing Distributed Systems w/ Deterministic Simulation" by Will Wilson
Strange Loop Conference
31:44The Value of Values with Rich Hickey
InfoQ
59:56AWS re:Invent 2018: Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB (DAT401)
Amazon Web Services
49:15Erlang Factory 2014 - That's 'Billion' with a 'B': Scaling to the Next Level at WhatsApp
Erlang Solutions
47:43"Turning the database inside out with Apache Samza" by Martin Kleppmann
Strange Loop Conference
1:02:50The Language of the System - Rich Hickey
ClojureTV
51:27Google I/O 2012 - Go Concurrency Patterns
Google for Developers
4 comments from Hacker News
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" [VIDEO] Simon Brown - "software architecture vs code" [LINK]
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: [VIDEO] This is just about a little part of one of the chapters.
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] [VIDEO]
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., [VIDEO]