En ingeniería, la redundancia en datos1 es la duplicación o re-escritura de información con la intención de aumentar la confiabilidad del sistema, generalmente en forma de respaldo de almacenamiento o prueba de fallas.
La redundancia en datos es un enfoque común para mejorar la confiabilidad y disponibilidad de un sistema. Agregar redundancia aumenta el costo y la complejidad del diseño de un sistema. Sin embargo, la regla a seguir es que si el costo de la falla es lo suficientemente alto, la redundancia es una opción atractiva. Considera que no deberá ser más costoso el sistema de almacenamiento de redundante que el hecho de perder la información.
Diferencia entre duplicidad y redundancia en datos
La duplicidad se explica cuando tenemos una copia de un dato pero que es innecesaria. Un ejemplo se da en las bases de datos; siguiendo las mejores prácticas los datos sólo existirán una sola vez en la estructura primaria. Es decir, el nombre y apellido de un usuario sólo debe estar en una tabla.
Si guardas estos datos en otra tabla, puedes decir que tienes información duplicada. Esto solamente está haciendo que la base de datos sea más grande y ocupe más espacio pues estos datos sólo deben existir en una estructura para evitar confusiones. Además, agrega un problema, si quieres actualizar esta información deberías no sólo actualizarla en un lugar para evitar que la información sea inconsistente.
Por el contrario, la redundancia en datos de almacenamiento es la acción explícita de generar una o varias copias de toda la base de datos. Un nodo redundante es cualquier nodo que no es estrictamente necesario para que el sistema distribuido funcione correctamente2. En otras palabras, cualquier nodo que aumente la funcionalidad mínima del sistema podemos decir que es redundante.
Redundancia: almacenamiento y seguridad
Una forma de lograr la redundancia es a través de una matriz redundante de discos independientes o RAID. Ésta comprende una tecnología de almacenamiento de datos en la que estos se distribuyen a través de múltiples unidades en una de varias maneras (denominados "niveles" de RAID). Otra técnica es tener uno o varios nodos extra independientes. Lo que representa un sistema distribuido.
Si bien la redundancia en datos es lo que permite duplicar los componentes del diseño, ésta en sí misma no es realmente lo que es útil. La redundancia en realidad no te ayuda si un nodo redundante no está sincronizado con el nodo desde el que se copió.
¿Cuánto tiempo ese nodo redundante será realmente funcional para nosotros? ¿Qué sucede si uno de los nodos cambia de valor o estado? Resulta que la respuesta a ambas preguntas es el proceso de sincronización. Cuando mantienes sincronizados los nodos en tu sistema, estas copias redundantes se vuelven mucho más funcionales para ti.
Por ejemplo, si se replica un servidor web o un nodo de base de datos, los usuarios finales del sistema distribuido no deberían tener idea de que están interactuando con una réplica o el nodo original. De hecho, no deberían tener idea de que incluso hay un nodo replicado.
Cuando esta transparencia se mantiene de manera principal en un sistema, la replicación de nodos brinda muchos beneficios:
1. Hace que el sistema sea mucho más confiable.
Si un nodo se cae y ya has agregado réplicas, es mucho más probable que una réplica intervenga y haga el trabajo del nodo que falla. Esto hace que tu sistema sea más tolerante a fallas. Tener réplicas instaladas también hace que esté más disponible, ya que, en general, hay más réplicas de respaldo para tomar el lugar de otro nodo, lo que significa que tu sistema no debería experimentar demasiado tiempo de inactividad.
2. Hace que tu sistema sea más eficiente.
Con más réplicas instaladas, ahora tienes la capacidad de hacer más trabajo, atender más solicitudes y procesar más datos. Esto hace que tu plataforma sea generalmente más rápida, reduce la latencia y permite que el sistema maneje un alto rendimiento de datos que deben procesarse/entregarse.
3. Logra que tu sistema sea mucho más fácil de escalar.
La escalabilidad es un gran punto a favor cuando se trata de construir un sistema distribuido, pero no siempre es fácil de lograr. Con más nodos replicados, es más fácil escalar al agregar más bases de datos, servidores o servicios según lo exijan las demandas.
También, es más fácil escalar geográficamente cuando puedes replicar un nodo y colocarlo en un continente o país diferente para ayudar a escalar una gran carga de trabajo en una ubicación específica.
Las plataformas bancarias, puntos de venta o cualquier diseño que no puede tolerar un fallo o una interrupción (sistemas de misión crítica) son los principales casos de uso de la redundancia, pues ésta ayuda a prevenir la pérdida de datos críticos.
Un ejemplo práctico: una tienda que tiene varias estaciones de punto de venta utiliza un servidor principal para las transacciones de los clientes. Si este servidor presenta una falla y los puntos de venta no se pueden comunicar al servidor y no hay redundancia de datos habilitada (configurando temporalmente las terminales para funcionar de forma independiente, mediante el uso de un almacenamiento copiado localmente) verás una interrupción en el servicio y no se podrán registrar transacciones.
La idea de incorporar la redundancia de almacenamiento en las aplicaciones puede parecer un desafío. Sin embargo, con el socio tecnológico correcto el proceso no es difícil. Los proveedores de soluciones como KIO Networks estamos listos para ayudar con este imprescindible elemento de la tecnología. Te invitamos a visitar https://www.kionetworks.com/es-mx/
Notas:
- Saha,Sumanta. Aalto University. (2015). Efficient Methods on Reducing DataRedundancy in the Internet https://aaltodoc.aalto.fi/bitstream/handle/123456789/18027/isbn9789526064222.pdf?sequence=1&isAllowed=y consultado noviembre, 2019.
- Huang, Zhen & Chen, Jinbang & Lin, Yisong & You, Pengfei & Peng, Yuxing. ResearchGate. (2015). Minimizing data redundancy for high reliable cloud storage systems https://www.researchgate.net/publication/273398978_Minimizing_data_redundancy_for_high_reliable_cloud_storage_systems consultado noviembre, 2019.
Fuentes:
.png?width=27&height=27&name=Threads_(app).png){kind=small}
