allow - ¿Por qué las súper columnas en Cassandra ya no son favorecidas?

cassandra allow filtering

Question

He leído en la última publicación que las súper columnas no son deseables debido a "problemas de rendimiento", pero en ningún lugar se explica esto.

Luego leo artículos como este que ofrecen maravillosos patrones de indexación usando supercolumnas.

Esto me deja sin idea de cuál es actualmente la mejor manera de indexar en Cassandra.

1. ¿Cuáles son los problemas de rendimiento de las súper columnas?
2. ¿Dónde puedo encontrar las mejores prácticas actuales para indexar?

Answer 1

Las súper columnas adolecen de una serie de problemas, entre los que destaca que es necesario que Cassandra deserialice todas las subcolumnas de una súper columna al realizar una consulta (incluso si el resultado solo devuelve un pequeño subconjunto). Como resultado, existe un límite práctico para la cantidad de subcolumnas por supercolumna que pueden almacenarse antes de que el rendimiento sufra.

En teoría, esto podría arreglarse dentro de Cassandra indexando correctamente las subcolumnas, pero el consenso es que las columnas compuestas son una mejor solución y funcionan sin la complejidad añadida.

La forma más fácil de utilizar columnas compuestas es aprovechar la abstracción que ofrece CQL 3 . Considere el siguiente esquema:

CREATE TABLE messages(
username text,
sent_at timestamp,
message text,
sender text,
PRIMARY KEY(username, sent_at)
);

El nombre de usuario aquí es la clave de fila, pero hemos utilizado una definición PRIMARY KEY que crea una agrupación de clave de fila y la columna sent_at. Esto es importante ya que tiene el efecto de indexar ese atributo.

INSERT INTO messages (username, sent_at, message, sender) VALUES (''bob'', ''2012-08-01 11:42:15'', ''Hi'', ''alice'');
INSERT INTO messages (username, sent_at, message, sender) VALUES (''alice'', ''2012-08-01 11:42:37'', ''Hi yourself'', ''bob'');
INSERT INTO messages (username, sent_at, message, sender) VALUES (''bob'', ''2012-08-01 11:43:00'', ''What are you doing later?'', ''alice'');
INSERT INTO messages (username, sent_at, message, sender) VALUES (''bob'', ''2012-08-01 11:47:14'', ''Bob?'', ''alice'');

Detrás de escena, Cassandra almacenará los datos insertados más arriba de la siguiente manera:

alice: (2012-08-01 11:42:37,message): Hi yourself, (2012-08-01 11:42:37,sender): bob
bob: (2012-08-01 11:42:15,message): Hi, (2012-08-01 11:42:15,sender): alice, (2012-08-01 11:43:00,message): What are you doing later?, (2012-08-01 11:43:00,sender): alice (2012-08-01 11:47:14,message): Bob?, (2012-08-01 11:47:14,sender): alice

Pero usando CQL 3, podemos consultar la "fila" usando un predicado send_at, y obtener un conjunto de resultados tabulares.

SELECT * FROM messages WHERE username = ''bob'' AND sent_at > ''2012-08-01'';
username | sent_at | message | sender
----------+--------------------------+---------------------------+--------
bob | 2012-08-01 11:43:00+0000 | What are you doing later? | alice
bob | 2012-08-01 11:47:14+0000 | Bob? | alice