Para novos requisitos do cliente, precisamos configurar a pesquisa de coluna não-chave. Quero evitar a criação de índice, portanto, avaliar uma nova criação de tabela com a coluna não-chave da tabela original como chave de partição seria melhor OU a exibição materializada seria a melhor opção aqui. Como a nova tabela e a visualização materializada ocupariam o armazenamento (e o cliente acha que é um desperdício de armazenamento, pois estamos salvando os mesmos dados duas vezes por nó), o que mais podemos obter criando a visualização materializada? (Também sua solicitação não é adequada para produção). Por acaso, há outra maneira além da criação de índice/visão materializada/nova tabela com coluna sem chave (da tabela original) como chave de partição para gerenciar esse tipo de situação em que a consulta de pesquisa de coluna sem chave seria introduzida
Visualizações materializadas (MV) são classificadas como um "recurso experimental" no Cassandra porque há cenários em que a visualização fica tão fora de sincronia que a única solução conhecida é descartar e recriar a visualização.
As MVs são desativadas por padrão, e é por isso que você recebe um aviso se tentar criar uma exibição ( CASSANDRA-13959 ). Escrevi sobre isso em Devemos reconsiderar o uso de visualizações materializadas em Cassandra? .
A vantagem dos MVs é que o Cassandra cria e mantém automaticamente a nova tabela para você. No entanto, existem algumas desvantagens, sendo a primeira que as atualizações na exibição são assíncronas, portanto, você não pode ver os dados imediatamente .
Um equívoco é que os dados não são duplicados, o que não é correto. Os dados na tabela base (origem) são duplicados para a exibição, para que não sejam salvos no armazenamento conforme o esperado.
Pela sua postagem, fica claro para mim que você já está ciente de que os índices secundários não são a solução, principalmente se o desempenho for importante, portanto, a única opção que resta é projetar uma tabela para cada consulta de aplicativo. Saúde!