{"id":56365,"date":"2020-02-11T00:00:00","date_gmt":"2020-02-10T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike"},"modified":"2020-02-18T14:04:37","modified_gmt":"2020-02-18T11:04:37","slug":"highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike","title":{"rendered":"HighLoad++, Mikhail Tyulenev (MongoDB): Causal consistency: from theory to practice","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

The next HighLoad++ conference will take place on April 6 and 7, 2020 in Saint Petersburg.
\nDetails and tickets at the link<\/a><\/noindex>. HighLoad++ Siberia 2019. Hall \"Krasnoyarsk\". June 25, 12:00. Theses and presentation<\/a><\/noindex>.<\/p>\n

\"HighLoad++,
\n
\nSometimes, practical requirements conflict with theory, where important aspects for a commercial product are not accounted for. This presentation outlines the process of selecting and combining various approaches to creating components of Causal consistency based on academic research while considering the requirements of a commercial product. Listeners will learn about existing theoretical approaches to logical clocks, dependency tracking, system security, clock synchronization, and why MongoDB opted for certain solutions.<\/a><\/noindex><\/p>\n

Mikhail Tyulenev (hereafter \u2013 MT):<\/b> \u2013 I will talk about Causal consistency \u2013 a feature we worked on at MongoDB. I work in the distributed systems group, and we developed it about two years ago.<\/p>\n

\"HighLoad++,
\n
\nIn the process, I had to delve into a considerable amount of academic research because this feature is quite well-studied. It turned out that no single paper fits what is required in production, a database due to the very specific demands that exist in almost any production application.<\/p>\n

I will discuss how we, as consumers of academic research, prepare something that we can then present to our users as a finished product that is convenient and safe to use.<\/p>\n

Causal consistency. Let's clarify the concepts.<\/h3>\n

\nFirst, I want to briefly explain what Causal consistency is. There are two characters \u2013 Leonard and Penny (from the series \"The Big Bang Theory\"):<\/p>\n

\"HighLoad++,
\n
\nSuppose Penny is in Europe, and Leonard wants to surprise her with some kind of gathering. And he thinks of no better idea than to remove her from the friend list, send all his friends an update on the feed: \"Let's surprise Penny!\" (she's in Europe, asleep, cannot see any of this, and cannot notice because she is not there). Eventually, he deletes this post, erases it from the feed, and restores access so that she doesn't notice anything and there is no scandal.
\nThis is all wonderful, but let's assume that the system is distributed, and things went a bit differently. For instance, it might happen that the access restriction on Penny occurred after this post appeared, if the events are not causally linked. Essentially, this is an example of when causal consistency is needed to perform a business function (in this case).<\/p>\n

In fact, these are quite non-trivial properties of databases\u2014very few actually support them. Let's move on to the models.<\/p>\n

Consistency Models<\/h3>\n

\nWhat is a consistency model in databases anyway? It refers to certain guarantees that a distributed system gives regarding which data and in what sequence the client can receive.<\/p>\n

Essentially, all consistency models boil down to how much a distributed system resembles one that operates, for example, on a single node on a laptop. The question is how similar a system operating across thousands of geographically distributed nodes is to a laptop where all these properties are essentially fulfilled automatically.<\/p>\n

Therefore, consistency models only apply to distributed systems. All systems that existed before and operated on vertical scaling did not experience such problems. There was a single Buffer Cache, and everything was always read from it.<\/p>\n

Strong Model<\/h3>\n

\nEssentially, the very first model is the Strong model (or rise ability, as it is often called). This is a consistency model that guarantees that every change, as soon as confirmation of its occurrence is received, becomes visible to all users of the system.<\/p>\n

This creates a global order of all events in the database. This is a very strong consistency property, and it is generally very costly. Nevertheless, it is very well supported. It\u2019s just very expensive and slow\u2014hence it is rarely used. This is called rise ability.<\/p>\n

There is another, even stronger property supported in Spanner, known as External Consistency. We will discuss it a bit later.<\/p>\n

Causal<\/h3>\n

\nThe following is Causal, exactly what I was talking about. There are several sublevels between Strong and Causal that I won\u2019t discuss, but they all come down to Causal. This is an important model because it is the strongest of all models, providing the most robust consistency in the presence of a network or partitions.<\/p>\n

Causals refer to situations where events are connected by a cause-and-effect relationship. They are often perceived as Read your on rights from the client's perspective. If a client has observed certain values, they cannot see values from the past. They start to notice prefix reads. It all comes down to the same thing.
\nCausals as a consistency model involve a partial ordering of events on the server, where events from all clients are observed in the same sequence. In this case, it involves Leonard and Penny.<\/p>\n

Eventual<\/h3>\n

\nThe third model is Eventual Consistency. This is what absolutely all distributed systems support; it is the minimal model that makes any sense. It means that when we make some changes to the data, they eventually become consistent.<\/p>\n

At that moment, it doesn\u2019t say anything; otherwise, it would turn into External Consistency\u2014 that would be a completely different story. Nevertheless, this is a very popular model, the most widespread. By default, all users of distributed systems use Eventual Consistency.<\/p>\n

I want to provide some comparative examples:<\/p>\n

\"HighLoad++,
\n
\nWhat do these arrows mean?<\/p>\n