[MÚSICA] [MÚSICA] En la sesión de hoy hablaremos de consistencia y qué efectos tiene la consistencia en sistemas distribuidos de datos sobre la fiabilidad y la escalabilidad de los sistemas. Hablaremos primero de qué significa la consistencia de datos, y luego introduciremos qué impacto tiene a la hora de gestionar los sistemas de distribuido de datos de gran tamaño. Introduciremos el teorema CAP en este entorno y hablaremos de la necesidad de decidir entre consistencia o disponibilidad en grandes sistemas de datos. Finalmente, daremos un par de ejemplos de qué sistemas existen para adaptarlos a nuestras necesidades de nuestros proyectos. Bueno, principalmente la consistencia de datos la vamos a analizar, la vamos a trabajar en el contexto de grandes sistemas de datos distribuidos donde tenemos nuestro repositor de datos donde vamos a trabajar. En ese sentido también es donde tiene validez el teorema CAP. Bien, la consistencia de datos en este entorno, lo que permite, el objetivo que tiene es garantizar que los datos almacenados en las bases de datos muerden siempre unos valores veraces. Es decir, que siempre que vayamos a acudir a esos datos, a esos repositorios, a esas bases de datos, tengamos un resultado fiable. Por lo tanto, cada vez que se realice una operación en la base de datos, el resultado tiene que ser consistente, es decir, no se puede invalidar el resultado que hay previamente. Para asegurar este tipo de operación, se realizan dos aproximaciones. La primera es que yo me aseguro que cada cambio que realizo en la base de datos mantiene la consistencia previa. Si es así dejamos pasar el dato y si no es así lo que hacemos es invalidar esa operación y pasamos al estado previo de consistencia que tenía el sistema. Existen varios modelos de consistencia que permiten perseguir este objetivo, que el sistema almacene en cada uno de los nodos donde se almacenan datos una consistencia. La primera es la estricta, es decir, todos los cambios que se producen en la base de datos tienen que llegar a todos los servidores, a todos los nodos, de forma atómica y de forma instantánea. Es decir, no se puede dar una operación como acabada hasta que todos los servidores tengan la última versión. En sistemas muy grandes eso tiene un coste muy alto, por lo tanto se plantean otros modelos de consistencia como por ejemplo la secuencial donde cada cliente ve los cambios en el orden en el que aparecieron, la causal, de forma que lo cambios aparecen según el orden causal. También la consistencia eventual es importante, you que permite que los cambios se propaguen de forma local. Y, finalmente, tenemos los de consistencia débil, donde no se hace ningún esfuerzo en asegurar la consistencia global y podemos tener datos en diferentes estados, en diferentes nodos del sistema. Bien, la consistencia es relevante cuando tratamos los errores. Es decir, hay un momento en nuestro sistemas de datos distribuido que tenemos dos versiones, dos documentos, dos variables tienen diferentes valores en dos servidores. ¿Qué hacemos en ese momento? Bueno, en ese momento, como diseñadores de sistemas, tenemos que decidir entre dos opciones, mantener la consistencia, es decir, no dejamos ningún cambio más, no dejamos acceder a nuestras variables o nuestros documentos hasta que ese cambio se haya propagado a todas las instancias de esos datos, o bien nos orientamos a la disponibilidad, es decir, permitimos que se siga leyendo los datos aunque estos no tengan la última versión de los mismos. Es importante decir que mientras no se produzcan errores, mantener la consistencia y la disponibilidad pues no tiene ningún problema, porque mientras solo sea de lectura no se produce ningún problema. En este sentido, en el sentido de cómo gestionamos los errores, es cuando se plantea el teorema CAP, que básicamente nos viene a decir que los sistemas distribuidos de gestión de datos tienen que elegir dos de tres propiedades: la primera es la consistencia, mantener la consistencia, mantener la disponibilidad o bien mantener la tolerancia la particionado de datos. Podemos elegir solo dos de estas tres capacidades. Como normalmente en los sistemas de distribuidos de datos aceptamos que los datos están distribuidos geográficamente, you sea en diferentes oficinas o de forma global en el planeta, utilizando proveedores en la nube, lo que tenemos es que elegir entre la consistencia o la disponibilidad de nuestros datos. Por lo tanto, tendremos que elegir entre dos opciones. Elegir consistencia, es decir, en algún momento el sistema no estará disponible, pueden ser segundos o milisegundos, hasta que todos los servidores que tenemos tengan la última versión, o bien nos orientamos a disponibilidad, es decir, los usuarios y aplicaciones siempre tienen acceso a los datos, en ningún momento se interrumpe, pero aquellos en algún momento no tendrán la última versión de los datos. Un servidor puede no reflejar la última versión de un valor. En ese sentido, muchos sistemas distribuidos plantean la consistencia eventual como una aproximación a las dos. Intentan tener las dos cosas, la disponibilidad y acercarnos a la consistencia de la mejor manera posible. Por lo tanto, ¿qué proponen? Un modelo de consistencia débil, es decir, que los clientes siempre tienen acceso a los datos en todo momento e intentan acercarse a la consistencia de forma que cuando los cambios se hayan producido, estos se propagan de la manera que se han producido a los demás servicios, demás servidores, demás nodos de nuestro sistema. Por lo tanto, conservaremos la consistencia de una manera relajada en un tiempo que se va a llegar a producir. En este ejemplo vemos un momento en el cual tenemos tres servidores y uno de los datos, el tercer servidor a la derecha, tiene una copia que se ha modificado. Por lo tanto, en una consistencia eventual los datos de los servidores que quedan a la izquierda siguen siendo visibles, las aplicaciones pueden seguir haciendo consultas, en algún momento ese dato llegará a propagarse ese cambio a los dos servidores que vemos a la izquierda. Como usuarios, como diseñadores de sistemas distribuidos y de aplicaciones, tenemos que elegir en algún momento qué tipos de bases de datos vamos a usar en nuestros sistemas, y, por ejemplo, para orientadas a disponibilidad y tolerancia a particionado tenemos Cassandra y orientadas a consistencia y disponibilidad tenemos HBASE y MongoDB. En nuestro caso, tendremos que elegir en cada momento qué es lo que nos interesa según nuestros proyectos. [MÚSICA] [MÚSICA]
