Pat Helland

@reubenbond @jorandirkgreef @jangray It will be great to get to know you! I'm looking forward to HPTS. Since it runs every two years, it's only my 20th time attending. :-)

@jorandirkgreef @jangray @PatHelland Would you say "Immutability Changes Everything" changed everything? 😁I look forward to seeing you & Pat at HPTS - this will be the first time I'm attending

@jorandirkgreef @jangray Yeah... Some things never change. When it comes to me talking all the time, I'm IM-MUTE-ABLE.

@PatHelland @jangray Thank you @PatHelland, I am really looking forward to that! (And no-one has a better number plate than you!) Warm regards Joran

@jorandirkgreef @jangray I'm looking forward to talking to you @jorandirkgreef about this at HPTS! Thank you for your kind words. Warm regards Pat

“Immutability Changes Everything” by Pat was an influence in the design of TigerBeetle’s LSM-Forest storage engine: - Separate different key/value types into their own LSM-tree. - Eliminate overhead of length prefixes for many small key/values. - Trees obliviously approach performance of an append-only log, where keys are inserted chronologically, immutably.

@MarcJBrooker In high school, my nickname was "A-tella the Pun".

If you write a database or systems paper and make a great pun, please assume I appreciated it and it made my day better.

@LewisCTech Thank you for your kindness, @LewisCTech ! Indeed, an essential form of interaction across systems is what happens across trust boundaries. I started talking about that in 1999 even before SOA came along or the CIDR 2005 paper happened. See: pathelland.substack.com/s/autonomous-c… for more.

@PatHelland Love this conception. Distributed transactions are a violation of a services sovereign right to keep on truckin'.

Reading @PatHelland's "Data on the Outside versus Data on the Inside". I loved the idea as presented in the immutability paper, though I cowardly avoided this one because it said "Service Oriented Architecture" and I had SOAP flashbacks. But it's good. cidrdb.org/cidr2005/paper…

@MarcJBrooker Snapshot seems to be the practical choice. There may be something to be said for natural selection. It’s the most commonly used isolation model. I certainly didn’t anticipate that. Go figure…

@PatHelland Indeed, the view over time (both longer and shorter than the economical repartitioning time). Write-write edge graphs seem to be much less dense (and more likely to be disjoint) than read-write edge graphs. Good argument for snapshot :)

If we draw database rows as points, and add edges between rows that appear in the same transaction, the resulting graph is a great way to think about potential scalability. The more you can cut the graph up without crossing edges, the easier the workload is to scale.

@nevgeniev @sunbains @jorandirkgreef @conor_power23 Atomic units (on IBM mainframes) were LUW (Logical Unit of Work). Business operations (sometimes spanning weeks) are bigger concepts. end/

@nevgeniev @sunbains @jorandirkgreef @conor_power23 The word "transaction" has a convoluted history. In the 1970s, it pretty much meant a human interaction with an online system. These were not too common at the time and mostly used for high-end complex systems like airline reservations. 1/

Transactions were a pretty good idea

@sunbains @jorandirkgreef @conor_power23 Coping with longer times and distributed space is very interesting and challenging. Building based on classic transactions is a simplifying piece of the puzzle. There are still challenges, though! Lots of fun issues. end/

@sunbains @jorandirkgreef @conor_power23 Yeah... But all joking aside, classic DB transactions routinely end up being the building blocks underlying long running sagas, workflows, and more. Transactions "normally" apply to a single point in time (the commit time in the DB) and a single point in space (the DB). 1/

@halberenson @MarcJBrooker @Hippotas Naahh... You've been both tired and re-tired. You know LOTS about the subject... Be careful before you weigh in. It might be interesting to you. Danger!

Pat, please stop writing about this. It is going to force me to read it and think and I’m trying to be retired. So now I have to read the paper and Marc’s response and then make believe I know something about the topic and, like, weigh in. And unless you share some good scotch with me I just don’t know if it is worth it.

New blog post, with some thoughts one @PatHelland's Big Deal paper, and on the tradeoffs between serializability and snapshot isolation in scalable databases: brooker.co.za/blog/2024/01/2…

@reubenbond @MarcJBrooker Discussions of the tradeoffs between isolation levels and their importance to the app are interesting. Still, that's not the goal of my BIG DEAL paper. I picked one and tried to explore the asymptotic limits to scale. These debates are separate (and fun). :-) /end

@reubenbond @MarcJBrooker Isolation levels are COMPLEX for the application. Strengthen them and an existing app may break. Weaken them and an existing app may break. My "BIG DEAL" paper picked one and explored issues of asymptotic limits to scale. That was the goal! 1/

@MarcJBrooker Yup. Of course, I acknowledge that. Still, VAST numbers of apps use snapshot isolation for one (or both) of two reasons: - It's what they have available, - It scales better than serializability. My argument is that this IS what happens, not a judgement of goodness.

@PatHelland Part of what I was trying to say is that I think there are fewer *correctness* challenges for app developers on serializable, but it (perhaps counterintuitively) forces them to think a lot more about scalability (because they have to pay attention to read set size).

@MarcJBrooker Provoking discussion and debate (as well as new ideas) was my goal for the paper. Thank you for contributing to the discussion. As alway, "hat tip" to my friend! - Pat /end

@MarcJBrooker I would add is that a HUGE number of existing apps (perhaps more than half) use some variant of snapshot isolation. The BIG DEAL paper is about OLTP scale for OLTP, app implementation challenges. ARGUABLY, the value of scale for the dominant isolation is most important. 3/