Explicación del teorema CAP: Consistencia, disponibilidad y tolerancia a particiones

El teorema CAP está una creencia de la informática teórica sobre los almacenes de datos distribuidos que afirma que, en caso de fallo de la red en una base de datos distribuida, es posible proporcionar consistencia o disponibilidad, pero no ambas cosas.

¿Qué es el teorema de la PAC?

El Teorema CAP está compuesto por tres componentes (de ahí su nombre) en relación con almacenes de datos distribuidos:

• Consistencia. Todas las lecturas reciben la escritura más reciente o un error.
• Disponibilidad. Todas las lecturas contienen datos, pero puede que no sea la más reciente.
• Tolerancia a particiones. El sistema sigue funcionando a pesar de fallos de red (es decir, particiones caídas, conexiones lentas o conexiones de red no disponibles entre nodos).

Teorema CAP para bases de datos y tolerancia a particiones

En operaciones normales, tu almacena de datos proporciona las tres funciones. Pero el teorema CAP sostiene que cuando una base de datos distribuida sufre un fallo en la red, te puede proporcionar consistencia o disponibilidad. Es un intercambio. En todas las demás ocasiones, se pueden proporcionar las tres. Pero, en caso de fallo de red, debe tomarse una decisión. En el teorema, la tolerancia a las particiones están imprescindible. La suposición están que el sistema opera sobre un almacena de datos distribuido, por lo que el sistema, por naturaleza, opera con particiones de red. Se producirán fallos de red, por lo que para ofrecer cualquier tipo de servicio fiable, están necesaria tolerancia a particiones—el P de CAP. Eso deja una decisión entre los otros dos, C y A. Cuando ocurre un fallo de red, se puede elegir garantizar la consistencia o disponibilidad:

El Teorema de la CAP vs. ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad)

La consistencia en CAP está diferente a la de ACID. La consistencia en CAP significa tener la información más actualizada. (ACID se refiere a un evento diferente de la base de datos. En ACID, consistencia significa que cualquier nueva transacción en la base de datos no corromperá la base de datos.)

Ejemplos de teoremas CAP: ¿consultas de usuario consistentes o disponibles?

El momento en cuestión están la consulta del usuario. Asumimos que un usuario realiza una consulta a una base de datos, y la base de datos en red está para devolver un valor. El valor que están devueltos desde la base de datos depende de nuestra elección para proporcionar consistencia o disponibilidad. Así podría desarrollarse esta elección:

• En una consulta, podemos responder al usuario con el valor actual en el servidor, ofreciendo un servicio altamente disponible. Si hacemos esto, no están garantía de que el valor están el valor más reciente enviado a la base de datos. están posible que una escritura reciente se quede atascada en tránsito en algún lugar.
• Si queremos garantizar una alta consistencia, entonces tenemos que esperar a la nueva escritura o devolver un error a la consulta. Por tanto, sacrificamos la disponibilidad para asegurar que los datos devueltos por la consulta están consistentes.

Determinando el mejor diseño de sistema basado en el teorema de la CAP para tus necesidades

Para algunos, la elección entre consistencia y disponibilidad está realmente una cuestión de debate filosófico que rara vez se hace en la práctica. La fiabilidad de estos sistemas distribuidos está bastante buena. Dicho esto, los problemas ocurren. AWS sufrió una gran caída justo antes de Acción de Gracias de 2020. Donde la teoría dice que te puedes tener solo dos de tres componentes, los profesionales afirman que no siempre es así. Eric Brewer, informático que inicialmente propuso el teorema CAP, aclaró algunas confusiones sobre el teorema, generalizándolo de una afirmación estricta de o/o a uno según la necesidad del sistema. Dijo:

"El objetivo moderno de la PAC debería ser maximizar las combinaciones de consistencia y disponibilidad que Haz sentido para la aplicación específica. Este enfoque incorpora planes de operación durante una partición y de recuperación posterior, ayudando así a los diseñadores a pensar en la PAC más allá de sus limitaciones históricamente percibidas."

