4.1 Descripción

Apache Cassandra es un sistema de administración de bases de datos distribuidas que pertenece a la clase de sistemas NoSQL y está diseñado para crear almacenamientos altamente escalables y confiables de enormes conjuntos de datos presentados en forma de hash.

Inicialmente, el proyecto se desarrolló en las entrañas de Facebook y en 2009 se transfirió bajo el ala de Apache Software Foundation, esta organización continúa desarrollando el proyecto. Las soluciones industriales basadas en Cassandra se implementan para brindar servicios a empresas como Cisco, IBM, Cloudkick, Reddit, Digg, Rackspace, Huawei, Netflix, Apple, Instagram, GitHub, Twitter y Spotify. En 2011, el clúster de servidores más grande que prestaba servicios a una sola base de datos bajo Cassandra tenía más de 400 máquinas y contenía más de 300 TB de datos.

Escrito en el lenguaje Java , implementa un sistema hash distribuido similar a DynamoDB, que proporciona una escalabilidad casi lineal con un volumen de datos creciente. Utiliza un modelo de almacenamiento de datos basado en una familia de columnas, que se diferencia de sistemas como MemcacheDB, que almacenan datos solo en un par clave-valor, por la capacidad de almacenar hashes con varios niveles de anidamiento.

Pertenece a la categoría de DBMS tolerante a fallas: los datos colocados en la base de datos se replican automáticamente en varios nodos de una red distribuida o incluso se distribuyen uniformemente en varios centros de datos. Cuando un nodo falla, sus funciones son retomadas sobre la marcha por otros nodos, agregando nuevos nodos al clúster y actualizando la versión de Cassandra sobre la marcha, sin intervención manual adicional ni reconfiguración de otros nodos.

Sin embargo, se recomienda encarecidamente volver a generar claves (etiquetas) para cada nodo, incluidos los existentes, para preservar la calidad del balanceo de carga. La generación de claves para los nodos existentes se puede evitar en el caso de un aumento múltiple en el número de nodos (2 veces, 3 veces, etc.).

4.2 Modelo de datos

En la terminología de Cassandra, una aplicación funciona con un espacio de claves, que corresponde al concepto de esquema de base de datos en el modelo relacional. Este espacio de claves puede contener varias familias de columnas, lo que corresponde al concepto de una tabla relacional.

A su vez, las familias de columnas contienen columnas (columna), que se combinan mediante la clave (clave de fila) en el registro (fila). La columna consta de tres partes: nombre (nombre de la columna), marca de tiempo (timestamp) y valor (value). Las columnas dentro de un registro están ordenadas. A diferencia de una base de datos relacional, no hay restricciones sobre si los registros (y en términos de la base de datos son filas) contienen columnas con los mismos nombres que en otros registros: no.

Las familias de columnas pueden ser de varios tipos, pero en este artículo omitiremos este detalle. También en las últimas versiones de Cassandra, se hizo posible ejecutar consultas para definir y cambiar datos (DDL, DML) utilizando el lenguaje CQL, así como crear índices secundarios.

El valor específico almacenado en cassandra se identifica por:

  • keyspace es un enlace a la aplicación (dominio). Le permite alojar datos de diferentes aplicaciones en el mismo clúster;
  • una familia de columnas es un enlace a una consulta;
  • key es un enlace a un nodo de clúster. La clave determina en qué nodos terminarán las columnas guardadas;
  • el nombre de la columna es un enlace a un atributo en el registro. Le permite almacenar múltiples valores en una sola entrada.

Cada valor está asociado con una marca de tiempo, un número especificado por el usuario que se usa para resolver conflictos durante la grabación: cuanto mayor es el número, se considera la columna más nueva y, cuando se compara, sobrescribe las columnas antiguas.

4.3 Tipos de datos

Por tipos de datos: el espacio de claves y la familia de columnas son cadenas (nombres); la marca de tiempo es un número de 64 bits; y la clave, el nombre de la columna y el valor de la columna es una matriz de bytes. Cassandra también tiene el concepto de tipos de datos. El desarrollador puede especificar estos tipos (opcionalmente) al crear una familia de columnas.

Para los nombres de las columnas, esto se denomina comparador, para los valores y las claves, se denomina validador. El primero define qué valores de bytes están permitidos para los nombres de las columnas y cómo ordenarlos. El segundo es qué valores de bytes son válidos para los valores de columna y clave.

Si estos tipos de datos no están configurados, Cassandra almacena los valores y los compara como cadenas de bytes (BytesType) ya que, de hecho, se almacenan internamente.

Los tipos de datos son:

  • BytesType : cualquier cadena de bytes (sin validación)
  • AsciiType : cadena ASCII
  • Tipo UTF8 : cadena UTF-8
  • IntegerType : número con tamaño arbitrario
  • Int32Type : número de 4 bytes
  • LongType : número de 8 bytes
  • UUIDType : UUID tipo 1 o 4
  • TimeUUIDType : Tipo 1 UUID
  • DateType : valor de marca de tiempo de 8 bytes
  • BooleanType : dos valores: verdadero = 1 o falso = 0
  • FloatType : número de punto flotante de 4 bytes
  • DoubleType : número de punto flotante de 8 bytes
  • DecimalType : un número con un tamaño arbitrario y un punto flotante
  • CounterColumnType : contador de 8 bytes

En cassandra, todas las operaciones de escritura de datos son siempre operaciones de reescritura, es decir, si una columna con la misma clave y nombre que ya existe llega a la familia de columnas, y la marca de tiempo es mayor que la que se guarda, entonces el valor se sobrescribe. . Los valores registrados nunca cambian, solo entran columnas más nuevas con nuevos valores.

Escribirle a Cassandra es más rápido que leer. Esto cambia el enfoque que se toma en el diseño. Si consideramos a Cassandra desde el punto de vista del diseño de un modelo de datos, entonces es más fácil imaginar una familia de columnas no como una tabla, sino como una vista materializada, una estructura que representa los datos de alguna consulta compleja, pero los almacena en disco.

En lugar de intentar componer datos de alguna manera mediante consultas, es mejor tratar de almacenar todo lo que pueda ser necesario para esta consulta en la familia de destino. Es decir, es necesario abordar no desde el lado de las relaciones entre entidades o relaciones entre objetos, sino desde el lado de las consultas: qué campos se requieren seleccionar; en qué orden deben ir los registros; qué datos relacionados con los principales deben solicitarse juntos; todo esto ya debe estar almacenado en la familia de columnas.

El número de columnas en un registro está teóricamente limitado a 2 mil millones. Esta es una breve digresión, y se pueden encontrar más detalles en el artículo sobre técnicas de diseño y optimización. Y ahora profundicemos en el proceso de guardar datos en Cassandra y leerlos.