2A - Cassandra

Paralelización de datos Cassandra Programa Ejecutivo en Big Data & Business Analytics Curso académico 2019 – 2020 PROF

Views 113 Downloads 1 File size 396KB

Report DMCA / Copyright

DOWNLOAD FILE

Recommend stories

Citation preview

Paralelización de datos Cassandra

Programa Ejecutivo en Big Data & Business Analytics

Curso académico 2019 – 2020 PROFESOR Alberto Oikawa [email protected]

Esta publicación está bajo licencia Creative Commons Reconocimiento, Nocomercial, Compartirigual, (bync-sa). Usted puede usar, copiar y difundir este documento o parte del mismo siempre y cuando se mencione su origen, no se use de forma comercial y no se modifique su licencia. Más información: http://creativecommons.org/licenses/by-nc-sa/3.0/

Cassandra

2

Índice de Contenido Cassandra

3

Objetivos

3

Introducción

3

Modelo de datos

4

Arquitectura

5

Referencias

9

Para saber más

9

EOI Escuela de Organización Industrial

http://www.eoi.es

Cassandra

3

Cassandra Durante este módulo se expondrá brevemente el funcionamiento de cassandra así como sus funcionalidades principales. Se pretende que el alumno adquiera una base de conocimiento que le permita seguir avanzando por su cuenta en el aprendizaje de esta tecnología.

Objetivos 1. 2. 3. 4. 5.

Entender el funcionamiento de una base de datos orientada a clave-valor. Conocer los antecedentes de esta tecnología. Comprender el funcionamiento del modelo clave valor Comprender el funcionamiento a grandes rasgos de casandra. Adquirir las nociones básicas de CQL (Cassandra Query Language)

Introducción Cassandra es una base de datos altamente escalable, eventualmente consistente, distribuida y con almacenamiento tipo clave-valor. Surge como el producto de la fusión de las tecnologías distribuidas de Dynamo y el modelo de datos Big Table de Google. Debido a que está basada en Big Table, el modelo de datos que presenta es orientado a familias de columnas (ColumnFamilies) lo que proporciona mayor flexibilidad que el tipo clave-valor exclusivo. El código fuente de Cassandra fue liberado por Facebook en 2008 y es la base de datos que esta empresa utiliza en producción. Las principales características de Cassandra son: 1. 2. 3. 4. 5.

Alta disponibilidad. Escalado horizontal. Consistencia eventual. Configuración del equilibrio entre consistencia y latencia. Modelo de distribución P2P, lo que evita puntos de fallo únicos.

Por tanto, según sus principales características, se trata de una base de datos pensada para funcionar en un sistema distribuido. Cada nodo del sistema juega el mismo papel, no hay arquitectura maestro-esclavo sino P2P. La arquitectura distribuida de Cassandra se presenta como un anillo en el que cada nodo del cluster almacena cierta parte de los datos automáticamente, sin necesidad de configuración. Al igual que otras bases de datos Cassandra proporciona un mecanismo de replicación en el que la información se almacena de forma redundante distribuida en distintos nodos de la red. De esta forma es como se proporciona alta disponibilidad, ya que si un nodo falla la información persiste en otros nodos del anillo. Por otra parte, como consecuencia de la sencillez en la arquitectura, la escalabilidad que se proporciona es lineal, es decir, crece linealmente con la adhesión de nodos al anillo.

EOI Escuela de Organización Industrial

http://www.eoi.es

Cassandra

4

Modelo de datos El modelo de datos de Cassandra tiene su origen en las BigTable de Google. El esquema se estructura de la siguiente forma, por orden de jerarquía: ●

Espacio de claves (Keyspace): Primer nivel de contenido, almacena familias de columnas. Es una práctica habitual que contenga todos los datos de una aplicación. Se podría equiparar a una base de datos en un modelo relacional.



Familia de columnas (Column Family): Segundo nivel de la jerarquía, contiene claves de filas y otras familias de columnas. Este nivel sería equiparable a las tablas del modelo relacional.



Clave de fila (Row Key): Identificador único de un dato almacenado dentro de una Column Family.



Súper columna (Super Column): Estructura tipo diccionario de columnas identificadas por una Row Key.



Columna (Column): Par nombre-valor con un campo adicional que contiene el timestamp del dato.

En la Figura XX se muestra un diagrama con la estructura general de almacenamiento en Cassandra. En primer lugar que se encuentra el keyspace que a su vez aglutina varias column families. Estas a su vez enlazan con una serie de claves, las row keys, que apuntan a grupos de columnas, que contienen el propio valor del dato identificado por un nombre y un timestamp.

Figura 1: Estructura general de almacenamiento de Cassandra.

Así, la forma de acceder a un valor almacenado en Cassandra sería:

EOI Escuela de Organización Industrial

