REDUNDANCIA

En ingeniería, la redundancia en datos es la duplicación o reescritura 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.
 ¿Qué es el modelo ACID en bases de datos?
El modelo ACID en bases de datos se refiere a un resumen de las propiedades que
debe mantener una data base de forma conjunta, con el objetivo de garantizar la
seguridad de las transacciones. Una transacción es una operación lógica o un
conjunto de órdenes, cuya ejecución da forma a una unidad de trabajo.

ACID es, por tanto, el acrónimo para los conceptos Atomicity, Consistency, Isolation
y Durability, que en español significa, respectivamente, atomicidad, consistencia,
aislamiento en las transacciones y durabilidad.

El término ACID en bases de datos proviene de Andreas Reuter y Theo Härder,

quienes, en el inicio de la década de los 80, desarrollaron este término para describir
las propiedades necesarias de una transacción fiable, que anteriormente había
planteado el científico de computación Jim Gray.

Propiedades ACID en bases de datos

Las cuatro propiedades pertenecientes al modelo ACID en bases de datos pueden

detallarse de la siguiente forma:

Atomicity o atomicidad

El primer término de ACID en base de datos se refiere a la atomicidad de las

transacciones, es decir, que el sistema permite que se lleven a cabo las operaciones
atómicas. Esta propiedad indica que, para que una transacción se dé por
«completada», deben haberse realizado todas sus partes o ninguna de ellas.

Es también conocida como el «todo o nada» de la transacción, debido a que, en el

caso de que se completen todos los pasos de la transacción, se obtendrán las
modificaciones requeridas en la base de datos. Si una parte de la transacción falla,
el sistema debe ser capaz de hacer que el resto de las operaciones fallen, por lo
que la base de datos no sufrirá ningún cambio indeseado.

Consistency o consistencia

El concepto de consistencia en el modelo ACID en base de datos está relacionado

con la propiedad de atomicidad y hace referencia a la capacidad que tiene un
sistema para iniciar solo operaciones que puede concluir. Esto implica que solo se
pueden ejecutar pasos de la transacción que no incumplan con las reglas o
directrices de integridad definidas, incluyendo los triggers, cascades y constraints,
así como sus combinaciones.
La propiedad de consistencia en las bases de datos se basa en la premisa que
afirma que una transacción debe llevar al sistema de un estado válido a otro que
también lo sea. Cabe resaltar que la validez de las operaciones está determinada
por su seguimiento o no de las reglas establecidas para garantizar la fiabilidad de la
base de datos.

Isolation o aislamiento

La propiedad de aislamiento del modelo ACID en bases de datos se refiere a la

manera y el momento en el que los cambios resultantes de una operación se harán
visible para las demás operaciones concurrentes. Es decir, la realización de una
operación no debería afectar a las otras, debido a que cada una de las
transacciones debe ser ejecutada en aislamiento total, sin importar si se llevan a
cabo de manera simultánea.

Esta propiedad puede entenderse también bajo la premisa de que el estado

intermedio de una transacción no debe ser visible por otra, garantizando así su
aislamiento y que sea posible replicar el estado final de la base de datos en el caso
de que se ejecuten una a una las transacciones de forma paralela y concurrente.

Durability o durabilidad

La durabilidad de ACID en bases de datos hace referencia a la propiedad que

garantiza que, una vez se haya llevado a cabo una determinada operación (aquellas
transacciones que tuvieron un commit), estas tengan la capacidad de persistir y no
puedan ser deshechas incluso si el sistema falla o se presentan eventos como
errores o caídas o pérdida de alimentación eléctrica, entre otros.

Esta característica de ACID en bases de datos implica que los datos y cambios en
una transacción que ya se ha realizado deben ser permanentes y no puede ocurrir
una pérdida de estos en el sistema.

Una de las estrategias de las bases de datos para poder implementar esta
propiedad es escribir en las operaciones un log de transacciones que tiene la
posibilidad de ser reprocesado para recrear el estado del sistema antes de una falla.
Cabe aclarar que una operación solo se considera confirmada una vez haya sido
ingresada al log.