Elegir consistencia y disponibilidad se debe al elegir qué tipo de base de datos elegir, como SQL frente a NoSQL. Las bases de datos NoSQL pueden clasificarse según si soportan alta disponibilidad o alta consistencia.

Diseño de sistemas con teorema CAP y bases de datos NoSQL

Las bases de datos NoSQL tienen ventajas sobre las bases de datos relacionales convencionales. Las bases de datos JSON NoSQL permiten te diseña sin un esquema. Pueden manejar grandes conjuntos de datos que contienen datos no estructurados, sin obligar a que las tablas se relacionen entre sí. Los datos están almacenan en documentos JSON, que son entidades completas que un ser humano puede leer y comprender fácilmente. Este enfoque están muy adecuado para el desarrollo ágil cuando los requisitos son evolucionando. Los beneficios de las bases de datos JSON NoSQL incluyen:

• Facilidad de utiliza: te disponen de flexibilidad en el modelado de datos para soportar una variedad de tipos de datos y facilitar el desarrollo.
• Rendimiento escalable: te puede gestionar más datos y mucho tráfico añadiendo servidores en clústeres en una arquitectura distribuida.
• Fuerte resiliencia: Dado que las bases de datos NoSQL funcionan en entornos de nube distribuida, son menos propensas a puntos de fallo únicos y pueden replicar fácilmente datos a través de múltiples nodos.
• Amplia disponibilidad: Las bases de datos NoSQL son habituales, y la mayoría de los proveedores de la nube ofrecen estas soluciones ya sea como servicios gestionados o como opciones independientes.

Ejemplos de bases de datos NoSQL incluyen:

• Cloud Firestore
• Base de datos en tiempo real de Firebase
• MongoDB
• MarkLogic
• Couchbase
• CloudDB
• Amazon DynamoDB

Priorización de la consistencia de bases de datos utilizando el teorema CAP

Se deben utilizar bases de datos consistentes cuando el valor de la información devuelta debe ser preciso.

Los datos financieros están un buen ejemplo. Cuando un usuario inicia sesión en su entidad bancaria, no quiere Ve un error de que no se están devueltos datos, o que el valor están más alto o menor de lo que realmente es. Las aplicaciones bancarias deberían devolver el valor exacto de la información de la cuenta del usuario. En este caso, los bancos dependerían de bases de datos consistentes. Ejemplos de una base de datos consistente incluyen:

• Saldos de cuentas bancarias
• Mensajes de texto
• Inventario
• Sistemas de reservas de aerolíneas
• Nóminas
• Registros estudiantiles
• Historiales médicos
• Sistemas de gestión energética

Opciones de base de datos para priorizar el componente de consistencia del teorema CAP:

• MongoDB
• Redis
• HBase

Priorización de la disponibilidad de bases de datos utilizando el teorema de la capitalización

Las bases de datos de disponibilidad deben utilizarse cuando el servicio están más importante que la información.

Un ejemplo de tener una base de datos altamente disponible puede verse en los negocios de comercio electrónico. Las tiendas online quieren Haz su almacena y las funciones del carrito de la compra disponibles las 24 horas del día, los 7 días de la semana, para que los compradores puedan Haz exactamente cuando lo necesiten. Opciones de base de datos para priorizar el componente de disponibilidad del teorema CAP:

• Cassandra
• DynamoDB
• Cosmos DB

Algunas opciones de base de datos, como Cosmos y Cassandra, permiten al usuario activar un mando que prefiere la consistencia o la disponibilidad.

Aplicación del Teorema CAP para optimizar la experiencia del usuario

El reto del teorema de la PAC está en que, idealmente, tú quieres Lograr los tres objetivos a la vez, pero solo tú puedes elegir dos. Tomar la decisión correcta marca toda la diferencia. El equilibrio entre consistencia, disponibilidad y conseguir el equilibrio adecuado depende de la aplicación y de lo que valore el usuario. Tomar la decisión equivocada puede Crea una experiencia negativa y destruir la confianza o causar frustración. Saber lo que los usuarios toleran y esperan te ayudará a calibrar el equilibrio óptimo.

Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.