2.

 Descripción general de Cassandra :

Es una base de datos NoSQL que tiene una arquitectura de igual a igual, lo que significa

que no hay maestro ni esclavo o, más específicamente, se puede decir que es la base de
datos sin maestro.

Figura - Arquitectura de igual a igual de Cassandra

Figura: Descripción general de la arquitectura servidor-cliente

Solución para el manejo de Big Data.

 En Cassandra, arquitectura de igual a igual, lo que significa que no hay un

maestro. En términos de escalabilidad, Cassandra es una de las bases de datos
que configura automáticamente el nodo cuando aumenta el número de usuarios.
 Como puede ver en el diagrama, tiene 3 réplicas, tiene 3 copias de datos que es
de alta disponibilidad.
  La tolerancia a fallas también es la característica clave de Cassandra, que le
brinda tiempo de inactividad cero, lo que implica directamente una alta
disponibilidad.

Nota:
Cassandra no reemplaza la base de datos relacional. La base de datos relacional también
es útil para datos de escala media y también puede manejar Big Data, pero si los usuarios
quieren escalabilidad, alta disponibilidad, un sistema tolerante a fallas y tienen big data,
puede optar por Cassandra. Depende de los requisitos del usuario y del modelo de datos.
Así que elige sabiamente.

1-Estado del Arte

De cara a la creación y mantenimiento de sistemas de bases de datos, la replicación es un servicio

casi imprescindible para garantizar una alta disponibilidad, rendimiento y fiabilidad. En una base
de datos replicada, se guardan múltiples copias de los datos en múltiples nodos, pudiendo estar
cada uno en distintas máquinas. Con la replicación de los datos, la base de datos puede mantener
el servicio si una de las maquinas falla.
En este escenario, podemos encontrar 3 tipos de servidores: ➢ Maestros: Procesan peticiones de
escritura y lectura.
➢ Esclavos: Procesan peticiones solo de lectura.
➢ Stand-by: No son accesibles, salvo en caso de switchover.

La replicación de una base de datos implica:

• Consistencia de los datos: Mantener la integridad y consistencia de los datos es un aspecto vital
importancia, como por ejemplo en las aplicaciones de misión crítica, que requieren una estricta
consistencia de los datos modificados por transacciones.
• Tiempos de respuesta bajos durante la creación de la replica: La performance de la base de
datos puede verse afectada durante el proceso de creación de la réplica, debido a razones de
consistencia. • Mantenimiento: Al duplicar los datos, se duplica el espacio ocupado, lo que implica
tener que administrar la réplica.
• Alto tiempo de escritura: Las operaciones de escritura en la base de datos pueden ralentizarse
durante periodos con una gran carga de modificaciones, ya que la transacción necesita
transmitirse en múltiples copias.

Entre los motivos para replicar encontramos:

1. Fail over: Para seguir ofreciendo servicio en caso de fallo del nodo principal.
2. Data warehousing: Útil para pasar los datos del data warehause a los data mart.
3. Load balancing: Mediante la replicación, se puede distribuir la carga entre los nodos, para
lograr un entorno más equilibrado.
4.Servidores Remotos: Para mantener la misma información en servidores separados
geográficamente.

Tipos de replicación:
Una base de datos replicada, todos los cambios realizados a los datos deben ser aplicados en las
múltiples copias, todas las copias tienen que ser idénticas. Tradicionalmente existen dos tipos de
técnicas de replicación, síncrona (eager) y asíncrona (lazy).
En una replicación síncrona, todos los cambios son enviados a todas las copias nada más
realizarse. Por otra parte, la replicación asíncrona, maneja la propagación de los datos con un
breve retraso desde la realización del cambio. Otra característica que diferencia los tipos de
replicación es quién puede realizar los cambios, será maestro-esclavo cuando los cambios tienen
lugar primero en la copia primaria o maestro y después son transmitidos a las segundas copias o
esclavos.

Maestro

Esclavo
Esclavo

La estructura maestro-maestro, al contrario que en la anterior, cualquier copia puede realizar

