Lindorm:Secondary indexes

Relação entre índices e tabelas primárias

Cada índice secundário corresponde a uma tabela de dados física independente, separada da tabela primária. É possível criar vários índices para uma única tabela primária, incluindo índices compostos baseados em uma ou mais colunas. Ao escrever na tabela primária, o Lindorm atualiza automaticamente todas as tabelas de índice associadas. Durante consultas, especifique condições na cláusula WHERE em relação à tabela primária. O Lindorm seleciona o melhor índice automaticamente e recorre à tabela primária quando nenhum índice for adequado.

Online Schema Change

Modificações em índices — como adicionar, desativar ou excluir um índice — não afetam as operações normais de leitura ou escrita na tabela primária. Adicione, exclua ou atualize índices a qualquer momento sem tempo de inatividade.

Consistência forte

A consistência de dados entre a tabela primária e as tabelas de índice apresenta as seguintes restrições:

• Não há suporte para isolamento de snapshot. Os dados gravados na tabela primária podem não ficar imediatamente visíveis nas tabelas de índice. Após o servidor retornar uma resposta de sucesso, os dados tornam-se visíveis em ambas.

• Comportamento em caso de timeout do cliente ou erro de I/O. Se uma falha de escrita ocorrer devido a timeout do cliente ou erro de I/O, os dados podem não aparecer nem na tabela primária nem nas tabelas de índice. A consistência eventual entre elas ainda é garantida.

Mutabilidade

Cada operação de escrita em uma tabela indexada custa mais do que em uma tabela simples, pois o índice precisa ser mantido. O custo real depende se a carga de trabalho atualiza ou exclui linhas existentes.

A propriedade MUTABILITY informa ao Lindorm quais operações a carga de trabalho executa, permitindo minimizar a sobrecarga de manutenção do índice. Defina essa propriedade usando Table_Options ao criar ou modificar uma tabela. Consulte CREATE TABLE syntax.

Escolha uma configuração de mutabilidade com base no padrão de escrita:

• Apenas adições, sem atualizações ou exclusões: use IMMUTABLE

• Adições e exclusões no nível de linha, sem atualizações: use IMMUTABLE_ROWS

• Atualizações e exclusões, sem timestamp personalizado: use MUTABLE_LATEST (recomendado)

• Atualizações e exclusões com timestamp personalizado: use MUTABLE_UDT

A configuração recomendada é MUTABLE_LATEST. Para LindormTable 2.7.9 e versões posteriores, ela já é o padrão. Caso a instância execute uma versão anterior, defina MUTABILITY='MUTABLE_LATEST' explicitamente.

Para gravar dados com um timestamp personalizado, utilize MUTABLE_UDT (requer LindormTable 2.6.7 ou posterior). Planeje essa definição antes de criar índices, pois a propriedade de mutabilidade entra em vigor no momento da criação do índice.

IMMUTABLE e IMMUTABLE_ROWS não possuem imposição no lado do servidor. Se a carga de trabalho atualizar dados, mas a tabela estiver configurada como IMMUTABLE ou IMMUTABLE_ROWS , o servidor não retornará erro, porém os dados do índice ficarão inconsistentes com a tabela primária. Utilize essas configurações apenas quando tiver certeza de que nenhuma atualização ocorrerá. Como tabelas IMMUTABLE não envolvem exclusões, elas oferecem suporte total a implantações ativas-ativas em múltiplos Internet Data Centers (IDCs).

Índices de cobertura

Sem um índice de cobertura, uma consulta que corresponda a uma entrada de índice ainda precisa buscar a linha completa na tabela primária. As rowkeys retornadas pelo índice podem estar dispersas pela tabela primária, exigindo múltiplas chamadas de procedimento remoto (RPCs) e aumentando o tempo de resposta (RT) conforme o conjunto de resultados cresce.

Um índice de cobertura inclui colunas da tabela primária diretamente na tabela de índice, eliminando buscas na tabela primária para essas colunas. O Lindorm oferece suporte a três modos de cobertura:

• Specific columns: Liste as colunas a replicar da tabela primária.

• Todas as colunas do schema (COVERED_ALL_COLUMNS_IN_SCHEMA): Inclui todas as colunas definidas atualmente no schema da tabela primária. Quando uma nova coluna é adicionada à tabela primária, o índice a inclui automaticamente, sem necessidade de reindexação.

• Colunas dinâmicas (DYNAMIC): Inclui todas as colunas dinâmicas da tabela primária, além de todas as colunas definidas no schema.

Timestamps personalizados (User-Defined Timestamp, UDT)

O Lindorm oferece suporte a timestamps personalizados no nível da coluna. A gravação de dados com timestamp personalizado é comum em sistemas baseados em HBase para controlar o Time to Live (TTL) e lidar com escritas fora de ordem ou idempotentes. Os índices secundários no Lindorm também suportam a atualização de dados do índice quando timestamps personalizados são utilizados, uma capacidade incomum em sistemas NoSQL.

Dois casos de uso relevantes:

• Importação simultânea e atualizações em tempo real: Use a hora atual para escritas em tempo real e um timestamp anterior (por exemplo, 23:59:59 do dia anterior) para importações históricas. As escritas em tempo real têm precedência; as importações históricas preenchem apenas os dados ainda não atualizados.

• Recuperação de mensagens: Quando um sistema ignora mensagens acumuladas e processa as atuais primeiro, cada mensagem carrega seu próprio timestamp. A recuperação posterior das mensagens anteriores aplica a ordem correta de sobrescrita, independentemente da sequência de processamento.

-- Create the primary table
CREATE TABLE orders (
  order_id VARCHAR NOT NULL,
  user_id  VARCHAR,
  status   VARCHAR,
  amount   DOUBLE,
  created  BIGINT,
  PRIMARY KEY(order_id)
) WITH (CONSISTENCY = 'strong', MUTABILITY = 'MUTABLE_LATEST');

-- Create a covering index on user_id, including all schema columns
-- Queries filtering on user_id hit this index and avoid primary table lookups
CREATE INDEX idx_user ON orders(user_id) WITH (INDEX_COVERED_TYPE = 'COVERED_ALL_COLUMNS_IN_SCHEMA');

-- This query uses idx_user automatically
SELECT * FROM orders WHERE user_id = 'u123';

SHOW INDEX FROM orders;

-- Activate an index
ALTER INDEX IF EXISTS idx_user ON orders ACTIVE;

-- Disable an index
ALTER INDEX idx_user ON orders DISABLED;

DROP INDEX IF EXISTS idx_user ON orders;

CREATE TABLE dt (rowkey VARCHAR, c1 VARCHAR, c2 VARCHAR, c3 VARCHAR, c4 VARCHAR, c5 VARCHAR, PRIMARY KEY(rowkey));
CREATE INDEX idx1 ON dt(c1);
CREATE INDEX idx2 ON dt(c2, c3, c4);
CREATE INDEX idx3 ON dt(c3) INCLUDE(c1, c2, c4);
CREATE INDEX idx4 ON dt(c5 DESC) WITH (INDEX_COVERED_TYPE = 'COVERED_ALL_COLUMNS_IN_SCHEMA');

Por que o erro User-Defined-Timestamp(UDT) is not supported by table in MUTABLE_LATEST mode aparece?

Você criou um índice enquanto a mutabilidade da tabela estava definida como MUTABLE_LATEST, mas a aplicação grava dados com um timestamp personalizado. O modo MUTABLE_LATEST não oferece suporte a timestamps personalizados.

Para corrigir isso:

1. Exclua o índice da tabela primária.

2. Altere a propriedade de mutabilidade para MUTABLE_UDT.

3. Crie o índice novamente.

Para outros problemas relacionados a índices, participe do grupo DingTalk do Lindorm ou envie um ticket. Consulte Technical support.