Por que estou lendo muitas lápides na tabela Cassandra, embora meu padrão de acesso deva evitá-las?

Question

Eu sei que esta não é a melhor maneira de usar o Cassandra, mas o tipo dos meus dados exige a leitura de todos os dados da última semana.No entanto, ao usar tipos de coleção em CQL3, encontrei certas limitações que me impedem de fazer consultas normais de intervalo de datas.

Então eu configurei o Cassandra (atualmente nó único, provavelmente mais no futuro) com a seguinte tabela

CREATE TABLE cache (tag text, id int, tags map<text,text>, 
  PRIMARY KEY (tag, id) );
ALTER TABLE cache WITH GC_GRACE_SECONDS = 0;

Estou inserindo com um TTL de uma semana para remover automaticamente os itens do Cache.

Tentei seguir as sugestões mencionadas em Este artigo para evitar a leitura de muitas lápides selecionando por "id mínimo", que persisto em outro lugar para evitar a leitura de dados antigos:

SELECT * FROM cache WHERE tag = ? AND id >= ?

O id é basicamente algum tipo de carimbo de data/hora que aumenta constantemente, ou seja,Eu apenas insiro valores mais altos ao longo do tempo e removo constantemente os IDs mais antigos da tabela.

Mas ainda recebo avisos sobre limites atingidos

WARN 08:59:06,286 Read 5001 live and 5702 tombstoned cells in cache (see tombstone_warn_threshold)

E se eu não executar a compactação/limpeza manual regularmente, recebo exceções e as consultas falham.

No entanto, com base no meu entendimento dos artigos e da documentação, devo evitar a maioria, se não todas as lápides aqui, ao consultar a igualdade da tag, o que permite que Cassandra procure apenas essas áreas e uso um ID mínimo que permite a Cassandra iniciar lendo somente após a maioria das lápides, então por que ainda há avisos/exceções de lápides relatados?

Answer 1

O par k/v do mapa é na verdade uma coluna (nome, valor e carimbo de data/hora):portanto, se você estiver emitindo muitas exclusões de elementos do mapa (expirar por TTL também é o caso) - esta é a fonte deste aviso.Porque você ainda está lendo mapas completos (com muitas lápides).Além disso, a configuração de TTL no mapa é aplicada por elemento.

Segundo, isso é multiplicado por >= predicado na sua consulta selecionada.

Se for esse o caso, você deve remodelar seu padrão de acesso a dados para usar apenas relações EQ na consulta SELECT e no bump id mais frequentemente.Além disso, esse padrão de acesso permitirá que você se livre do agrupamento de parte de sua CHAVE PRIMÁRIA.

Então, se você não fizer muitas exclusões nesse mapa, você pode tentar usar tag text, time timeuuid, name text, data text modele e corte-o precisamente por tempo.