cambios en los datos, dicha copia procesará el cambio y se sincronizará con las restantes.
 Maestro

Maestro Maestro

Figura 2 – Estructura Maestro-Maestro

Para garantizar la consistencia mutua en una base de datos distribuida, la transacción se procesa
en la base de datos primaria, se registra en el log y se propaga a los secundarios. Un protocolo de
control de atomicidad se encarga de asegurarla, o se ejecuta la transacción en todos los niveles o
en ninguno. Los protocolos más conocidos son 2PC (Two phase commit) y 3PC (Three phase
commit)[22].

Técnicas de replicación Síncrona

Como se ha mencionado anteriormente, existen 2 modos de estructurar los nodos según quién
realiza los cambios. A continuación, se va a detallar el funcionamiento de las dos estructuras con
una replicación síncrona:

Maestro esclavo Síncronos La ejecución de la transacción empieza en la copia primaria, cuando

la transacción termina, los logs generados son enviados a los secundarios, cuando la primera copia
recibe la confirmación de que la transacción en las segundas copias ha finalizado correctamente,
realiza el commit. Es una técnica sencilla, ya que las modificaciones solo se pueden realizar sobre
la copia primaria y no hay necesidad de coordinación. Este tipo de replicación es útil para 12
entornos con muchas lecturas y pocas modificaciones en los datos. Los cambios se propagan
inmediatamente, disponiendo de los datos en tiempo real y asegurando la consistencia en caso de
fallos.
Maestro-Maestro Síncrono En esta técnica, mientras el ítem requerido por la transacción no
esté bloqueado en todas las copias, no se puede acceder a él. Al inicio de la transacción, se envían
peticiones de bloqueo a los otros participantes, hasta que el bloqueo no esté garantizado en todas
las copias, la transacción continuará. Tras recibir la confirmación de bloqueo, la transacción se
ejecuta en todas las copias. La consistencia mutua de los datos está asegurada, los datos siempre
van a ser idénticos en todas las copias. Una alta actividad de escritura puede provocar un exceso
de bloqueos, y consecuentemente a un bajo rendimiento. Esta técnica es útil para entornos que
requieran que los datos se actualicen continuamente y en sistemas de misión crítica. Los
beneficios se contrarrestan con la mayor necesidad de recursos de hardware y de red.

Técnicas de replicación asíncronas

La replicación asíncrona evita los costes de la replicación síncrona, gracias a que se proporciona
una respuesta al cliente antes de la coordinación entre copias. A continuación, se detalla el
funcionamiento, en modo asíncrono, de las dos estructuras de replicación de bases de datos:

Maestro-Esclavo asíncrono Las transacciones de actualización se transmiten de la copia

primaria a las segundas copias y se ejecutan en las mismas. Normalmente, los logs se propagan
entre las segundas copias con un retraso después de haber hecho commit en la primaria. Las
transacciones de lectura son ejecutas en las segundas copias En cada segunda copia, se almacenan
las actualizaciones en una cola FIFO. Un proceso de refresco se encargará de asegurar la
concurrencia entre las transacciones de solo lectura y las de actualización transmitidas por la copia
primaria. La replicación asíncrona maestro-esclavo, es útil cuando hay muchas lecturas y pocas
escrituras. La propagación de los datos es en diferido, por lo que las modificaciones se toman un
tiempo en realizarse desde el commit en la copia primaria. También existe la posibilidad que, al
realizar una lectura local, esta no incluya las modificaciones más recientes realizadas en la copia
primaria. Maestro-Maestro asíncrono La transacción se ejecuta en el maestro delegado, el cliente
obtiene una respuesta, transcurrido un tiempo desde el commit, las modificaciones se propagan al
resto de 13 segundas copias. Como en el otro case de replicación asíncrona, se almacenan las
actualizaciones en una cola FIFO y un proceso de refresco se encarga de su realización. La
propagación de las modificaciones, al ser en diferido puede causar inconsistencia de los datos,
pudiendo incluso perder modificaciones en caso de caída.
Maestro-Maestro vs Maestro-Esclavo
La replicación multimaestro es una solución más elegante, ya que a diferencia de en la replicación
Maestro -Esclavo, no necesita distribuir la carga entre las copias, como los datos son replicados en
todos los nodos, las modificaciones tiene que ser ejecutadas en todos los nodos por igual. Una
manera de mejorar el rendimiento de la replicación multimaestro, es procesando las operaciones
solo en un sitio y mandando los resultados al resto de nodos, con esto, la transmisión de los datos
entre las copias sería más robusta ante posibles fallos

