Cassandra Modelo de datos con ejemplo de base de datos simple

Aunque Cassandra El lenguaje de consulta se asemeja a SQL lenguaje, sus métodos de modelado de datos son totalmente diferentes.

In Cassandra, un modelo de datos incorrecto puede degradar el rendimiento, especialmente cuando los usuarios intentan implementar los conceptos de RDBMS en Cassandra. Lo mejor es tener en cuenta algunas reglas que se detallan a continuación.

Cassandra Reglas del modelo de datos

In Cassandra, las escrituras no son caras. Cassandra no admite uniones, grupos por, cláusulas OR, agregaciones, etc. Por lo tanto, debe almacenar sus datos de tal manera que sean completamente recuperables. Por lo tanto, estas reglas deben tenerse en cuenta al modelar datos en Cassandra.

Maximizar el número de escrituras

In Cassandra, las escrituras son muy baratas. Cassandra Está optimizado para un alto rendimiento de escritura. Por lo tanto, intente maximizar sus escrituras para obtener un mejor rendimiento de lectura y disponibilidad de datos. Existe una compensación entre la escritura y la lectura de datos. Así que optimice su rendimiento de lectura de datos maximizando el número de escrituras.

Maximice la duplicación de datos

La desnormalización y duplicación de datos son de facto Cassandra. El espacio en disco no es más caro que la memoria, el procesamiento de la CPU y la operación de IO. Como Cassandra Es una base de datos distribuida, por lo que la duplicación de datos proporciona disponibilidad instantánea de datos y ningún punto único de falla.

Cassandra Objetivos del modelado de datos

Debes tener los siguientes objetivos al modelar datos en Cassandra:

Distribuya los datos de manera uniforme en todo el Cluster

Quiere una cantidad igual de datos en cada nodo de Cassandra ClusterLos datos se distribuyen entre los distintos nodos según las claves de partición, que constituyen la primera parte de la clave primaria. Por lo tanto, conviene elegir una columna de alta cardinalidad como clave de partición para distribuir los datos de manera uniforme en el clúster.

Minimizar el número de particiones leídas al consultar datos

La partición es un grupo de registros con la misma clave de partición. Cuando se emite la consulta de lectura, recopila datos de diferentes nodos de diferentes particiones.

Si habrá muchas particiones, entonces es necesario visitar todas ellas para recopilar los datos de la consulta.

Esto no significa que no se deban crear particiones. Si sus datos son muy grandes, no puede almacenar esa enorme cantidad de datos en una sola partición. La partición única se ralentizará.

Intente elegir un número equilibrado de particiones.

Buena clave primaria en Cassandra

Ambos objetivos se reducen a una sola decisión, por lo que los dos esquemas que aparecen a continuación muestran la misma tabla con una clave deficiente y, posteriormente, con una clave correcta.

Veamos un ejemplo y descubramos qué clave primaria es la más adecuada.

Aquí está la tabla MusicPlaylist.

CREATE TABLE MusicPlaylist (
    SongId int,
    SongName text,
    Year int,
    Singer text,
    PRIMARY KEY (SongId, SongName)
);

En el ejemplo anterior, tabla MusicPlaylist,

• SongId es la clave de partición y
• SongName es la columna de agrupamiento
• Los datos se agruparán según el nombre de la canción. Solo se creará una partición por cada SongId, y dado que cada canción tiene un identificador único, cada partición contendrá una sola fila.

La recuperación de datos será lenta con este modelo de datos debido a una clave primaria incorrecta.

Aquí hay otra tabla MusicPlaylist.

CREATE TABLE MusicPlaylist (
    SongId int,
    SongName text,
    Year int,
    Singer text,
    PRIMARY KEY ((SongId, Year), SongName)
);

En el ejemplo anterior, tabla MusicPlaylist,

• SongId y Year son la clave de partición, y
• SongName es la columna de agrupamiento.
• Los datos se agruparán en función del nombre de la canción. En esta tabla, cada año, se creará una nueva partición. Todas las canciones del año estarán en el mismo nodo. Esta clave principal será muy útil para los datos.

Nuestra recuperación de datos será rápida con este modelo de datos.

Modele sus datos en Cassandra

A la hora de modelar tus consultas debes tener en cuenta lo siguiente:

Determine qué consultas desea respaldar

En primer lugar, determine qué consultas desea.

Por ejemplo, ¿lo necesitas?

• Une
• Agrupar por
• Filtrar en qué columna, etc.

Crea una tabla según tus consultas.

Crea una tabla según tus consultas. Cree una tabla que satisfaga sus consultas. Intente crear una tabla de tal manera que sea necesario leer un número mínimo de particiones.

Las tres secciones que siguen aplican ese principio a los tres tipos de relaciones que se encuentran en casi todos los esquemas.

Manejo de relaciones uno a uno en Cassandra

La relación uno a uno significa que dos tablas tienen correspondencia uno a uno. Por ejemplo, el estudiante puede registrarse solo en un curso y quiero buscar en un estudiante en qué curso está registrado un estudiante en particular.

