{"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\/es\/blog\/administrirovanie\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike","title":{"rendered":"HighLoad++, Mikhail Tyulenev (MongoDB): Consistencia causal: de la teor\u00eda a la pr\u00e1ctica","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La pr\u00f3xima conferencia HighLoad++ se llevar\u00e1 a cabo el 6 y 7 de abril de 2020 en San Petersburgo.
\nDetalles y entradas en el enlace<\/a><\/noindex>. HighLoad++ Siberia 2019. Sal\u00f3n \"Krasnoyarsk\". 25 de junio, 12:00. Res\u00famenes y presentaci\u00f3n<\/a><\/noindex>.<\/p>\n

\"HighLoad++,
\n
\nA veces, los requisitos pr\u00e1cticos entran en conflicto con la teor\u00eda, donde no se han considerado aspectos importantes para un producto comercial. En esta presentaci\u00f3n se presenta el proceso de selecci\u00f3n y combinaci\u00f3n de diferentes enfoques para crear componentes de consistencia causal basados en investigaciones acad\u00e9micas a partir de los requisitos de un producto comercial. Los oyentes conocer\u00e1n los enfoques te\u00f3ricos existentes sobre relojes l\u00f3gicos, seguimiento de dependencias, seguridad del sistema, sincronizaci\u00f3n de relojes y por qu\u00e9 MongoDB eligi\u00f3 ciertas soluciones.<\/a><\/noindex><\/p>\n

Mikhail Tyulenev (en adelante \u2013 MT):<\/b> \u2013 Voy a hablar sobre la consistencia causal; es una caracter\u00edstica en la que hemos trabajado en MongoDB. Trabajo en el grupo de sistemas distribuidos, la creamos hace aproximadamente dos a\u00f1os.<\/p>\n

\"HighLoad++,
\n
\nEn el proceso tuve que familiarizarme con una gran cantidad de investigaci\u00f3n acad\u00e9mica, ya que esta caracter\u00edstica est\u00e1 bastante bien estudiada. Result\u00f3 que ning\u00fan art\u00edculo se ajusta a lo que se requiere en producci\u00f3n, a la base de datos, debido a los requisitos bastante espec\u00edficos que existen, probablemente, en cualquier aplicaci\u00f3n de producci\u00f3n.<\/p>\n

Voy a hablar sobre c\u00f3mo, como consumidores de la investigaci\u00f3n acad\u00e9mica, preparamos algo de ello que luego podemos presentar a nuestros usuarios como un plato terminado, con el que sea conveniente y seguro de usar.<\/p>\n

Consistencia causal. Definamos los conceptos<\/h3>\n

\nPara comenzar, quiero esbozar en t\u00e9rminos generales qu\u00e9 es la consistencia causal. Hay dos personajes: Leonard y Penny (de la serie \"The Big Bang Theory\"):<\/p>\n

\"HighLoad++,
\n
\nSupongamos que Penny est\u00e1 en Europa, y Leonard quiere hacerle una sorpresa, una fiesta. Y no se le ocurre nada mejor que eliminarla de su lista de amigos, enviar a todos sus amigos una actualizaci\u00f3n en el feed: \"\u00a1Celebremos a Penny!\" (ella est\u00e1 en Europa, mientras duerme, no ve nada de esto y no puede verlo, porque no est\u00e1 all\u00ed). En un momento final elimina esa publicaci\u00f3n, la borra del \"Feed\" y restaura el acceso, para que ella no se de cuenta y no haya esc\u00e1ndalo.
\nTodo esto es maravilloso, pero supongamos que el sistema es distribuido, y las cosas no salieron exactamente como se esperaba. Puede suceder, por ejemplo, que la restricci\u00f3n de acceso a Penny se aplicara despu\u00e9s de que se public\u00f3 esta entrada, si los eventos no est\u00e1n conectados entre s\u00ed de manera causal. Este es un ejemplo de cu\u00e1ndo se requiere consistencia causal para llevar a cabo una funci\u00f3n comercial (en este caso).<\/p>\n

En realidad, estas son propiedades bastante no triviales de las bases de datos, muy pocos las soportan. Pasemos a los modelos.<\/p>\n

Modelos de consistencia (Consistency Models)<\/h3>\n

\n\u00bfQu\u00e9 es en realidad un modelo de consistencia en bases de datos? Son ciertas garant\u00edas que un sistema distribuido proporciona sobre qu\u00e9 datos y en qu\u00e9 secuencia un cliente puede recibir.<\/p>\n

En principio, todos los modelos de consistencia se reducen a cu\u00e1n parecido es un sistema distribuido a uno que opere, por ejemplo, en un solo nodo en una laptop. Y cu\u00e1n similar es un sistema que opera en miles de nodos geogr\u00e1ficamente distribuidos a una laptop, donde todas estas propiedades se cumplen autom\u00e1ticamente.<\/p>\n

Por lo tanto, los modelos de consistencia solo se aplican a sistemas distribuidos. Todos los sistemas que existieron antes y funcionaron con una escalabilidad vertical no enfrentaban tales problemas. Hab\u00eda un solo Buffer Cache, y de \u00e9l siempre se le\u00eda.<\/p>\n

Modelo Strong<\/h3>\n

\nEn realidad, el primer modelo es el Strong (o modelo de capacidad de crecimiento, como se le suele llamar). Este es un modelo de consistencia que garantiza que cada cambio, tan pronto como se recibe la confirmaci\u00f3n de que ocurri\u00f3, se vuelve visible para todos los usuarios del sistema.<\/p>\n

Esto crea un orden global de todos los eventos en la base de datos. Esta es una propiedad de consistencia muy fuerte, y es bastante costosa. Sin embargo, se mantiene muy bien. Es simplemente muy cara y lenta; por ello, se usa raramente. Esto se llama capacidad de crecimiento.<\/p>\n

Hay otra propiedad, a\u00fan m\u00e1s fuerte, que se mantiene en 'Spanner' \u2013 se llama consistencia externa. Hablaremos de esto m\u00e1s adelante.<\/p>\n

Causal<\/h3>\n

\nLo siguiente es Causal, justo de lo que hablaba. Existen varios subniveles entre Strong y Causal, de los cuales no hablar\u00e9, pero todos se reducen a Causal. Este es un modelo importante porque es el m\u00e1s fuerte de todos los modelos, la consistencia m\u00e1s fuerte en presencia de una red o particiones.<\/p>\n

Causals son, de hecho, la situaci\u00f3n en la que los eventos est\u00e1n relacionados por una relaci\u00f3n de causa y efecto. A menudo se perciben como Read your own rights desde la perspectiva del cliente. Si un cliente ha observado ciertos valores, no puede ver los valores que estaban en el pasado. Ya empieza a ver lecturas prefijadas. Todo esto se reduce a lo mismo.
\nCausals como modelo de consistencia - un orden parcial de los eventos en el servidor, donde los eventos de todos los clientes se observan en la misma secuencia. En este caso - Leonard y Penny.<\/p>\n

Eventual<\/h3>\n

\nEl tercer modelo es la Consistencia Eventual. Este es el que mantienen absolutamente todos los sistemas distribuidos, el modelo m\u00ednimo que tiene sentido. Significa lo siguiente: cuando ocurren ciertos cambios en los datos, en alg\u00fan momento se vuelven consistentes.<\/p>\n

En ese momento no dice nada, de lo contrario se convertir\u00eda en Consistencia Externa, ser\u00eda una historia completamente diferente. Sin embargo, este es un modelo muy popular, el m\u00e1s com\u00fan. Por defecto, todos los usuarios de sistemas distribuidos utilizan precisamente la Consistencia Eventual.<\/p>\n

Quiero dar algunos ejemplos comparativos:<\/p>\n

\"HighLoad++,
\n
\n\u00bfQu\u00e9 significan estas flechas?<\/p>\n