Previously in this series: Reading about Serializeable Snapshot Isolation.

Last week I took a deep dive into articles on Serializeable Snapshot Isolation. It ended on a sad note, as I learned that to extended SSI to a sharded database using 2PC for distributed transactions1 , there is a need to persist - which means replicate - all read sets in addition to all writes.

This conclusion has been bothering me, so before diving into other papers on distributed serializeable transactions, I wanted to understand better what exactly happens in SSI when a node (shard) fails. This blog doesn't introduce any new papers, just more details. And more speculation.

• 1for example, MongoDB

Previously in this series: Toward strict consistency in distributed databases.

Apparently, when Snapshot Isolation was invented, it was received with great enthusiasm, since it avoids all the anomalies familiar from the SQL standard. It was only as time went by that people discovered that SI had some completely new anomalies and therefore wasn't equivalent to serializeable isolation. (This I learned from the PostgreSQL paper below.)

July is vacation time in Finland. Which means it is a great time to read blogs and papers on consistency in distributed databases! This and following blogs are my reading notes and thoughts. Mostly for my own benefit but if you benefit too, that's great. Note also that my ambition is not to appear like an authority on consistency. I just write down questions I had and things I learned. If you have comments, feel free to write some below. That's part of the point of blogging this!

The CAP theorem was published in (party like it's...) 1999: Fox Armando, Brewer Eric A: Harvest, Yield, and Scalable Tolerant Systems.

Since its publication it has provided a beacon and rallying cry around which web scale distributed databases could be built and debated. It(s interpretation) has also evolved. Quite quickly the original 1999 formulation was abandoned, and from there it has further eroded as real world database implementations have provided ever more finer grained trade offs for navigating the space that - after all - was correctly mapped out by the CAP theorem.

Pick ANY two? Really?

I was recently invited to speak at Fwdays Highload in Kyiv. This was my first ever visit to Ukraine, so I was excited to go and visit this large and beautiful European capital. Over a thousand years ago Vikings would row their boats through the rivers in Russia, and take the Dniepr southward to Kyiv and ultimately Turkey. It was exciting to travel in the footsteps of my forefathers.

My talk isn't really MongoDB specific, rather about an EC2 performance tuning project we did in 2017:

I have released impress.js v1.0. Impress.js is a framework for creating awesome 3D presentations with standard HTML5 and CSS. (Similar to Prezi + 3D and open source.)

From the release notes:

• New plugin based architecture allows adding more features without bloating core src/impress.js file
• Source files are in src/ and compiled into js/impress.js with npm run build. End users should continue to use js/impress.js as before.
• 19 new plugins
• Integrates impressConsole.js by default (press 'P' to open speaker console)
• Markdown support for those that are too much in a hurry to type HTML

A common and IMO cool way to create impress.js presentations, is to use some large background image for the entire presentation, then layout each slide over it. One of my first impress.js presentation was Selling Open Source 101 for Oscon 101. The presentation is inside a picture of a woman selling all kinds of stuff in a bazaar.

Next week I will present something about EC2 at HighLoad++ conference, and my presentation is flying over some clouds, of course.

It's been almost a year since my last update on features I've added to the impress.js presentation framework. Already a year ago I had pretty much merged or implemented all of the open backlog for the project. But at the end of the post I still listed two popular requests I hadn't implemented: Support sub-steps and 2D navigation.