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

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 de leer artículos como this one que dan patrones de indexación maravillosas Si se utilizan columnas.

Esto me deja sin idea de lo que es actualmente la mejor manera de hacer indexación en Cassandra.

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

Answer 1

Las súper columnas adolecen de una serie de problemas, entre los cuales 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 una pequeña 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 ser fijado dentro de Cassandra indexando adecuadamente sub-columnas, pero el consenso es que las columnas compuestas son una mejor solución, y trabajan sin la complejidad añadida.

La manera más fácil de hacer uso de columnas compuestas es tomar ventaja de la abstracción que proporciona CQL 3. Considere el siguiente esquema:

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

nombre de usuario aquí está 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 las escenas Cassandra almacenará lo anterior se inserta algo datos 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 el uso de CQL 3, se puede consultar la "fila" por medio de un predicado sent_at, y volver tabular conjunto resultante.

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