ventajas - sintaxis cassandra

Comprender los gastos generales de almacenamiento de Cassandra

Question

He estado leyendo esta sección de los documentos de Cassandra y encuentro lo siguiente un poco desconcertante:

Determine la sobrecarga de columna:

regular_total_column_size = column_name_size + column_value_size + 15

counter - expiring_total_column_size = column_name_size + column_value_size + 23

Cada columna en Cassandra incurre en 15 bytes de sobrecarga. Dado que cada fila en una tabla puede tener diferentes nombres de columna, así como diferentes números de columnas, los metadatos se almacenan para cada columna. Para las columnas de contador y las columnas que caducan, debe agregar 8 bytes adicionales (23 bytes en total).

La forma en que interpreto lo anterior para un esquema definido en CQL3 como:

CREATE TABLE mykeyspace.mytable(
  id text,
  report_id text,
  subset_id text,
  report_date timestamp,
  start_date timestamp,
  end_date timestamp,
  subset_descr text,
  x int,
  y double,
  z int,
  PRIMARY KEY (id, report_id, subset_id)
);

es que cada fila contendrá los metadatos para los nombres de columna, por ejemplo, las cadenas report_date , report_date , report_date , etc. y su tipo junto con los datos. Sin embargo, no es claro para mí lo que significa que cada fila en una tabla puede tener diferentes nombres de columna. Esto me suena mal, dado que el esquema anterior es totalmente estático , es decir, Cassandra 2.0 seguramente se quejará si intento escribir:

INSERT INTO mykeyspace.mytable (id, report_id , subset_id, x, y, z, w) 
VALUES ( ''asd'',''qwe'',''rty'',100,1.234,12, 123.123);

Bad Request: Unknown identifier w

Ahora me parece que los nombres de las columnas son fijos dado este esquema de tabla y, por lo tanto, no es necesario que los metadatos se almacenen por cada fila. Supongo que el fraseo en la documentación está desactualizado (es lo mismo que Cassandra 1.2) o estoy malinterpretando algún concepto central que funciona aquí.

¿Alguien puede aclarar? En pocas palabras: ¿tengo que preocuparme por la longitud de los nombres de mis columnas o no?

Hemos estado jugando a lo seguro y usamos nombres de personajes individuales siempre que fue posible (por lo que las columnas anteriores serían en realidad i , r , s , dr , ds , de , sd , ...), pero no es tan ilegible y puede ser confuso trabajar con.

Answer 1

La forma más fácil de descubrir qué sucede en situaciones como esta es verificar la representación de sus datos en sstable2json (cassandra / bin). Esto le mostrará qué termina realmente guardado en el disco.

Aquí está el ejemplo para su situación

 [
 {"key": "4b6579","columns": [
       ["rid1:ssid1:","",1401469033325000],
       ["rid1:ssid1:end_date","2004-10-03 00:00:00-0700",1401469033325000],
       ["rid1:ssid1:report_date","2004-10-03 00:00:00-0700",1401469033325000],
       ["rid1:ssid1:start_date","2004-10-03 00:00:00-0700",1401469033325000], 
       ["rid1:ssid1:subset_descr","descr",1401469033325000],
       ["rid1:ssid1:x","1",1401469033325000], 
       ["rid1:ssid1:y","5.5",1401469033325000],
       ["rid1:ssid1:z","1",1401469033325000],
       ["rid2:ssid2:","",1401469938599000],
       ["rid2:ssid2:end_date", "2004-10-03 00:00:00-0700",1401469938599000],
       ["rid2:ssid2:report_date","2004-10-03 00:00:00-0700",1401469938599000],
       ["rid2:ssid2:start_date","2004-10-03 00:00:00-0700",1401469938599000], 
       ["rid2:ssid2:subset_descr","descr",1401469938599000],
       ["rid2:ssid2:x","1",1401469938599000],
       ["rid2:ssid2:y","5.5",1401469938599000],
       ["rid2:ssid2:z","1",1401469938599000]
 }
 ]

El valor de la clave de partición se guarda una vez por partición (por sstable) como puede ver arriba, el nombre de la columna en este caso no importa en absoluto ya que está implícito dada la tabla. Los nombres de columna para las columnas de clúster tampoco están presentes porque con C * no está permitido insertar sin especificar todas las partes de la clave.

Lo que queda, sin embargo, tiene el nombre de columna, esto es necesario en caso de que se realice una actualización parcial de una fila para que pueda guardarse sin el resto de la información de la fila. Podría imaginarse una actualización de un campo de columna individual en una fila, para indicar en qué campo es C * actualmente utiliza el nombre de la columna, pero hay entradas para cambiar esto a una representación más pequeña. https://issues.apache.org/jira/browse/CASSANDRA-4175

Para generar esto

cqlsh
CREATE TABLE mykeyspace.mytable(   id text,   report_id text,   subset_id text,   report_date timestamp,   start_date timestamp,   end_date timestamp,   subset_descr text,   x int,   y double,   z int,   PRIMARY KEY (id, report_id, subset_id) );
INSERT INTO mykeyspace.mytable (id, report_id , subset_id , report_date , start_date , end_date , subset_descr ,x, y, z) VALUES ( ''Key'', ''rid1'',''ssid1'', ''2004-10-03'',''2004-10-03'',''2004-10-03'',''descr'',1,5.5,1);
INSERT INTO mykeyspace.mytable (id, report_id , subset_id , report_date , start_date , end_date , subset_descr ,x, y, z) VALUES ( ''Key'', ''rid2'',''ssid2'', ''2004-10-03'',''2004-10-03'',''2004-10-03'',''descr'',1,5.5,1);
exit;
nodetool flush
bin/sstable2json $DATA_DIR/mytable/mykeyspace-mytable-jb-1-Data.db