Introducción

Hay un conocido teorema de informática propuesto por Eric Brewer que dice que para una base de datos con datos distribuidos solo puede prometer dos de las siguientes tres cualidades:

• Consistencia
• Disponibilidad
• Tolerancia a particiones

Esto es muy abstracto y la terminología no es exactamente intuitiva, por lo que en este artículo haremos todo lo posible para romper este la teoría baja de lo abstracto a la charla y los ejemplos del mundo real. Este teorema puede hacerle pensar en la arquitectura de su base de datos en términos de lo que su aplicación realmente necesita y los sacrificios que podría tener que hacer para lograrlo.

Definiendo la terminología de la tapa

Quitemos algunas definiciones básicas del camino para que podamos estar en la misma página a medida que avanzamos hablando de este teorema.

CAP – Consistencia, Disponibilidad, Tolerancia a particiones

• Consistencia – Todos sus servidores de datos tienen los mismos datos, por lo que puede consultar cualquier servidor del sistema y obtener exactamente los mismos datos.
• Disponibilidad: Cada solicitud a los servidores de datos recibe una respuesta. Si un servidor está ocupado, se enrutará a otro que pueda responder.
• Tolerancia a particiones: la capacidad del sistema de seguir funcionando incluso si hay fallos de red y algunos de los servidores no pueden comunicarse.

Suposición subyacente: P es imposible

En un sistema de base de datos distribuida, sus datos se dividen en diferentes servidores y esos servidores se comunican entre sí a través de una red para que puedan mantener el mismo conjunto de datos. El problema es que las redes se rompen y por lo tanto asumimos que siempre se comunicará, es decir, no podemos tener una red perfecta. En términos de esta teoría, eso significa que en el mundo real hay que sacrificar la Tolerancia de partición. Si la red perfecta e infalible existiera, entonces no tendríamos problemas para lograr Consistencia y Disponibilidad, pero este es el mundo real construido sobre cables físicos que fallan y, por lo tanto, asumimos que fallará.

Si P es Imposible, ¿Cuáles son nuestras opciones?

Dado que hemos renunciado a la Tolerancia de particiones, el teorema dice que ahora tenemos que elegir entre Consistencia y Disponibilidad.

Puede elegir tener disponibilidad donde su aplicación pueda satisfacer todas las solicitudes entrantes, pero NO PUEDE garantizar que los datos sean los más recientes.

¿Qué necesita su aplicación?

Si su aplicación es un sitio de redes sociales y no necesita tener los datos más recientes en todo momento, es posible que desee elegir Disponibilidad. ¿Importa que tus usuarios vean una publicación después de un retraso de 30 segundos? Si no es así, es posible que prefiera la disponibilidad, porque prioriza que los usuarios puedan acceder a los datos incluso si no son los datos más actualizados.

Si, por otro lado, su aplicación requiere que cada lectura en la base de datos sea la información absoluta más reciente, tendrá que sacrificar la Disponibilidad y elegir la Consistencia. Algunas solicitudes tendrán que salir con errores debido a que la información no puede garantizarse que sea la más reciente en absoluto.

Las elecciones hechas por la tecnología de bases de datos Relacionales y NoSQL

como SQL y otros sistemas de bases de datos relacionales diseñados con consistencia de prioridad ÁCIDA. Por otro lado, la mayoría de las bases de datos NoSQL priorizan la disponibilidad.

Conclusión

Creemos que examinar este teorema en términos de su aplicación es un ejercicio excelente y le ayuda a evaluar las prioridades de su aplicación. Si tiene un sistema de datos distribuido, examine su arquitectura y comprenda qué sacrificio está haciendo.

MongoDB, CockroachDB y Postgres son hoy en día una gran tecnología de bases de datos que hace que nuestras arquitecturas de bases de datos sean extremadamente robustas, pero, como hemos comentado, no son perfectas. No tenemos una red perfecta y siempre hay «error de usuario». Si se muda a un entorno de producción y desea analizar las mejores opciones para su aplicación, no dude en ponerse en contacto con nosotros en Object Rocket.