select * from update_audit where scopeid=35 and formid=78005 and record_link_id=9897;

Como la consulta anterior trabajará internamente en cassandra?

en Esencia, todos los datos de la partición scopeid=35 y formid=78005 será devuelta, y luego filtrado por la etiqueta record_link_id índice. Buscará la entrada record_link_id para 9897, e intentará encontrar entradas que coincidan con las filas devueltas donde scopeid=35y formid=78005. Se devolverá la intersección de las filas para las claves de partición y las claves de índice.

¿Cómo afectará el índice de columna de alta cardinalidad (record_link_id) al rendimiento de la consulta para la consulta anterior?

Los índices de alta cardinalidad esencialmente crean una fila para (casi) cada entrada en la tabla principal. El rendimiento se ve afectado, porque Cassandra está diseñado para realizar lecturas secuenciales de los resultados de las consultas. Una consulta de índice esencialmente obliga a Cassandra a realizar lecturas aleatorias. A medida que aumenta la cardinalidad de su valor indexado, también lo hace el tiempo que se tarda en encontrar el valor consultado.

¿Cassandra tocará todos los nodos para la consulta anterior? ¿Por qué?

No. Solo debe tocar un nodo responsable de la partición scopeid=35 y formid=78005. Los índices también se almacenan localmente, solo contienen entradas que son válidas para el nodo local.

crear un índice sobre columnas de alta cardinalidad será el modelo de datos más rápido y mejor

El problema aquí es que el enfoque no se escala, y será lento si update_audit es un conjunto de datos grande. El MVP Richard Low tiene un gran artículo sobre índices secundarios (El punto Óptimo para la Indexación Secundaria de Cassandra), y particularmente sobre este punto:

Si su tabla era significativamente más grande que la memoria, una consulta sería muy lenta incluso para devolver solo unos pocos miles de resultados. Devolver potencialmente a millones de usuarios sería desastroso a pesar de que parecería ser una consulta eficiente.

En la práctica, esto significa que la indexación es más útil para devolver decenas, tal vez cientos de resultados. Tenga esto en cuenta la próxima vez que considere usar un índice secundario.

Ahora, su enfoque de restringir primero una partición específica ayudará (ya que su partición ciertamente debería caber en la memoria). Pero creo que la opción de mejor rendimiento aquí sería hacer record_link_id una clave de clúster, en lugar de depender de un índice secundario.

Edit

Cómo se puede escalar tener un índice en un índice de baja cardinalidad cuando hay millones de usuarios, incluso cuando proporcionamos la clave primaria

Dependerá de qué tan anchas sean sus filas. Lo complicado de los índices de cardinalidad extremadamente bajos es que el % de las filas devueltas suele ser mayor. Por ejemplo, considere una tabla de fila ancha users. Restringe por la clave de partición en su consulta, pero todavía hay 10.000 filas devueltas. Si su índice está en algo como gender, su consulta tendrá que filtrar aproximadamente la mitad de esas filas, lo que no funcionará bien.

Los índices secundarios tienden a funcionar mejor en (a falta de una mejor descripción) la cardinalidad «en medio de la carretera». Utilizando el ejemplo anterior de una gran fila users de la tabla, un índice de country o state debe realizar mucho mejor que un índice gender (suponiendo que la mayoría de los usuarios no vivimos en el mismo país o estado).

Edite 20180913

Para su respuesta a la 1a pregunta » ¿Cómo funcionará internamente la consulta anterior en cassandra?», ¿sabes cuál es el comportamiento al realizar consultas con paginación?

Considere el siguiente diagrama, tomado de la documentación del controlador Java (v3.6):

Básicamente, la paginación hará que la consulta se rompa y regrese al clúster para la siguiente iteración de resultados. Sería menos probable que se agote el tiempo, pero el rendimiento tenderá a la baja, proporcional al tamaño del conjunto total de resultados y al número de nodos en el clúster.

TL;DR; Cuantos más resultados solicitados se distribuyan en más nodos, más tiempo llevará.