Segmentación o particionamiento de las bases de datos

El particionamiento o segmentación es una técnica para dividir la información de una base de datos
en diferentes partes y cada parte almacenarla en un dispositivo -físico o lógico- para aprovechar
características de paralelismo de los motores modernos de bases de datos, para distribuir espacio de
almacenamiento y para eficientar tablas muy grandes.

Partición o segmentación de tablas e índices

Las tablas se pueden segmentar por grupos de registros y se pueden incluso almacenar en diferentes
FileGroups (que son generados por el DBA) que apuntan a diversos discos inclusive. La decisión
acerca del uso de las particiones depende básicamente del tamaño actual y futuro de la tabla, la
forma en que se utiliza y el rendimiento que presenta en las consultas y las operaciones de
mantenimiento. Por regla general, se crean particiones en tablas si:
1. La tabla contiene, o se espera que contenga, muchos datos que se utilizan de formas diferentes.
2. Las consultas o las actualizaciones en la tabla no presentan el
rendimiento que se esperaba.
3. Si se tiene un arreglo RAID, se puede colocar una partición o Filegroup en cada disco, de tal
manera que el acceso se pueda hacer simultaneo No es recomendable cuando se hacen consultas
utilizando datos de varias particiones, ya que será más costoso para el motor de bases de datos ir por
fracciones de la información de cada segmente y luego unirlas para presentar el resultado al usuario.

Ejemplos de segmentación de tablas

En una base de datos de contabilidad, es común que la información de años anteriores sea de sólo
consulta, y difícilmente habrá una consulta que involucre más de un año, por lo que pueden crearse
particiones por año. Pueden existir grupos de productos o servicios que tienen una demanda mayor
a la de los demás, por lo que esos registros pueden moverse a una o más particiones independientes,
para aislarlos de los demás.

Estrategias de particionamiento
Existen dos maneras principales de hacer la segmentación de tablas:
1. Particionamiento manual, hecho y diseñada por el usuario.
2. Particionamiento por motor de base de datos. Diseñada por el usuario, hecha por el motor de base
de datos.

