Showing posts from January, 2022

Decoupled Transactions: Low Tail Latency Online Transactions Atop Jittery Servers (CIDR 2022)

This is a CIDR22 paper by Pat Helland. It is a long paper at 18 pages, followed by 12 pages of  appendix. Since he wrote such a long paper, I won't apologize for writing a long review. This is a Pat Helland paper, so it is full of Hellandisms. Pat's papers are always remarkable, distinct. There is a lot of wisdom in them. So, in case there could be any doubt about this, let me preface this review by saying that I learn a lot from Pat's papers, and I am grateful to Pat for teaching me and the community. Problem and scope Jitter refers to probabilistic response times, message latencies in networks. In big data processing systems it is easy to deal with jitter by retrying stragglers, in fact this has been suggested in the MapReduce paper. But the same approach does not apply to databases, where we don't have the same idempotency affordances. Databases should be transactionally correct! The paper presents a hypothetical design (meaning this is not implemented). The design

Clear communication

My cat is a great communicator. Today, just before noon, he meowed in front of my room. When I opened the door, he walked down the stairs till halfway, stopped, looked back at me, made eye contact, and meowed again. When I started following him, he passed the living room, stopped, looked back at me, meowed again, and waited for me to catch up. He then led me to the kitchen next to his feeder, and made me feed him. Many technical people forget this first rule of communication. Make sure your correspondent is following you. Make sure you connect with them strongly. My cat, Pasha, first made sure he connected with me and then communicated with me in a deep/visceral manner. He did this even without needing to use words.   How do you achieve this?  The first step is to take this as the objective. By dumping out one paragraph of content per minute to the other side, you don't achieve communication. You should stop, check the other side, confirm they are with you, before you carry on to

Reasons I hate conferences, and suggestions for fixing them

(This is about academic conferences, but I guess most of these also apply to industrial conferences.) It is too much cramming Attending a conference is like drinking from a firehose. After the first day, conferences become a drag. I can ponder about only so many papers/ideas, but in a conference they keep coming one after the other incessantly, not giving my soul a chance to catch up. I think what makes it worse is that there is too much context switching going on from one paper to another, and from one session to another. Focused workshops where the presentations/discussions revolve around the same topic work much better, as there is less context switching. I miss some of the self-stabilizing-systems workshops I had been to around 1999-2000. And also can we please have 2 hour long lunch breaks? At a self-stabilization workshop in Luminy, France, we had 3 hour long lunch breaks, and it made the workshop more productive. Networking is hard Conferences are hell for introverted people. T

Popular posts from this blog

Learning a technical subject

Foundational distributed systems papers

Learning about distributed systems: where to start?

Strict-serializability, but at what cost, for what purpose?

CockroachDB: The Resilient Geo-Distributed SQL Database

Amazon Aurora: Design Considerations + On Avoiding Distributed Consensus for I/Os, Commits, and Membership Changes

Anna: A Key-Value Store For Any Scale

Warp: Lightweight Multi-Key Transactions for Key-Value Stores

The Seattle Report on Database Research (2022)

Graviton2 and Graviton3