http://www.eoi.es

Cassandra

5

[Keyspace][ColumnFamily][RowKey][Column] = Valor [Keyspace][ColumnFamily][RowKey][SuperColumn][Column] = Valor en función de si se incluye el nivel SuperColumn o no. Las columnas contenidas en las column families se definen en la creación de la misma. Por ejemplo, supóngase un modelo en el que se debe representar información de clientes de una web. La definición del esquema a nivel de column family podría ser entonces como la que se muestra en la Figura 2.

ROW KEY

COLUMNAS Nombre

Apellido

Dirección

Manuel

Rodriguez

C/ Saturno 22

Nombre

Apellido

Dirección

Santiago

García

C/ Júpiter

m.rodriguez

s.garcia

Nombre

Email

Alberto

[email protected]

a.fernandez

Figura 2: Ejemplo de posible modelo de datos para un grupo de usuarios de una web.

Las column families a su vez pueden ser estáticas o dinámicas, en función de si los campos que almacenarán quedan prefijados o no. En el modo estático cada columna debe ser definida, en particular el tipo de dato que almacenará cada campo. No obstante, no se reserva espacio para cada campo definido, como en el caso relacional, sino que el consumo de memoria depende de los datos insertados en cada momento. En el modelo dinámico, sin embargo, no hay definición del esquema y por tanto la aplicación que hace uso de la base de datos es libre de insertar los datos que requiera en tiempo de ejecución.

Arquitectura La arquitectura de Cassandra [2] está orientada a solventar problemas debidos a fallos hardware. Este tipo de fallos son mitigados empleando un sistema P2P distribuido a través de nodos homogéneos donde todos ellos se encargan de almacenar los datos. Por otra parte se realiza un proceso de escritura secuencial en unos ficheros denominados commitlogs presentes en cada nodo que almacenan toda la información sobre la actividad local asegurando así la durabilidad de las acciones. Tras ser escritos en los commitlogs los datos son indexados y almacenados en memoria en unas tablas denominadas memtables. Una vez que la memoria dedicada a dichas tablas está llena, esta información es almacenada en disco en lo que se denominan Sorted String Tables (SSTables). En la Figura 3 se ilustra este proceso de escritura.

EOI Escuela de Organización Industrial

http://www.eoi.es

Cassandra

6

Figura 3: Proceso de almacenamiento de datos (memoria y disco) en Cassandra.

Además, periódicamente, mediante un proceso denominado compactación, los datos son consolidados descartando datos obsoletos y eliminando tombstones, flags que indican que los datos han sido borrados. Se trata de una base de datos orientada a fila, en la que los datos son tratados mediante un lenguaje similar a SQL denominado CQL (Cassandra Query Language). Desde el punto de vista de CQL la base de datos está formada por tablas, como en el caso SQL. CQL se emplea en la consola de acceso cqlsh y en los drivers de desarrollo de aplicaciones. Las lecturas y escrituras se envían al nodo del cluster que debe almacenar el dato en concreto, el proceso de replicación y distribución se realiza de forma automática a través de un nodo que actúa como coordinador. Dicho coordinador actúa como proxy entre la aplicación cliente y los nodos que conforman la base de datos determinando qué nodo del anillo debe atender la petición que entrante. A continuación se listan los principales actores del sistema: ●

Nodo: Unidad mínima de la infraestructura de Cassandra, en ella se almacenan los datos.



Data Center: Colección de nodos relacionados, pueden ser físicos o virtuales. En ellos se realiza el proceso de replicación, en función del factor de replicación este proceso se lleva a cabo en un data center individual o en varios relacionados. No pueden abarcar diferentes localizaciones.



Cluster: Agrupación de Data Centers. En este caso sí pueden abarcar distintas localizaciones físicas.

EOI Escuela de Organización Industrial

http://www.eoi.es

Cassandra

7



Commit Log: Fichero en el que se escriben las acciones realizadas sobre un nodo, después los datos son enviados a las SSTables.



Tabla: Colección de columnas ordenadas accedidas por filas. Una fila está compuesta por varias columnas representadas por una clave primaria (row key) cuya primera parte es el nombre de la columna.



SSTable: Fichero de datos inmutable en el que Cassandra escribe el contenido de las memtables periódicamente. Se trata de tablas en las que únicamente se adjunta información, no se eliminan entradas, únicamente son compactadas y convertidas en otras SSTables.

Por otra parte, los componentes clave que marcan el funcionamiento de la base de datos son: ●

Gossip: Protocolo de comunicación P2P que emplean los nodos del cluster para descubrir la existencia del resto de nodos y compartir información sobre la localización y el estado con el resto. La información gossip es persistente localmente en cada nodo de forma que pueda ser utilizada cuando un nodo se recupera y se reinserta en el anillo.



