Tipos de Datos Que Tiene Apache Cassandra

Nube Colectiva

hace 2 años

En esta página:

La mayoría de bases de datos tienen similares tipos de datos, pero solo similares, ya que cada una suele tener peculiaridades que las hacen diferentes unas de otras. y Apache Cassandra no es la excepción. Cuando empiezas a desarrollar un proyecto en donde se usa Apache Cassandra, es importante conocer cuales son los tipos de datos que esta base de datos NoSQL soporta, de esta manera evitaremos futuros errores y conflictos a la hora de gestionar los datos mediante operaciones CRUD (Create, Read, Update y Delete). En este Post te compartiré los Tipos de Datos Que Tiene Apache Cassandra, vamos con ello.

Antes de continuar, te invito a escuchar el Podcast: “Que Hacer Cuando Estamos En Casa” y “Consejos Para Entrenar Tu Memoria de Programador” (Anchor Podcast):

Spotify:	Sound Cloud:	Apple Podcasts	Anchor Podcasts

Bien ahora continuemos con el Post: Tipos de Datos Que Tiene Apache Cassandra.

Tipos de Datos en Apache Cassandra

Apache Cassandra cuenta con su propio lenguaje llamado CQL (Cassandra Query Language), el cual es tipado y admite un amplio conjunto de tipos de datos como los tipos nativos, colecciones, tipos definidos por el usuario, tuplas y tipos personalizados.

Tipos Nativos

Los tipos nativos admitios en Cassandra son:

ascii

Es de tipo string y esta conformado por una cadena de caracteres ASCII.

bigint

Es de tipo integer o entero y esta conformado por un número entero de 64 bits firmado largo.

blob

Es de tipo blob y esta conformado por Bytes arbitrarios (sin validación).

boolean

Es de tipo booleano y puede ser true o false.

counter

Es de tipo integer o entero y puede ser una columna de contador (valor con signo de 64 bits).

date

Puede ser de tipo integer o string y representa una fecha (sin valor de hora correspondiente )

decimal

Puede ser de tipo integer o float y representa un número decimal de precisión variable.

double

Puede ser de tipo integer o flat y representa un número con punto flotante IEEE – 754 de 64 bits.

duration

Es de tipo duration y representa una duración con precisión de nano-segundos.

float

Puede ser de tipo integer o float y representa un número con punto flotante IEEE – 754 de 32 bits.

inet

Puede ser de tipo string y representa una dirección IP, ya sea IPv4 (4 bytes de longitud) o IPv6 (16 bytes de longitud), no hay una constante inet, la dirección IP debe ingresarse como string.

int

Es de tipo integer o entero y representa una sesión de 32 bits.

smallint

Es de tipo integer o entero y representa una sesión de 16 bits.

text

Esde tipo string y representa una cadena o string codificada en UTF8.

time

Puede ser de tipo integer o string y representa una hora (sin valor de fecha correspondiente) con precisión de nanosegundos.

timestamp

Puede ser de tipo integer o string y representa una marca de tiempo (fecha y hora) con precisión de milisegundos.

timeuuid

Es de tipo uuid y es generalmente utilizado como una marca de tiempo “libre de conflictos”.

tinyint

Es de tipo integer o entero y representa un sesión de 8 bits.

uuid

Es de tipo uuid y representa un identificador único universal.

varchar

Es de tipo string y representa un string o cadena codificada en UTF8.

varint

Es de tipo integer o entero y representa un númeo entero de precisión arbitraria.

Colecciones

Apache Cassandra admite 3 tipos de colecciones: map, set y list.

map

Es un conjunto (ordenado) de pares clave-valor, donde las claves son únicas y el mapa está ordenado por sus claves. Puedes definir e insertar un map con:


CREATE TABLE usuarios (
   id text PRIMARY KEY,
   nombre text,
   favoritos map<text, text> # Un 'map' de keys y valores de texto 
);

INSERT INTO usuarios (id, nombre, favoritos)
   VALUES ('Jorge', 'Luis Torres', { 'frutas' : 'Manzana', 'banda' : 'Los Beatles' });

CREATE TABLE usuarios (

id text PRIMARY KEY,

nombre text,

favoritos map<text, text> # Un 'map' de keys y valores de texto

);

INSERT INTO usuarios (id, nombre, favoritos)

VALUES ('Jorge', 'Luis Torres', { 'frutas' : 'Manzana', 'banda' : 'Los Beatles' });

set

