Nota: Este post está desactualizado. Puede encontrar la versión más actualizada aquí.
Esta publicación está desactualizada. Por favor, encuentre la versión actualizada aquí. Estoy dejando intencionalmente este artículo aquí para no interrumpir otros sitios que enlazan a mí.
Hace varios años, integrar el rendimiento en un sistema de software era sencillo: aumentaba los recursos de hardware (ampliación) o modificaba la aplicación para que se ejecutara de manera más eficiente (ajuste del rendimiento). Hoy en día, hay una tercera opción: escalado horizontal (escalado horizontal).
El escalado horizontal de los sistemas de software se ha vuelto necesario en los últimos años, debido a la naturaleza global de la informática y a las crecientes demandas de rendimiento de las aplicaciones. En muchos casos, ya no es aceptable ejecutar un solo servidor con una sola base de datos en un solo centro de datos adyacente a la sede central de su empresa. Necesitamos entornos verdaderamente distribuidos para hacer frente a los desafíos empresariales de hoy en día.
Desafortunadamente, los beneficios de rendimiento que proporciona el escalado horizontal tienen un costo complejo. Los sistemas distribuidos introducen muchos más factores en la ecuación de rendimiento que los que existían antes. Los registros de datos varían según los clientes / nodos en diferentes ubicaciones. Los puntos únicos de falla destruyen el tiempo de actividad del sistema y los problemas intermitentes de la red aumentan en el peor momento posible.
Estas preocupaciones de consistencia (C), disponibilidad (A) y tolerancia de partición (P) en sistemas distribuidos conforman lo que ~~Eric Brewer~~ acuñó como el teorema de la TAPA. En pocas palabras, el teorema de la TAPA demuestra que cualquier sistema distribuido no puede garantizar C, A y P simultáneamente, más bien, las compensaciones deben hacerse en un punto en el tiempo para lograr el nivel de rendimiento y disponibilidad requeridos para una tarea específica.
Consistencia: Todos los nodos ven los mismos datos al mismo tiempo.
En pocas palabras, realizar una operación de lectura devolverá el valor de la operación de escritura más reciente haciendo que todos los nodos devuelvan los mismos datos. Un sistema tiene consistencia si una transacción comienza con el sistema en un estado consistente y termina con el sistema en un estado consistente. En este modelo, un sistema puede (y lo hace) cambiar a un estado inconsistente durante una transacción, pero toda la transacción se revierte si hay un error durante cualquier etapa del proceso.
Las bases de datos relacionales típicas son consistentes: SQL Server, MySQL y PostgreSQL.
Disponibilidad: Cada solicitud recibe una respuesta en caso de éxito o fracaso.
Lograr la disponibilidad en un sistema distribuido requiere que el sistema permanezca operativo el 100% del tiempo. Cada cliente recibe una respuesta, independientemente del estado de cualquier nodo individual del sistema. Esta métrica es trivial de medir: puede enviar comandos de lectura/escritura o no puede hacerlo.
Las bases de datos relacionales típicas también están disponibles: SQL Server, MySQL y PostgreSQL. Esto significa que las bases de datos relacionales existen en el espacio de la CA: consistencia y disponibilidad. Sin embargo, CA no solo está reservada para bases de datos relacionales, algunas herramientas orientadas a documentos como ElasticSearch también caen bajo el paraguas de CA.
Tolerancia de partición: el sistema sigue funcionando a pesar de la pérdida de mensajes o de un fallo parcial.
La mayoría de la gente piensa en su almacén de datos como un solo nodo en la red. «This is our production SQL Server instance» (en inglés). Cualquiera que haya ejecutado una instancia de producción durante más de cuatro minutos, se dará cuenta rápidamente de que esto crea un único punto de falla. Un sistema que es tolerante a particiones puede soportar cualquier cantidad de fallo de red que no resulte en un fallo de toda la red. Los registros de datos se replican lo suficiente en combinaciones de nodos y redes para mantener el sistema activo durante interrupciones intermitentes.
Sistemas de almacenamiento que caen bajo Tolerancia de partición con consistencia (CP): MongoDB, Redis, Almacenamiento en caché de AppFabric y MemcacheDB. Los sistemas CP ofrecen excelentes cachés distribuidos, ya que cada cliente obtiene los mismos datos y el sistema se divide a través de los límites de la red.
Los sistemas de almacenamiento que se encuentran bajo Tolerancia de partición con disponibilidad (AP) incluyen DynamoDB, CouchDB y Cassandra.
Conclusión
Los sistemas distribuidos nos permiten alcanzar un nivel de potencia informática y disponibilidad que simplemente no estaban disponibles en el pasado. Nuestros sistemas tienen un mayor rendimiento, una latencia más baja y un tiempo de actividad cercano al 100% en centros de datos que abarcan todo el mundo. Lo mejor de todo es que los sistemas de hoy en día se ejecutan en hardware básico que se puede obtener fácilmente y configurar con costos cercanos a 0 dólares.
Todo este poder de cómputo y beneficio tiene un precio, sin embargo. Los sistemas distribuidos son más complejos que sus homólogos de una sola red. Hay muchas más herramientas y habilidades que deben adquirirse para crear un sistema verdaderamente escalable y de alto rendimiento. Comprender la complejidad en la que se incurre en los sistemas distribuidos, hacer las compensaciones apropiadas para la tarea en cuestión (CAP) y seleccionar la herramienta adecuada para el trabajo son habilidades críticas en un mundo en el que los sistemas informáticos se están moviendo hacia afuera, no hacia arriba.
