replicacion - Cassandra: elegir una clave de partición

base de datos cassandra

Question

No estoy seguro de si es mejor, en términos de rendimiento, usar un valor de columna compartido comúnmente (como Country ) como clave de partición para una clave primaria compuesta o un valor de columna bastante único (como Last_Name ).

Mirando la documentación de Cassandra 1.2 sobre los índices , obtengo esto:

" Cuándo usar un índice : los índices incorporados de Cassandra son mejores en una tabla que tiene muchas filas que contienen el valor indexado. Cuantos más valores únicos existan en una columna en particular, más gastos generales tendrá, en promedio, para consultar y mantener el índice. Por ejemplo, supongamos que tiene una tabla de usuarios con mil millones de usuarios y desea buscar usuarios según el estado en el que viven. Muchos usuarios compartirán el mismo valor de columna para el estado (como CA, NY, TX, etc. .). Este sería un buen candidato para un índice " .

" Cuándo no usar un índice : no use un índice para consultar un gran volumen de registros para una pequeña cantidad de resultados. Por ejemplo, si crea un índice en una columna que tiene muchos valores distintos, se realizará una consulta entre los campos. incurrir en muchos busca muy pocos resultados. En la tabla con mil millones de usuarios, buscar usuarios por su dirección de correo electrónico (un valor que es típicamente único para cada usuario) en lugar de por su estado, es probable que sea muy ineficiente. ser más eficiente para mantener manualmente la tabla como una forma de índice en lugar de utilizar el índice incorporado de Cassandra. Para las columnas que contienen datos únicos, a veces es bueno para el rendimiento usar un índice para mayor comodidad, siempre que el volumen de consulta a la tabla que tiene una columna indexada es moderada y no bajo carga constante ".

Mirando los ejemplos de CQL''s SELECT para

" Consultando claves primarias compuestas y resultados de clasificación ", veo algo así como un UUID que se usa como clave de partición ... ¿ lo que indicaría que es preferible usar algo bastante único ?

Answer 1

La indexación en la documentación que escribió se refiere a los índices secundarios. En Casandra hay una diferencia entre los índices primario y secundario . Para un índice secundario, sería malo tener valores muy únicos, sin embargo, para los componentes en una clave primaria esto depende de en qué componente nos estamos enfocando. En la clave principal tenemos estos componentes:

PRIMARY KEY (clave de particionamiento, clustering key_1 ... clustering key_n)

La clave de particionamiento se usa para distribuir datos a través de diferentes nodos, y si desea que sus nodos estén equilibrados (es decir, datos bien distribuidos en cada nodo), entonces desea que su clave de partición sea lo más aleatoria posible. Es por eso que el ejemplo que tiene usa UUID.

La clave de clúster se utiliza para ordenar, de modo que las columnas de consulta con una clave de clúster particular pueden ser más eficientes. Ahí es donde desea que sus valores no sean únicos y donde hubiera un golpe de rendimiento si las filas únicas fueran frecuentes.

Los documentos de cql tienen una buena explicación de lo que está sucediendo.

Answer 2

si usa cql3, dada una familia de columnas:

CREATE TABLE table1 (
  a1 text,
  a2 text,
  b1 text,
  b2 text,
  c1 text,
  c2 text,
  PRIMARY KEY ( (a1, a2), b1, b2) )
);

definiendo una clave primaria ((a1, a2, ...), b1, b2, ...)

Esto implica que:

a1, a2, ... son campos utilizados para crear una clave de fila con el fin de:

• determinar cómo se particionan los datos
• determinar qué se almacena físicamente en una sola fila
• referida como clave de fila o clave de partición

b1, b2, ... son campos de familias de columnas utilizados para agrupar una clave de fila para:

• crear conjuntos lógicos dentro de una sola fila
• Permitir esquemas de búsqueda más flexibles, como rango de rango
• referida como clave de columna o clave de clúster

Todos los campos restantes se multiplexan / duplican efectivamente para cada combinación posible de claves de columna. Aquí debajo funciona un ejemplo sobre claves compuestas con claves de partición y claves de agrupamiento.

Si desea usar consultas de rango, puede usar índices secundarios o (comenzando desde cql3) puede declarar esos campos como claves de agrupamiento. En términos de velocidad tenerlos como clave de agrupamiento creará una sola fila ancha. Esto tiene un impacto en la velocidad, ya que obtendrá varios valores clave de clúster, como:

select * from accounts where Country>''Italy'' and Country<''Spain''

Answer 3

Estoy seguro de que obtendría la respuesta, pero aún así esto puede ayudarlo a comprenderlo mejor.

CREATE TABLE table1 (
  a1 text,
  a2 text,
  b1 text,
  b2 text,
  c1 text,
  c2 text,
  PRIMARY KEY ( (a1, a2), b1, b2) )
);

aquí las claves de partición son (a1, a2) y las claves de fila son b1, b2.

La combinación de ambas claves de partición y fila debe ser única para cada nueva entrada de registro.

la clave primaria anterior se puede definir así.

Node< key, value>

Node<(a1a2), Map< b1b2, otherColumnValues>>

como sabemos, Partition Key es responsable de la distribución de datos entre sus nodos.

Entonces, si está insertando 100 registros en la tabla 1 con las mismas claves de partición y diferentes claves de fila. almacenará datos en el mismo nodo pero en diferentes columnas.

lógicamente podemos representar así.

Node<(a1a2), Map< string1, otherColumnValues>, Map< string2, otherColumnValues> .... Map< string100, otherColumnValues>>

Entonces el registro se almacenará secuencialmente en la memoria.