A varredura completa de tabelas é um dos principais gargalos para consultas analíticas em grandes conjuntos de dados. O ApsaraDB for SelectDB mantém duas categorias de índices para minimizar leituras desnecessárias: índices inteligentes integrados, criados e gerenciados automaticamente, e índices secundários, definidos para padrões específicos de consulta.
|
Categoria |
Tipos de índice |
|
Índices inteligentes integrados |
Índice zone map, índice de prefixo |
|
Índices secundários |
Inverted index, Bitmap index, Bloom filter index, NGram Bloom filter index |
Este tópico aborda os índices inteligentes integrados: seu funcionamento e como aproveitar ao máximo seus benefícios.
Índice zone map
O SelectDB cria e mantém automaticamente o índice zone map para cada coluna no formato de armazenamento colunar. Para cada coluna, o sistema registra:
Min: valor mínimo da coluna
Max: valor máximo da coluna
NULL count: quantidade de valores NULL na coluna
Quando uma consulta inclui um filtro de intervalo ou igualdade, o SelectDB compara o filtro com os limites Min–Max de cada coluna e ignora dados sem linhas correspondentes. Essa abordagem acelera significativamente consultas de intervalo e filtros de desigualdade em grandes conjuntos de dados.
O gerenciamento dos índices zone map ocorre automaticamente, sem necessidade de intervenção do usuário.
Índice de prefixo
Construção do índice de prefixo
O ApsaraDB for SelectDB é um banco de dados OLAP (processamento analítico online) com arquitetura MPP (processamento massivamente paralelo). Os dados residem em uma estrutura semelhante à SSTable (tabela de strings ordenadas): as linhas são classificadas e armazenadas conforme as colunas-chave definidas na criação da tabela.
Nos modelos Aggregate Key, Unique Key e Duplicate Key, a ordenação das linhas segue as colunas listadas nas cláusulas AGGREGATE KEY, UNIQUE KEY ou DUPLICATE KEY. O índice de prefixo utiliza os primeiros 36 bytes das colunas-chave de cada linha como estrutura de consulta acelerada.
Aplica-se uma restrição: se uma coluna-chave for do tipo VARCHAR, o índice de prefixo será truncado no limite dessa coluna, mesmo que o consumo não atinja 36 bytes.
Exemplos
Exemplo 1: Índice de prefixo abrange várias colunas
|
Nome da coluna |
Tipo |
|
user_id |
BIGINT |
|
age |
INT |
|
message |
VARCHAR(100) |
|
max_dwell_time |
DATETIME |
|
min_dwell_time |
DATETIME |
Neste esquema, o índice de prefixo corresponde a user_id (8 bytes) + age (4 bytes) + message (prefixo de 20 bytes), totalizando 36 bytes.
Consultas que filtram pelas colunas iniciais utilizam o índice de prefixo e apresentam desempenho significativamente superior:
-- Hits the prefix index: user_id is the first key column
SELECT * FROM table WHERE user_id = 1829239 AND age = 20;Consultas que ignoram a primeira coluna-chave não utilizam o índice de prefixo:
-- Does not hit the prefix index: user_id is not in the filter
SELECT * FROM table WHERE age = 20;Exemplo 2: Índice de prefixo truncado por VARCHAR
|
Nome da coluna |
Tipo |
|
user_name |
VARCHAR(20) |
|
age |
INT |
|
message |
VARCHAR(100) |
|
max_dwell_time |
DATETIME |
|
min_dwell_time |
DATETIME |
Neste esquema, o índice de prefixo corresponde apenas a user_name (20 bytes). Como user_name é VARCHAR, o índice é truncado após essa coluna, embora apenas 20 bytes tenham sido consumidos. As colunas subsequentes (age, message) não fazem parte do índice de prefixo.
Modifique um índice de prefixo usando uma materialized view
A ordem das colunas-chave de uma tabela é fixa na criação; portanto, cada tabela possui apenas um índice de prefixo. Para adotar uma ordem diferente de colunas e obter um índice de prefixo distinto, crie uma materialized view que reordene as colunas. Para mais informações, consulte Materialized views.