Es una colección (ordenada) de valores únicos. Puedes definir e insertar un set con:


CREATE TABLE imagenes (
   nombre text PRIMARY KEY,
   propietario text,
   etiquetas set<text> # Un 'set' de valores 
);

INSERT INTO imagenes (nombre, propietario, etiquetas)
   VALUES ('perro.png', 'boby', { 'mascota', 'labrador' });

CREATE TABLE imagenes (

nombre text PRIMARY KEY,

propietario text,

etiquetas set<text> # Un 'set' de valores

);

INSERT INTO imagenes (nombre, propietario, etiquetas)

VALUES ('perro.png', 'boby', { 'mascota', 'labrador' });

list

Es una colección (ordenada) de valores no únicos donde los elementos están ordenados por su posición en la lista. Puedes definir e insertar una lista con:


CREATE TABLE jugadas (
    id text PRIMARY KEY,
    juego text,
    jugadores int,
    puntajes list<int> # Una 'list' de enteros o integers 
)

INSERT INTO jugadas (id, juego, jugadores, puntajes)
           VALUES ('134', 'Super Mario Bros', 2, [15, 12, 7]);

CREATE TABLE jugadas (

id text PRIMARY KEY,

juego text,

jugadores int,

puntajes list<int> # Una 'list' de enteros o integers

)

INSERT INTO jugadas (id, juego, jugadores, puntajes)

VALUES ('134', 'Super Mario Bros', 2, [15, 12, 7]);

Tipos Definidos por el Usuario (UDTs)

Apache Cassandra admite la definición de tipos definidos por el usuario o User-Defined Types (UDTs). Este tipo puede crearse, modificarse y eliminarse mediante create_type_statement, alter_type_statement y drop_type_statement y se describe a continuación. Una vez creado simplemente se hace referencia a un UDT por su nombre.

Creación de un UDT

Un UDT tiene un nombre (usado para declarar columnas de ese tipo) y es un conjunto de campos con nombre y tipo. El nombre de los campos puede ser de cualquier tipo, incluidas las colecciones u otros UDT. Por ejemplo:


CREATE TYPE telefono (
    codigo_pais int,
    numero text,
);

CREATE TYPE direccion (
    calle text,
    ciudad text,
    zip text,
    telefonos map<text, telefono>
);

CREATE TABLE usuario (
    nombre text PRIMARY KEY,
    direcciones map<text, frozen<direccion>>
);

CREATE TYPE telefono (

codigo_pais int,

numero text,

);

CREATE TYPE direccion (

calle text,

ciudad text,

zip text,

telefonos map<text, telefono>

);

CREATE TABLE usuario (

nombre text PRIMARY KEY,

direcciones map<text, frozen<direccion>>

);

Aspectos a tener en cuenta sobre los UDT:

Intentar crear un tipo ya existente generará un error a menos que se use la opción IF NOT EXISTS. Si se usa, la declaración no funcionará si el tipo ya existe.
Un tipo está intrínsecamente vinculado al espacio de claves en el que se crea y solo se puede usar en ese espacio de claves. En el momento de la creación, si el nombre del tipo tiene como prefijo un nombre de espacio de claves, se crea en ese espacio de claves. De lo contrario, se crea en el espacio de claves actual.
A partir de Cassandra, los UDT deben congelarse en la mayoría de los casos, por lo tanto se agrega frozen<direccion> en la definición de la tabla anterior.

Literales UDT

Una ves que se ha creado un tipo definido en uso, el valor se puede ingresar usando el literal UDT. En otras palabras, un literarl UDT es como un ‘map literal’ pero sus claves son los nombres de los campos del tipo. Por ejemplo, se podría insertar en una tabla definida en la sección anterior usando:


INSERT INTO usuario (nombre, direcciones)
   VALUES ('z4 Pr4z3thr2', {
     'casa' : {
        direccion: 'Av. Lunitas 185',
        ciudad: 'Lima',
        zip: '07016',
        telefonos: { 'celular' : { codigo_ciudad: 51, numero: '945102478' },
                  'fijo' : { codigo_ciudad: 51, numero: '...' } }
     },
     'trabajo' : {
        direccion: 'Av. Cien Fuegos 457',
        ciudad: 'Duitama',
        zip: '150461',
        telefonos: { 'fax' : { codigo_ciudad: 60, numero: '...' } }
     }
  }
);

INSERT INTO usuario (nombre, direcciones)