Particionamiento manual
1. Es el usuario quien crea varias tablas físicas para guardar la información de la tabla original:
Se pueden crear tablas haciendo una partición horizontal o por registros (Una tabla para cada
subconjunto de registros como la contabilidad del 2017, otra tabla para la contabilidad de 2018,
etc.). Esto presupone que no habrá muchas consultas que hagan uso de más de una «partición» ya
que en esa situación se tendrían que hacer uniones de tablas.
2. Vertical, es decir, algunos campos en algunas tablas, todas con el mismo número de registros, y
regularmente con la misma llave primaria (DatosGenerales, Domicilios, etc.) Rompe con reglas de
normalización, pero hace eficiente el mantenimiento y consulta. Implementable en cualquier motor
de base de datos. Migrable fácilmente. Si bien este tipo de segmentación (creando varias tablas para
cada «partición») no cumple con las formas normales (http://dbadixit.com/formas-normales/), si
puede hacer, bajo ciertas circunstancias, la consulta y actualización más eficientes. Como ventaja
podemos mencionar que es implementable en cualquier motor de base de datos y su migración es
muy sencilla.

Particionamiento por motor de base de datos

Esta implementación es una implementación que configura el DBA y que para el usuario de la base
de datos queda en una capa «invisible», por lo que no tiene que hacer ningún cambio o
consideración al trabajar con las tablas o índices. Para el usuario todo aparecerá como una sola
tabla, aunque en la realidad esté dividida la información en varias particiones. Cada motor de bases
de datos tiene su propia implementación de la segmentación, por lo que se irán revisando algunos
motores para conocer la implementación particular de cada uno de ellos.
¿Qué es un cluster?

Un cúmulo, granja o cluster de computadoras, lo podemos definir como un sistema de

procesamiento paralelo o distribuido. Consta de un conjunto de computadoras independientes,
interconectadas entre sí, de tal manera que funcionan como un solo recurso computacional. A
cada uno de los elementos del cluster se le conoce como nodo. Estos son aparatos o torres que
pueden tener uno o varios procesadores, memoria RAM, interfaces de red, dispositivos de entrada
y salida, y sistema operativo. Los nodos pueden estar contenidos e interconectados en un solo
gabinete, o, como en muchos casos, acoplados a través de una red de área local (LAN (Local Area
Network)). Otro componente básico en un cluster es la interfaz de la red, la cual es responsable de
transmitir y recibir los paquetes de datos, que viajan a través de la red entre los nodos. Finalmente
el lograr que todos estos elementos funcionen como un solo sistema, es la meta a la que se quiere
llegar para dar origen a un cluster. Comúnmente, en los clusters existe una máquina (con monitor,
teclado, ratón, etcétera) que funciona como nodo-maestro y se encarga de administrar, controlar
y monitorear todas las aplicaciones y recursos del sistema, en tanto que el resto de los nodos está
dedicado al procesamiento de datos o a ejecutar operaciones aritméticas. Se les conoce como
nodos-esclavos (ver Figura 1)
CONCEPTOS BÁSICOS DE CLUSTERING

En esta sección se presenta una descripción de los términos utilizados en el mundo de los clusters.
El concepto clustering se refiere a una técnica que permite combinar múltiples sistemas para que
trabajen en paralelo y se comporten como un recurso informático unificado para: servir a un grupo
de tareas, proporcionar tolerancia a fallos y tener disponibilidad continua. Por ejemplo, en el caso
de usuarios de Internet, el clustering proporciona bases de datos, correo electrónico, ficheros u
otros servicios de sistema sin interrupciones. Si se presentara una falla dentro de una red de
servidores de un cluster, ésta se corregiría inmediatamente sin que los usuarios lo notaran. Dentro
de esta técnica existen una serie de conceptos fundamentales que se describen a continuación.
Comencemos por explicar el concepto de paralelismo, que consiste en el procesamiento de una
serie de instrucciones de un programa, que son ejecutadas por múltiples procesadores que
trabajan de manera independiente. El paralelismo puede manejarse en dos niveles: paralelismo
del hardware y el software. El primero depende básicamente de la tecnología de cómputo
disponible, mientras el segundo se refiere a la habilidad del usuario para encontrar áreas bien
definidas del problema por resolver, de tal forma que éste pueda ser dividido en partes
autónomas que serán distribuidas entre los nodos del cluster, obteniendo un sistema de alto
rendimiento computacional. Por otro lado está el concepto de multiprocesamiento, una
característica del sistema operativo que controla el hardware. El software asegura la interacción
entre los procesadores a nivel de carga y descarga de datos, además de realizar el despacho de
trabajos en forma múltiple, independiente y simultánea. Otro concepto fundamental es la
programación de hebras (programming threads). Una hebra (thread) es una secuencia de
instrucciones ejecutables que pueden correr independientemente, compartiendo recursos
computacionales con otras hebras. En un programa hay la posibilidad de ejecutar varias hebras
simultáneamente. Cuando esto ocurre todas las hebras activas pueden competir y compartir los
recursos del sistema. Por lo tanto, el usuario ha recurrido a la programación multi-hebras
(multithread) que trae como consecuencia la concurrencia entre procesos y tiene una gran
importancia en el cómputo paralelo (para obtener una descripción más detallada, ver E. Cuadros
2001).