2A - Cassandra
2A - Cassandra
2A - Cassandra
Cassandra
PROFESOR
Alberto Oikawa
[email protected]
Índice de Contenido
Cassandra 3
Objetivos 3
Introducción 3
Modelo de datos 4
Arquitectura 5
Referencias 9
Para saber más 9
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. Entender el funcionamiento de una base de datos orientada a clave-valor.
2. Conocer los antecedentes de esta tecnología.
3. Comprender el funcionamiento del modelo clave valor
4. Comprender el funcionamiento a grandes rasgos de casandra.
5. 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.
1. Alta disponibilidad.
2. Escalado horizontal.
3. Consistencia eventual.
4. Configuración del equilibrio entre consistencia y latencia.
5. 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.
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:
● 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.
[Keyspace][ColumnFamily][RowKey][Column] = Valor
[Keyspace][ColumnFamily][RowKey][SuperColumn][Column] = Valor
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.
Nombre Email
a.fernandez
Alberto [email protected]
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.
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:
● 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.
● 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.
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.
Nivel Descripció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.
Referencias
● [1] Cassandra Chapter Three – Data Model. Code Project. 2012.
● [2] Architecture in brief. Datastax Documentation.