Particionador: El nodo particionador determina cómo distribuir los datos a través de los nodos del cluster y qué nodo, en un sistema replicado, debe contener la primera copia de los datos. El particionador es en realidad una función hash que calcula el rango o token al que corresponde cada clave insertada. Existen diferentes funciones hash seleccionables, el particionador por defecto es de tipo Murmur3Partitioner.



Factor de replicación: Indica el número total de réplicas que contiene un determinado data center. Un factor de replicación 1 indica que únicamente se almacenará una copia de los datos, 2 establece que se almacenarán dos copias cada una en un nodo diferentes, etc. Todas las réplicas cumplen el mismo papel, no hay réplicas primarias o secundarias sino que todas son accedidas por igual.



Estrategia de distribución de réplicas: Cassandra almacena réplicas de los datos en múltiples nodos para asegurar fiabilidad y tolerancia a fallos. La estrategia de replicación define en qué nodos se almacena cada réplica existiendo dos tipos principales: ○

SimpleStrategy: En esta estrategia de replicación la primera copia de los datos se localiza en un nodo del anillo seleccionado por el particionador y el resto de copias se almacenan en los nodos siguientes siguiendo el sentido de las agujas del reloj. En la FiguraXX se muestra un ejemplo de replicación en un anillo de 4 nodos almacenando 3 copias de los datos.

EOI Escuela de Organización Industrial

http://www.eoi.es

Cassandra

8

Figura 4: Ejemplo de anillo de nodos replicados con 4 nodos y 3 copias.

En el ejemplo el particionador ha determinado que los datos en el rango [A-B) pertenecen al nodo 1, el rango [B,C) al nodo 2, el rango [C,D) al nodo 3 y los comprendidos en [D,A) al nodo 4. Así, con la estrategia de replicación simple la primera copia de A (A1) se almacena en el nodo 1, la segunda (A2) en el nodo 2 y la tercera (A3) en el nodo 3. De forma equivalente, la primera copia de B (B1) se almacena en el nodo 2, la segunda en el nodo 3 y la tercera en el nodo 4 y así sucesivamente. En esta estrategia el único parámetro a determinar es el número de copias de cada dato, que queda establecido en el parámetro replication_factor. ○

NetworkTopologyStrategy: Esta estrategia de replicación se emplea cuando el anillo se distribuye en distintos data centers y se desea especificar cuántas réplicas se almacenarán en cada uno de ellos. Las dos maneras principales de configurar un escenario de este tipo son: ■

Dos réplicas en cada data center: De esta forma se tolera el fallo de un único nodo por grupo de replicación permitiendo lecturas locales si se selecciona un nivel de consistencia ONE. El nivel de consistencia es un parámetro empleado en la escritura que determina cuántos nodos del conjunto de replicación deben estar de acuerdo en la versión del dato para ser considerado correctamente almacenado. Las posibles opciones en los niveles de consistencia son:

Nivel

EOI Escuela de Organización Industrial

Descripción

http://www.eoi.es

Cassandra

9

ANY

La escritura debe realizarse en, al menos, un nodo. Según la configuración es posible que, aún estando todos los nodos de replicación caídos, las escrituras sigan realizándose con éxito y sean las lecturas las que queden bloqueadas hasta que algún nodo se reponga. Es lo que se denomina hinted handoff.

ONE

Las escrituras deben realizarse en, al menos, el commit log y la tabla de memoria de un nodo del conjunto de replicación.

QUORUM

Igual que el caso anterior pero el número de nodos debe llegar a quorum, es decir (numero_nodos_total / 2)+1.

LOCAL_QUORUM

Igual que el caso anterior pero los nodos de replicación deben pertenecer al mismo data center.

EACH_QUORUM

En este caso se debe cumplir la estrategia anterior en cada uno de los data centers.

ALL

La escritura debe realizarse en todos los nodos del conjunto de replicación. ■

Tres réplicas en cada data center: En este caso se toleran fallos de un nodo en cada conjunto de replicación con un nivel de consistencia de LOCAL_QUORUM o la caída de múltiples nodos por data center con un nivel de consistencia ONE.

En este caso es necesario indicar cuántas réplicas almacenará cada datacenter. ●

Snitch: El snitch es el encargado de definir la topología de la red y la estrategia de replicación. Debido a que monitoriza constantemente el estado del cluster es el encargado de determinar qué nodo del conjunto de replicación debe servir una petición por razones de rendimiento. Debe configurarse en el momento de la creación del cluster.

Referencias ● ●

[1] Cassandra Chapter Three – Data Model. Code Project. 2012. [2] Architecture in brief. Datastax Documentation.

Para saber más Aquí se puede ampliar la información sobre el funcionamiento interno de Cassandra.

EOI Escuela de Organización Industrial

http://www.eoi.es