Recursos do LindormTable — como TTL, TTL no nível de célula, versionamento de dados e tabelas imutáveis — podem gerar resultados de consulta inesperados se configurados incorretamente. Este tópico aborda nove causas comuns para ajudar você a diagnosticar e corrigir problemas de consulta.
O LindormTable é um mecanismo de dados NoSQL que armazena informações usando Log-Structured Merge Tree (LSM-Tree). Ao gravar dados, o sistema os registra primeiro nos logs Write-Ahead Log (WAL) antes de consolidá-los no banco de dados. Se não houver erros, a gravação foi bem-sucedida e os dados poderão ser restaurados a partir dos logs WAL em caso de falha no servidor, garantindo a durabilidade das informações.
Índice de diagnóstico rápido
Use esta tabela para associar seu sintoma à seção correspondente.
|
Sintoma |
Causa provável |
|
Dados gravados com sucesso, mas não encontrados na consulta |
Dados ainda não gravados ou consulta executada antes da conclusão da gravação |
|
Consulta exata sem resultados, mesmo com dados corretos |
|
|
Nenhum resultado retornado para uma coluna existente |
Diferença entre maiúsculas e minúsculas no nome da coluna ou família de colunas ausente |
|
Dados desaparecem após um período |
|
|
Coluna retorna um valor antigo inesperado após algum tempo |
|
|
Operação DELETE removeu mais dados do que o esperado |
|
|
Dados aparecem brevemente e depois somem |
Condição de corrida entre gravação e exclusão no pipeline de dados |
|
Toda gravação torna-se imediatamente não consultável |
|
|
Resultados inconsistentes dependendo do caminho de busca |
Causas comuns
Dados ainda não gravados ou consulta executada antes da conclusão da gravação
Em pipelines de big data, qualquer falha ou atraso no caminho de gravação impede que os dados cheguem ao LindormTable no momento esperado. Caso uma consulta não retorne resultados, é possível que a gravação ainda não tenha sido concluída.
Diagnóstico: Adicione uma dica à sua consulta para retornar o timestamp junto com os resultados. Compare esse timestamp com o horário em que você esperava que a gravação tivesse sido finalizada.
Para obter detalhes sobre como adicionar dicas e recuperar timestamps, consulte Usar dicas para implementar versionamento de dados.
Se nenhum timestamp for especificado durante a gravação de uma linha, o timestamp retornado refletirá o momento exato em que a linha foi gravada na tabela.
Campo STRING contém caracteres de parada ou invisíveis
Se o valor de uma coluna STRING contiver caracteres invisíveis — adicionados por um bug no programa, por exemplo —, a consulta por correspondência exata falhará porque o valor armazenado difere do valor pesquisado.
Exemplo: Um valor armazenado como 1000<invisible character> não corresponde a where orderID = "1000".
Diagnóstico: Execute uma consulta de intervalo para inspecionar o valor real armazenado:
SELECT * FROM <table> WHERE orderID > "1000" LIMIT 1;Se a linha for retornada, provavelmente o valor possui um caractere invisível à direita. Corrija o caminho de gravação para remover esses caracteres antes de salvar os dados.
Caracteres de parada no meio de uma string: O LindormTable não suporta caracteres de parada no meio de um valor STRING. Tentar gravar uma string como "1000\<stop character>\1000" causa uma exceção de codificação, tornando impossível consultar esse valor.
Diferença entre maiúsculas e minúsculas no nome da coluna ou família de colunas ausente
Dois erros distintos de configuração resultam em consultas vazias.
Incompatibilidade de caixa: Os nomes de colunas no Lindorm diferenciam maiúsculas de minúsculas. Uma consulta usando OrderID não encontrará uma coluna chamada orderID.
Prefixo de família de colunas ausente: Tabelas largas do LindormTable suportam múltiplas famílias de colunas. Se nenhuma família for especificada na criação da tabela, todas as colunas serão colocadas na família padrão f, dispensando prefixos. No entanto, se a tabela possuir várias famílias, consultas que omitirem o prefixo buscarão apenas em f.
Exemplo: Suponha que uma coluna chamada column1 esteja em uma família de colunas chamada meta. Uma consulta com where column1 = xxx buscará em f e não retornará nada. Utilize where meta:column1 = xxx em vez disso.
Dados expiraram com base no TTL no nível da tabela
O TTL do LindormTable é especificado em segundos. Já os timestamps gravados com os dados usam milissegundos.
Com o TTL configurado corretamente, os dados expiram naturalmente após o período definido. Por exemplo, dados gravados hoje expirarão amanhã se o TTL for de 86.400 segundos (um dia).
Dois casos extremos causam a exclusão imediata dos dados após a gravação:
Timestamp muito pequeno: Se você especificar um timestamp anterior ao gravar dados e a diferença entre ele e o horário atual for maior que o TTL definido, os dados poderão ser excluídos imediatamente após a gravação na tabela. Números de versão personalizados como
1,2ou3são especialmente suscetíveis a isso.Timestamp na unidade errada: Se um timestamp em microssegundos ou nanossegundos for gravado em vez de milissegundos, o valor será muito maior que o esperado. Os dados podem nunca expirar conforme planejado ou serem tratados como se tivessem sido gravados milhões de segundos no futuro.
No LindormTable, o número de versão de um par chave-valor equivale a um timestamp. Se você definir valores pequenos (como 1, 2 e 3) como números de versão personalizados, os dados tendem a ser limpos com base no TTL especificado. Da mesma forma, se você usar um valor grande, como um timestamp em microssegundos ou nanossegundos em vez de milissegundos, como timestamp personalizado ou número de versão, os dados não serão limpos conforme o esperado pelo TTL.
Verificar o TTL de uma tabela:
Faça login no sistema de gerenciamento de cluster.
Na página Overview, clique em no nome da tabela.
Na seção Current table details, clique em em View table properties.
Visualize o valor de TTL.
Modifique o TTL:
Dados expiraram com base em um TTL de célula
O LindormTable suporta um TTL em milissegundos para pares chave-valor individuais, conhecido como TTL de célula. Quando definido, o tempo real de expiração de um par chave-valor segue a regra:
min(expiration based on cell TTL, expiration based on table TTL)Tanto o TTL da célula quanto o da tabela são calculados a partir do timestamp ou número de versão do par chave-valor. Se o timestamp for muito pequeno ou muito grande, o par poderá expirar antes ou depois do previsto.
Comportamento de exemplo:
Uma coluna possui dois pares chave-valor: KV1 (com TTL de célula) e KV2 (sem TTL de célula).
Antes da expiração de KV1: as consultas podem retornar KV1 porque seu timestamp é mais recente.
Após a expiração de KV1: KV1 é removido e KV2 passa a ser retornado, o que pode não corresponder ao valor esperado.
A disponibilidade de KV2 para consulta também depende do atributo VERSIONS e da compactação principal (major compaction). Se VERSIONS estiver definido como 1, KV2 será excluído durante a compactação principal assim que KV1 for removido, mesmo que nenhum TTL de célula tenha sido configurado para KV2.
Timestamp de exclusão removeu mais dados do que o esperado
Uma operação DELETE remove todos os dados gravados na linha ou coluna de destino antes do timestamp ou número de versão especificado. Se nenhum timestamp for fornecido, o LindormTable usa o horário atual, excluindo todos os dados gravados até agora.
Dois problemas podem ocorrer:
Dados gravados após o timestamp de exclusão não são removidos: Se uma linha foi gravada depois do timestamp presente na solicitação DELETE, ela não será excluída e aparecerá nas consultas subsequentes.
Gravações posteriores à exclusão são removidas imediatamente: Se um timestamp grande for especificado na solicitação DELETE, gravações subsequentes com timestamps menores (normais) serão tratadas como mais antigas que o marcador de exclusão e apagadas instantaneamente.
Não é possível especificar timestamps em instruções SQL DELETE.
Exemplo: DELETE FROM sensor WHERE p1 = 10; exclui todas as versões das linhas correspondentes gravadas antes do horário atual (16 de janeiro de 2024, 16:00:00 neste exemplo).
Condição de corrida entre gravação e exclusão no pipeline de dados
Em pipelines de big data onde gravações e exclusões originam-se de programas ou processos separados, uma operação de exclusão pode chegar ao LindormTable antes da gravação que deveria suceder. Quando isso ocorre, a gravação acontece após a exclusão: a linha aparece brevemente e logo é deletada.
Problema no conector Flink: Versões mais antigas do conector Lindorm para Realtime Compute for Apache Flink apresentam um bug em que uma operação de gravação pode ser sobrescrita por uma exclusão simultânea. Para contornar isso, defina ignoreDelete=true na sua configuração do Flink.
Para mais detalhes, consulte Conector Lindorm.
Atributo VERSIONS definido como 0
O atributo VERSIONS controla quantas versões de um par chave-valor são retidas. Quando VERSIONS é definido como 0, nenhum dado é mantido: toda gravação é excluída imediatamente e não pode ser consultada.
O valor padrão de VERSIONS é 1 (uma versão retida). O atributo MIN_VERSIONS tem como padrão 0 e não causa perda de dados.
Caso VERSIONS tenha sido definido equivocadamente como 0:
Exclua a tabela e recrie-a com VERSIONS definido como
1ou superior, ouModifique VERSIONS para
1ou superior usando o Lindorm Shell ou ALTER TABLE.
Verificar o atributo VERSIONS:
Faça login no sistema de gerenciamento de cluster.
Na página Overview, clique em no nome da tabela.
Na seção Current table details, clique em em View table properties.
Visualize o valor de VERSIONS.
Modifique VERSIONS:
Para mais informações sobre versionamento de dados, consulte Usar dicas para implementar versionamento de dados.
Dados atualizados ou excluídos em uma tabela imutável
Quando o atributo MUTABILITY de uma tabela é definido como IMMUTABLE, os dados só podem ser gravados por meio de uma única instrução UPSERT. Atualizações e exclusões não são permitidas.
No entanto, o LindormTable não bloqueia estritamente operações de atualização e exclusão em tabelas imutáveis. Executar tais operações causa inconsistência de dados entre a tabela de índice e a tabela base: a mesma consulta pode corresponder a linhas diferentes dependendo de qual tabela é usada para a busca.
Para recuperar a consistência, reconstrua a tabela de índice e pare de emitir operações de atualização ou exclusão na tabela imutável.