Diseñando modelos en Cassandra

Requisito previo: Introducción a Cassandra , descripción general del modelado de datos 
En este artículo, vamos a discutir cómo podemos diseñar el modelo en Cassandra. El diseño de modelado es una de las partes clave para cualquier aplicación. Entonces, analicemos cómo podemos hacer un mejor modelo para cualquier aplicación con un ejemplo, veremos cómo podemos hacerlo. 

Como verá, Cassandra tiene un enfoque diferente con respecto al modelado de datos del modelado RDBMS. Podemos ver la diferencia mientras discutimos el modelado de datos. En RDBMS, podemos realizar JOINS mientras creamos tablas y también podemos evitar duplicados mediante el uso de claves externas en tablas relevantes. 

En Cassandra, podemos decir que no es el caso y Cassandra es un sistema distribuido y podemos desnormalizar los datos donde sea necesario. En RDBMS, podemos recuperar y obtener a través de JOIN, mientras que en Cassandra puede ser costoso porque podemos recuperar datos a través de claves de partición y en Cassandra, los datos se distribuyen entre los Nodes de Cassandra. 

Tenga en cuenta los objetivos al diseñar los modelos: 
 

• Distribución uniforme de datos: 
  en un clúster, la distribución uniforme de datos es uno de los objetivos clave, de modo que para una sola columna, la clave principal será la clave de partición y para una clave principal compuesta, la clave de partición será una clave de partición y una clave de clúster. Deberíamos tener una clave principal (PK) sobre la base de la singularidad, por ejemplo, podemos decir como ID, correo electrónico, el nombre de usuario debe elegirse como PK, por lo que, en ese caso, el grupo de Nodes se utilizará por completo.
• Minimizar el número de Lecturas: 
  En Cassandra debemos conocer de antemano las consultas que requerirá el sistema y luego diseñar el modelo en consecuencia. En Cassandra, si una sola consulta está obteniendo datos de varias particiones, esto puede afectar el rendimiento del sistema, lo que hará que el sistema sea lento. En RDBMS, tenemos tanta libertad que podemos crear una consulta después de diseñar primero el esquema que muestra cómo es realmente diferente del modelo no relacional.

Caso de uso: 
número de personas que visitan el sitio web y la administración desea seguir los detalles que se detallan a continuación. Echemos un vistazo. 
 

1. Lista de todos los empleados
2. Lista de todos los dominios.
3. Lista de Empleados por dominios

Ahora, vamos a crear la tabla una por una. Primero, vamos a crear la tabla Dominio. 
 

CREATE TABLE Domain (
 D_id int,
 D_name text,
 D_info text,
 PRIMARY KEY(D_id)
); 

Ahora, vamos a crear la tabla de empleados. 
 

CREATE TABLE Employee (
 username Varchar,
 E_name text,
 E_age int,
 PRIMARY KEY(username)
); 

Ahora, vamos a insertar algunos datos en la tabla Dominio. 
 

INSERT INTO Domain(D_id, D_name, D_info) 
VALUES (1, 'database', '50 member');

INSERT INTO Domain(D_id, D_name, D_info) 
VALUES (2, 'Management', '10 member');

INSERT INTO Domain(D_id, D_name, D_info) 
VALUES (3, 'Networking', '15 member');

INSERT INTO Domain(D_id, D_name, D_info) 
VALUES (4, 'software', '50 member'); 

Ahora, vamos a insertar algunos datos en la tabla de empleados. 
 

INSERT INTO Employee(username, E_name, E_age) 
VALUES ('Alpha007', 'Ashish', 23);

INSERT INTO Employee(username, E_name, E_age) 
VALUES ('Alice007', 'Alice', 23);

INSERT INTO Employee(username, E_name, E_age) 
VALUES ('Bob007', 'Bob', 23); 

En el caso de RDBMS, podemos usar Domain_id como una clave externa en la tabla de empleados y al JOIN podemos obtener los datos, pero estamos diseñando el modelo en Cassandra. entonces, en el caso de Cassandra, tenemos que crear otra tabla que satisfaga la necesidad según el requisito. 
 

CREATE TABLE Employees_by_Domains (
 username varchar,
 E_name text,
 D_name  text,
 E_age int,
 PRIMARY KEY(D_name, E_age)
); 

En la tabla Employees by Domains, la clave principal tiene dos partes, la primera es D_name, que es la clave principal y la segunda es E_age, que es la clave de clúster y los registros están agrupados por E_age. 
 

insert into Employees_by_Domains(username, E_name, D_name, E_age) 
VALUES ('Ashish001', 'Rana', 'Software Er.', 23);

insert into Employees_by_Domains(username, E_name, D_name, E_age) 
VALUES ('Alice007', 'Alice', 'Database', 25);

insert into Employees_by_Domains(username, E_name, D_name, E_age) 
VALUES ('Bob007', 'Bob', 'Networking', 26); 

Ahora, veremos los resultados de cada tabla y obtendremos los datos según el caso de uso. 
Echemos un vistazo. 

Para ver los resultados de la tabla Dominio, utilice la siguiente consulta CQL que se proporciona a continuación. 
 

Select * 
from Domain; 

Producción: 

Para ver los resultados de la tabla de empleados, utilice la siguiente consulta CQL que se proporciona a continuación. 
 

Select * 
from Employee; 

Producción: 

Para ver los resultados de la tabla Employees_by_Domains, use la siguiente consulta CQL que se proporciona a continuación. 
 

Select * 
from Employees_by_Domains; 

Producción: 

Para obtener el valor del token, se utilizó la siguiente consulta de CQL que se proporciona a continuación. 
 

select token(username) 
from Employee; 

Producción: 

Cada valor de token es único para cada nombre de usuario y los tokens se distribuirán entre los Nodes. Cuando ejecutaremos la siguiente consulta: 
 

SELECT * 
FROM Employee 
where username = 'Alpha007' 

Devolverá datos y elegirá el Node en función de este valor de token (-9203506337422437113).