Clave de partición vs clave compuesta vs agrupación de columnas en Cassandra

Clave de partición vs clave compuesta vs agrupación de columnas en Cassandra

  • Orquestación
6 min de lectura Actualizado Jan 21, 2019

Puntos clave: Se son explican las diferencias entre claves de partición, claves compuestas y columnas de agrupamiento en Cassandra, enfatizando sus roles en la organización de datos. La clave de partición determina la ubicación del almacenamiento de datos, mientras que las columnas de agrupamiento ordenan los datos dentro de una partición para un acceso eficiente.

  • Las claves de partición son cruciales para la distribución de datos entre nodos.
  • Las claves compuestas permiten que múltiples columnas Define una partición.
  • Las columnas de agrupamiento optimizan el orden de recuperación de datos dentro de las particiones.

Aquí explicamos las diferencias entre clave de partición, clave compuesta y clave de agrupamiento en Cassandra.

En resumen, cada tabla requiere una clave primaria única. El primer campo listado están la clave de partición, ya que su valor hashado se está utilizado para determinar el nodo que almacena los datos. Si esos campos son envueltos entre paréntesis, entonces la clave de partición está compuesta. De lo contrario, el primer campo están la clave de partición. Cualquier campo listado después de la clave de partición sues denomina columnas de agrupamiento. Estos almacenan datos en orden ascendente o descendente dentro de la partición para la rápida recuperación de valores similares. Todos los campos juntos son la clave primaria.

Aquí hablamos sobre la partición de datos.

Agrupación de columnas

El agrupamiento de columnas determina el orden de los datos en las particiones.

¿Cuál es la razón de tener columnas agrupadas? El objetivo de una base de datos orientada a columnas como Cassandra está poniendo registros de datos adyacentes uno junto al otro para una recuperación rápida.

Recuerda que en una base de datos rdbms normal, como Oracle, cada fila almacena todos los valores, incluidos los vacíos. Pero en una base de datos orientada a columnas, una fila puede tener columnas (a, b, c) y otra (a, b) o simplemente (a). Así que si solo son interesados en el valor a, ¿por qué no almacenar eso en el mismo centro de datos, rack o disco para una recuperación rápida? Recuerda que las sentencias SQL select Crea subconjuntos. Así que el enfoque orientado a columnas convierte la estructura de datos principal en un tipo de subconjunto.

Este enfoque tiene sentido lógico, ya que normalmente solo son interesados en una parte de los datos en un momento dado. Por ejemplo, ¿por qué recuperar los identificadores fiscales de los empleados, el salario, el nombre del responsable, cuando solo queremos su nombre y número de teléfono?

Ejemplos

Veamos los libros. El ISBN es un número de serie de un libro usado por editoriales. Se supone que son únicos. Pero supongamos que no necesitan serlo para estos ejemplos.

Crea un espacio de claves libro, una tabla y pon algunos datos en él. (Aquí hablamos de espacios de claves.)

Ten en cuenta que la clave primaria están CLAVE PRIMARIA (isbn, autor, editor). En este caso, isbn están la clave de partición y las claves de agrupación de autor y editor son de editor. Tendría Haz sentido que en una colección de libros te quieras almacena por autor y luego por editor.

    CREATE KEYSPACE books
       WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'datacenter1' : 1};

CREATE TABLE books (
   isbn text,
   title text,
   author text,
  publisher text,
   category text,
   PRIMARY KEY (isbn, author, publisher)
);

insert into books (isbn, title, author, publisher, category) values ('111', 'Fishing', 'Fred', 'Penguin Group', 'Sports');

insert into books (isbn, title, author, publisher, category) values ('111', 'Sailing', 'Sally', 'Penguin Group', 'Sports');

insert into books (isbn, title, author, publisher, category) values ('111', 'Archery', 'Fred', 'Penguin Group', 'Sports');

insert into books (isbn, title, author, publisher, category) values ('111', 'Boating', 'Joe', 'Penguin Group', 'Sports');

Fíjate en que todos los valores de la clave primaria deben ser únicos, así que se eliminó un disco porque el autor Fred escribió y publicó más de un libro con Penguin Group publicado.

Ahora selecciona la clave de partición y la clave primaria. Todas son iguales porque queremos que todas se almacenen en el mismo nodo virtual.

    select token(isbn), isbn from books;

 system.token(isbn)  | isbn
