cassandra - índices secundarios máximos en una familia de columnas

data-modeling

Question

¿Es un problema de rendimiento si tenemos dos o más índices secundarios en una familia de columnas? Tengo orderid, city y shipmenttype. Así que pensé en crear la clave principal en los índices ordenados y secundarios en city y shipmenttype. Y use una combinación de columnas secundarias de índice mientras consulta. ¿Es eso un mal modelado?

Answer 1

Considere los datos que se colocarán en el índice secundario. Al mirar los documentos , quiere evitar columnas con alta cardinalidad. Si los valores de su ciudad y tipo de envío varían mucho (o por el contrario, de manera similar), entonces un índice secundario puede no ser el adecuado.

Mire para mantener potencialmente una tabla separada con esta información. Esto se comportaría como un índice de tipo manual, pero tiene el beneficio adicional de comportarse como se espera de una tabla de Cassandra. Cuando cree o actualice registros, asegúrese de actualizar esta tabla de índice. Las escrituras son baratas, realizar múltiples escrituras a lo largo de la actualización de un registro no es algo inaudito.

Al observar sus patrones de acceso, ¿usará la clave de partición como parte de la cláusula WHERE o solo los índices secundarios?

Si realiza una consulta en los índices secundarios junto con la clave de la partición, obtendrá un mejor rendimiento que cuando consulta con índices secundarios.

Por ejemplo, con WHERE orderid = ''foo'' AND shipmenttype = ''bar'' la solicitud solo se enviará a los nodos responsables de la partición donde se almacena foo . Luego se consultará el índice secundario para shipmenttype = ''bar'' y se devolverán sus resultados.

Cuando ejecuta una consulta con WHERE shipmenttype = ''bar'' la consulta se envía a todos los nodos del clúster antes de consultar los índices secundarios para buscar filas. Esto es menos que ideal.

Además, si consulta contra múltiples índices secundarios con una única solicitud, debe usar ALLOW FILTERING . Esto solo consultará UN índice secundario durante su solicitud, generalmente el más específico de los índices a los que se hace referencia. Esto causará un golpe de rendimiento ya que todos los registros devueltos al verificar el primer índice requerirán la verificación de los otros valores enumerados en su cláusula WHERE .

Si está utilizando un índice secundario, siempre intente incluir la parte de la clave de partición de la consulta. En segundo lugar, NO use índices secundarios múltiples cuando consulte una tabla, esto causará un gran golpe de rendimiento.

En última instancia, su rendimiento está determinado por la forma en que construye sus consultas frente a la partición y los índices secundarios.