Entonces, en este caso, el esquema de su tabla debe abarcar todos los detalles del estudiante correspondiente a ese curso en particular, como el nombre del curso, el número de registro del estudiante, el nombre del estudiante, etc.

El diagrama anterior muestra una única tabla que atiende la consulta, ya que cada estudiante está asociado a un único curso.

CREATE TABLE Student_Course (
    Student_rollno int PRIMARY KEY,
    Student_name text,
    Course_name text
);

Dado que Student_rollno es la clave de partición, una búsqueda por número de matrícula lee exactamente una partición.

Manejo de relaciones de uno a muchos en Cassandra

Relaciones de uno a muchos significa tener correspondencia de uno a muchos entre dos tablas.

Por ejemplo, muchos estudiantes pueden estudiar un curso. Quiero buscar a todos los estudiantes que están estudiando un curso en particular.

Entonces, al consultar el nombre del curso, tendré muchos nombres de estudiantes que estudiarán un curso en particular.

En este caso, el nombre del curso se convierte en la clave de partición, de modo que cada estudiante de un curso se ubica en la misma partición, y el número de matrícula se convierte en la columna de agrupación, de modo que cada estudiante permanece en una fila distinta.

CREATE TABLE Student_Course (
    Course_name text,
    Student_rollno int,
    Student_name text,
    PRIMARY KEY (Course_name, Student_rollno)
);

Puedo recuperar todos los estudiantes de un curso en particular mediante la siguiente consulta.

SELECT * FROM Student_Course WHERE Course_name = 'Course Name';

Manejo de relaciones de muchos a muchos en Cassandra

Relaciones de muchos a muchos significa tener correspondencia de muchos a muchos entre dos tablas.

Por ejemplo, muchos estudiantes pueden estudiar un curso y un estudiante también puede estudiar muchos cursos.

Quiero buscar a todos los estudiantes que están estudiando un curso en particular. Además, quiero buscar todo el curso que está estudiando un estudiante en particular.

En este caso, tendré dos tablas, es decir, dividiré el problema en dos casos. Esta es la ilustración más clara de la regla de duplicación: los mismos datos se escriben dos veces para que cada consulta lea una partición.

Primero, crearé una tabla mediante la cual podrá encontrar cursos de un estudiante en particular.

CREATE TABLE Student_Course (
    Student_rollno int,
    Course_name text,
    Student_name text,
    PRIMARY KEY (Student_rollno, Course_name)
);

Puedo encontrar todos los cursos de un estudiante en particular mediante la siguiente consulta.

SELECT * FROM Student_Course WHERE Student_rollno = 101;

En segundo lugar, crearé una tabla mediante la cual podrás encontrar cuántos estudiantes están estudiando un curso en particular.

CREATE TABLE Course_Student (
    Course_name text,
    Student_rollno int,
    Student_name text,
    PRIMARY KEY (Course_name, Student_rollno)
);

Puedo encontrar un estudiante en un curso particular mediante la siguiente consulta.

SELECT * FROM Course_Student WHERE Course_name = 'Cassandra';

Ambas tablas deben actualizarse cada vez que un estudiante se inscribe en un curso, normalmente dentro de un único lote registrado para que las dos copias se mantengan sincronizadas.

Preguntas frecuentes sobre bancarrota Cassandra Errores en el modelado de datos

La mayoría de los esquemas deficientes repiten el mismo puñado de errores, y cada uno traces volver a un hábito heredado del diseño relacional.

• Particiones ilimitadas: Al elegir una clave de partición, como el nombre de un país, se agrupan millones de filas en una sola partición. Añada un intervalo de tiempo, por ejemplo (país, mes), para mantener las particiones dentro de un tamaño razonable.
• Claves de cardinalidad muy baja: Una clave de partición con solo unos pocos valores posibles, como un indicador de estado, concentra todo el tráfico en unos pocos nodos y deja el resto inactivo.
• Utilizar ALLOW FILTERING para que una consulta funcione: Analiza cada partición y oculta un problema de modelado. Si una consulta lo requiere, el esquema necesita otra tabla.
• Modelado de entidades en lugar de consultas: Crear una tabla de estudiantes y una tabla de cursos, para luego intentar combinarlas en la aplicación, contradice el propósito del diseño.
• Eliminaciones y sobrescrituras frecuentes: Cada eliminación escribe una marca de eliminación que debe leerse y omitirse hasta que la compactación la elimine, lo que ralentiza las lecturas en particiones de uso frecuente.

Evitar estos elementos mantiene el esquema alineado con las reglas indicadas en la parte superior de esta página y con los contrastes relacionales resumidos a continuación.

Diferencia entre RDBMS y Cassandra Modelado de datos

Estas decisiones de esquema se aplican en la práctica en el Cassandra mesa y espacio de teclas Tutoriales.

Preguntas Frecuentes