Icono del sitio Blog de Programación y Desarrollo – Nube Colectiva

Tipos de Datos Que Tiene Apache Cassandra

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“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:

set

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

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:

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:


Aspectos a tener en cuenta sobre los UDT:

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:


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:

Descartar un UDT

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


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:


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)

 

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

Salir de la versión móvil