Modelo de datos de Cassandra para una aplicación de mensajería simple

Solución:

Sí, siempre es una lucha adaptarse a las limitaciones de Cassandra cuando proviene de una base de datos relacional. Dado que todavía no tenemos el lujo de hacer uniones en Cassandra, a menudo querrás meter todo lo que puedas en una sola mesa. En su caso, esa sería la tabla users_by_username.

Hay algunas características de Cassandra que deberían permitirle hacer eso.

Como es nuevo en Cassandra, probablemente podría usar Cassandra 3.0, que actualmente se encuentra en versión beta. En 3.0 hay una característica interesante llamada vistas materializadas. Esto le permitiría tener users_by_username como una tabla base y crear users_by_email como una vista materializada. Luego, Cassandra actualizará la vista automáticamente cada vez que actualice la tabla base.

Otra característica que le ayudará son los tipos definidos por el usuario (en C * 2.1 y posteriores). En lugar de crear tablas separadas para seguidores y mensajes, puede crear la estructura de esos como UDT y luego en la tabla de usuarios mantener listas de esos tipos.

Entonces, una vista simplificada de su esquema podría ser así (no estoy mostrando algunos de los campos como marcas de tiempo para mantener esto simple, pero son fáciles de agregar).

Primero cree sus UDT:

CREATE TYPE user_follows (
    followed_username text,
    street text,
);

CREATE TYPE msg (
    from_user text,
    body text
);

A continuación creamos su tabla base:

CREATE TABLE users_by_username (
    username text PRIMARY KEY,
    email text,
    password text,
    follows list<frozen<user_follows>>,
    followed_by list<frozen<user_follows>>,
    new_messages list<frozen<msg>>,
    old_messages list<frozen<msg>>
);

Ahora creamos una vista materializada particionada por correo electrónico:

CREATE MATERIALIZED VIEW users_by_email AS
    SELECT username, password, follows, new_messages, old_messages FROM users_by_username
    WHERE email IS NOT NULL AND password IS NOT NULL AND follows IS NOT NULL AND new_messages IS NOT NULL
    PRIMARY KEY (email, username);

Ahora demos una vuelta y veamos qué puede hacer. Creemos un usuario:

INSERT INTO users_by_username (username , email , password )
    VALUES ( 'someuser', '[email protected]', 'somepassword');

Deje que el usuario siga a otro usuario:

UPDATE users_by_username SET follows = [{followed_username: 'followme2', street: 'mystreet2'}] + follows
    WHERE username="someuser";

Enviemos un mensaje al usuario:

UPDATE users_by_username SET new_messages = [{from_user: 'auser', body: 'hi someuser!'}] + new_messages
    WHERE username="someuser";

Ahora veamos qué hay en la tabla:

SELECT * FROM users_by_username ;

 username | email             | followed_by | follows                                                 | new_messages                                 | old_messages | password
----------+-------------------+-------------+---------------------------------------------------------+----------------------------------------------+--------------+--------------
 someuser | [email protected] |        null | [{followed_username: 'followme2', street: 'mystreet2'}] | [{from_user: 'auser', body: 'hi someuser!'}] |         null | somepassword

Ahora verifiquemos que nuestra vista materializada esté funcionando:

SELECT new_messages, old_messages FROM users_by_email WHERE email="[email protected]"; 

 new_messages                                 | old_messages
----------------------------------------------+--------------
 [{from_user: 'auser', body: 'hi someuser!'}] |         null

Ahora leamos el correo electrónico y pongámoslo en los mensajes antiguos:

BEGIN BATCH
    DELETE new_messages[0] FROM users_by_username WHERE username="someuser"
    UPDATE users_by_username SET old_messages = [{from_user: 'auser', body: 'hi someuser!'}] + old_messages where username="someuser"
APPLY BATCH;

 SELECT new_messages, old_messages FROM users_by_email WHERE email="[email protected]";

 new_messages | old_messages
--------------+----------------------------------------------
         null | [{from_user: 'auser', body: 'hi someuser!'}]

Con suerte, eso le dará algunas ideas que puede utilizar. Eche un vistazo a la documentación sobre colecciones (es decir, listas, mapas y conjuntos), ya que realmente pueden ayudarlo a mantener más información en una tabla y son como tablas dentro de una tabla.

Para los principiantes en el modelado de datos cassandra o noSQL, existe un proceso involucrado en el modelado de datos de su aplicación, como

1- Comprende tus datos, diseña un diagrama conceptual
2- Enumere todas sus necesidades en detalle
3- Mapee sus consultas utilizando reglas y patrones definidos, más adecuados para cassandra
4- Crea un diseño lógico, tabla con campos derivados de consultas
5- Ahora crea un esquema y prueba su aceptación.

si lo modelamos bien, entonces es fácil manejar problemas como nuevas consultas complejas, sobrecarga de datos, consistencia de datos setc.

Después de realizar esta capacitación gratuita en modelado de datos en línea, obtendrá más claridad

https://academy.datastax.com/courses/ds220-data-modeling

¡Buena suerte!

---

---

Utiliza Nuestro Buscador