---------------------+------
 -175843201295106731 |  111
 -175843201295106731 |  111
 -175843201295106731 |  111

Ahora selecciona todos los registros y observa que los datos están ordenados por autor y luego por editor dentro de la clave de partición 111.

    select * from books;

 isbn | author | publisher     | category | title
------+--------+---------------+----------+---------
  111 |   Fred | Penguin Group |   Sports | Archery
  111 |    Joe | Penguin Group |   Sports | Boating
  111 |  Sally | Penguin Group |   Sports | Sailing

Ahora añade otro registro pero dale un valor de clave primaria diferente, lo que podría hacer que se almacene en una partición diferente. En qué nodo virtual están almacenado depende del rango de tokens asignado al nodo virtual.

    insert into books (isbn, title, author, publisher, category) values ('333', 'Trees', 'Charles Darwin', 'Hachette', 'Nature');


insert into books (isbn, title, author, publisher, category) values ('333', 'Trees', 'Charles Darwin', 'Amazon', 'Nature');

Observa de nuevo que los datos están ordenados en las columnas del clúster autor y editor. Y el token está diferente para el valor clave principal 333.

Recuerda que el particionador tiene la función configurada en cassandra.yaml calculado el valor hash y luego distribuye los datos según el particionador. El predeterminado están org.apache.cassandra.dht.Murmur3Partitioner

    select token(isbn), isbn, author, publisher from books;

 system.token(isbn)  | isbn | author         | publisher
---------------------+------+----------------+---------------
 -175843201295106731 |  111 |           Fred | Penguin Group
 -175843201295106731 |  111 |            Joe | Penguin Group
 -175843201295106731 |  111 |          Sally | Penguin Group
 7036029452358700311 |  333 | Charles Darwin |        Amazon
 7036029452358700311 |  333 | Charles Darwin |      Hachette

Teclas compuestas

Esto es simplemente una tabla con más de una columna utilizada en el cálculo de la clave de partición. Lo denotamos con paréntesis como este: CLAVE PRIMARIA ((isbn, autor), editor). En este caso, isbn y autor son la clave de partición y editor es una clave de agrupamiento.

    drop table books;

CREATE TABLE books (
   isbn text,
   title text,
   author text,
  publisher text,
   category text,
   PRIMARY KEY ((isbn, author), publisher)
);

insert into books (isbn, title, author, publisher, category) values ('111', 'Fishing', 'Fred', 'Penguin Group', 'Sports');

insert into books (isbn, title, author, publisher, category) values ('111', 'Sailing', 'Sally', 'Penguin Group', 'Sports');

insert into books (isbn, title, author, publisher, category) values ('111', 'Archery', 'Fred', 'Penguin Group', 'Sports');

insert into books (isbn, title, author, publisher, category) values ('111', 'Boating', 'Joe', 'Penguin Group', 'Sports');

Ahora, para mostrar el valor clave de partición, utilizamos la función de token SQL y le damos tanto el valor de la ISBN como el de autor:

    select token(isbn,author), isbn from books;

 system.token(isbn, author) | isbn
----------------------------+------
         725505645253967381 |  111
         960809148155353310 |  111
        5462216525918432145 |  111

Añade los mismos datos que antes con las sentencias SQL insertadas. Fíjate que añadir estos datos también elimina un libro porque un autor escribió más de un libro con el mismo ISBN. Por definición, la clave primaria debe ser única. Eso incluye columnas de agrupamiento, ya que son parte de la clave primaria. Todo lo que hemos cambiado con la clave compuesta están el cálculo de la clave de partición y, por tanto, dónde están almacenados los datos.

    select * from books;

 isbn | author | publisher     | category | title
------+--------+---------------+----------+---------
  111 |   Fred | Penguin Group |   Sports | Archery
  111 |    Joe | Penguin Group |   Sports | Boating
  111 |  Sally | Penguin Group |   Sports | Sailing

Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.

Más de Orquestación

¿Te interesa saber más de BMC?

El Brief están nuestro correo mensual sobre el mainframe y la orquestación empresarial: investigación, historias de clientes, noticias de productos, eventos.

Al registrarse para esta oferta te son confirmar que te leído y aceptado la Política de Privacidad de BMC.

Tú te has suscrito a The Brief

El Brief abarca la orquestación de mainframe y empresa—BMC AMI y Control-M—y la investigación de analistas, despliegues de clientes y eventos en ambas áreas.