VALUES ('z4 Pr4z3thr2', {

'casa' : {

direccion: 'Av. Lunitas 185',

ciudad: 'Lima',

zip: '07016',

telefonos: { 'celular' : { codigo_ciudad: 51, numero: '945102478' },

'fijo' : { codigo_ciudad: 51, numero: '...' } }

'trabajo' : {

direccion: 'Av. Cien Fuegos 457',

ciudad: 'Duitama',

zip: '150461',

telefonos: { 'fax' : { codigo_ciudad: 60, numero: '...' } }

}

);

Para ser válido, un literal UDT solo puede incluir campos definidos por el tipo del que es un literal, pero puede omitir algunos campos (estos se establecerán en NULL).

Alteración de un UDT

Un tipo definido por el usuario existente se puede modificar usando una declaración ALTER TYPE. Si el tipo no existe, la declaración devolverá un error, a menos que se use IF EXISTS, en cuyo caso la operación no es operativa. Puedes:

Agregar un nuevo campo al tipo ( ALTER TYPE direccion ADD pais text). Ese nuevo campo será NULL para cualquier valor del tipo creado antes de la adición. Si el nuevo campo existe, la declaración devolverá un error, a menos que se use IF NOT EXISTS, en cuyo caso la operación no es operativa.
Renombrar los campos del tipo. Si los campos no existen, la declaración devolverá un error, a menos que se use IF EXISTS, en cuyo caso la operación no se puede realizar.


ALTER TYPE direccion RENAME zip TO codigozip;

ALTER TYPE direccion RENAME zip TO codigozip;

Descartar un UDT

Puedes descartar un tipo definido por el usuario existente mediante una declaración DROP TYPE :


drop_type_statement::= DROP TYPE [ IF EXISTS ] nombre_udt

drop_type_statement::= DROP TYPE [ IF EXISTS ] nombre_udt

Descartar un tipo da como resultado la eliminación inmediata e irreversible de ese tipo. Sin embargo, intentar descartar un tipo que todavía está en uso por otro tipo, tabla o función resultará en un error.

Si el tipo descartado no existe, se devolverá un error a menos que se use IF EXISTS, en cuyo caso la operación no se realiza.

Tuplas

Apache Cassandra también admite tuplas y tipos de tuplas (donde los elementos pueden ser de diferentes tipos). Funcionalmente, las tuplas se pueden considerar como UDT anónimos con campos anónimos, se pueden crear tuplas de la siguiente manera:


CREATE TABLE duraciones (
  evento text,
  duracion tuple<int, text>,
);

INSERT INTO duraciones (evento, duracion) VALUES ('evento3', (4, 'horas'));

CREATE TABLE duraciones (

evento text,

duracion tuple<int, text>,

);

INSERT INTO duraciones (evento, duracion) VALUES ('evento3', (4, 'horas'));

A diferencia de otros tipos compuestos, como colecciones y UDT, una tupla es siempre frozen <frozen> (sin necesidad de la palabra clave frozen) y no es posible actualizar solo algunos elementos de una tupla (sin actualizar toda la tupla). Además, un literal de tupla siempre debe tener el mismo número de valor que el declarado en el tipo del que es una tupla (algunos de esos valores pueden ser nulos, pero deben declararse explícitamente como tales).

Tipos Personalizados

Según la documentación de Apache Cassandra:

Los tipos personalizados existen principalmente con fines de compatibilidad con versiones anteriores y se desaconseja su uso. Su uso es complejo, no fácil de usar y los otros tipos proporcionados, en particular los tipos definidos por el usuario , casi siempre deberían ser suficientes.

Un tipo personalizado es un string que contiene el nombre de la clase de Java que amplía la clase del lado del servidor AbstractType y que Cassandra puede cargar (por lo tanto, debe estar en el CLASSPATH de cada nodo que ejecuta Cassandra). Esa clase definirá qué valores son válidos para el tipo y cómo se ordena el tiempo cuando se usa para una columna de agrupación. Para cualquier otro propósito, el valor de un tipo personalizado es el mismo que el de un blob y, en particular, se puede ingresar utilizando la sintaxis literal blob.

Conclusión

En este post hemos aprendido todos los tipos de datos que existen en la base de datos Apache Cassandra. Esta información la obtuve desde la página oficial de Apache Cassandra, por ende son los tipos de datos oficiales que tiene esta potente base de datos.

Nota (s)

No olvides que debemos usar la Tecnología para hacer cosas Buenas por el Mundo.

Síguenos en nuestras Redes Sociales para que no te pierdas nuestros próximos contenidos.