Índice de intervalo de bloco - Block Range Index
Um Block Range Index ou BRIN é uma técnica de indexação de banco de dados . Eles se destinam a melhorar o desempenho com tabelas extremamente grandes.
Os índices BRIN fornecem benefícios semelhantes ao particionamento horizontal ou fragmentação, mas sem a necessidade de declarar partições explicitamente.
Um BRIN é aplicável a um índice em uma tabela que é grande e onde o valor da chave do índice é facilmente classificado e avaliado com uma função MinMax .
BRIN foi originalmente proposto por Alvaro Herrera da 2ndQuadrant em 2013 como 'índices Minmax'. As implementações até agora estão fortemente acopladas às técnicas de implementação e armazenamento internas para as tabelas do banco de dados. Isso os torna eficientes, mas os limita a fornecedores específicos. Até agora, o PostgreSQL é o único fornecedor a anunciar um produto ativo com esse recurso específico, no PostgreSQL 9.5. Outros fornecedores descreveram alguns recursos semelhantes, incluindo Oracle , 'mapas de zona' da Netezza , 'pacotes de dados' da Infobright , MonetDB e Apache Hive com ORC / Parquet.
Projeto
O BRIN opera "resumindo" grandes blocos de dados em um formato compacto, que pode ser testado de forma eficiente para excluir muitos deles de uma consulta de banco de dados logo no início. Esses testes excluem um grande bloco de dados para cada comparação. Ao reduzir o volume de dados logo no início, tanto por representar grandes blocos como pequenas tuplas, quanto por eliminar muitos blocos, o BRIN reduz substancialmente a quantidade de dados detalhados que devem ser examinados pelo nó do banco de dados linha por linha.
O armazenamento de dados em grandes bancos de dados é dividido em camadas, com o armazenamento da tabela organizado em 'blocos'. Cada bloco contém talvez 1 MB em cada pedaço e eles são recuperados solicitando blocos específicos de uma camada de armazenamento baseada em disco. BRIN são uma camada de resumo leve na memória acima disso: cada tupla no índice resume um bloco quanto ao intervalo dos dados nele contidos: seus valores mínimo e máximo, e se o bloco contém quaisquer dados não nulos para a coluna ( s) de interesse.
Ao contrário de um índice tradicional que localiza as regiões da tabela contendo valores de interesse, o BRIN atua como "índices negativos", mostrando os blocos que definitivamente não são de interesse e, portanto, não precisam ser processados posteriormente.
Alguns benchmarks simples sugerem uma melhoria de cinco vezes no desempenho de pesquisa com uma varredura de índice, em comparação com a tabela não indexada. Em comparação com árvores B, eles evitam sua sobrecarga de manutenção.
Como os BRIN são tão leves, eles podem ser mantidos inteiramente na memória, evitando assim a sobrecarga do disco durante a varredura. O mesmo pode não ser verdade para a árvore B: a árvore B requer um nó de árvore para cada aproximadamente N linhas na tabela, onde N é a capacidade de um único nó, portanto, o tamanho do índice é grande. Como o BRIN requer apenas uma tupla para cada bloco (de muitas linhas), o índice se torna suficientemente pequeno para fazer a diferença entre o disco e a memória. Para uma tabela 'estreita', o volume do índice da árvore B se aproxima do volume da própria tabela; o BRIN pode ser apenas 5-15% dele.
Vantagens
Pesquisa e varredura de índice
Um grande índice de banco de dados normalmente usaria algoritmos de árvore B. BRIN nem sempre é um substituto para a árvore B, é uma melhoria na varredura sequencial de um índice, com vantagens particulares (e potencialmente grandes) quando o índice atende a condições particulares para ser ordenado e para o alvo de pesquisa ser um conjunto estreito de esses valores. No caso geral, com dados aleatórios, a árvore B ainda pode ser superior.
Uma vantagem particular da técnica BRIN, compartilhada com o Smart Scanning do Oracle Exadata, está na utilização desse tipo de índice com aplicativos de Big Data ou data warehouse , onde se sabe que quase toda a tabela é irrelevante para a faixa de interesse. O BRIN permite que a tabela seja consultada em tais casos, recuperando apenas os blocos que podem conter dados de interesse e excluindo aqueles que estão claramente fora do intervalo ou não contêm dados para esta coluna.
Inserir
Um problema comum com o processamento de tabelas grandes é que a recuperação requer o uso de um índice, mas a manutenção desse índice retarda a adição de novos registros. As práticas típicas têm sido agrupar adições e adicioná-las como uma única transação em massa ou descartar o índice, adicionar o lote de novos registros e, em seguida, recriar o índice. Ambos são prejudiciais às operações simultâneas de leitura / gravação e podem não ser possíveis em alguns negócios em operação contínua.
Com o BRIN, a desaceleração da manutenção do índice é muito reduzida em comparação com a árvore B. Wong relata que a árvore B desacelerou as adições a uma tabela não indexada de 10 GB em 85%, mas um BRIN comparável teve apenas uma sobrecarga de 11%.
Criação de índice
BRIN pode ser criado para dados extremamente grandes onde a árvore B exigiria particionamento horizontal.
Criar o BRIN também é muito mais rápido do que para uma árvore B, em 80%. Isso seria uma melhoria útil para refatorar aplicativos de banco de dados existentes que usam a abordagem drop-add-reindex, sem exigir alterações de código.
Implementação
Dependência da ordem da mesa
Vários BRIN podem ser definidos para diferentes colunas em uma única tabela. No entanto, existem restrições.
BRIN são eficientes apenas se a ordem dos valores-chave seguir a organização dos blocos na camada de armazenamento. No caso mais simples, isso pode exigir a ordem física da tabela, que geralmente é a ordem de criação das linhas dentro dela, para corresponder à ordem da chave. Onde esta chave é uma data de criação, isso pode ser um requisito trivial.
Se os dados forem realmente aleatórios, ou se houver muita rotatividade dos valores-chave em um banco de dados 'quente', as suposições subjacentes ao BRIN podem falhar. Todos os blocos contêm entradas "de interesse" e, portanto, poucos podem ser excluídos no início pelo filtro de intervalo BRIN.
Na maioria dos casos, BRIN é restrito a um único índice por tabela. Vários BRIN podem ser definidos, mas apenas um provavelmente terá um pedido adequado. Se dois (ou mais) índices tiverem comportamento de ordenação semelhante, pode ser possível e útil definir vários BRIN na mesma tabela. Um exemplo óbvio é onde uma coluna de data de criação e uma coluna record_id aumentam monotonicamente com a sequência de criação do registro. Em outros casos, o valor da chave pode não ser monotônico, mas desde que ainda haja um agrupamento forte na ordem física do registro, BRIN é eficaz.
Índices de armazenamento Exadata
BRIN tem algumas semelhanças com os " índices de armazenamento " do Oracle Exadata . O Exadata tem o forte conceito de uma 'camada de armazenamento' em sua pilha de arquitetura. Os dados da tabela são mantidos em blocos ou 'células de armazenamento' nos servidores de armazenamento. Essas células de armazenamento são opacas para o servidor de armazenamento e são devolvidas ao mecanismo de banco de dados a pedido, por seu identificador. Anteriormente, os nós do banco de dados devem solicitar todas as células de armazenamento para fazer a varredura.
Os índices de armazenamento fornecem remoção de dados nesta camada: indicando com eficiência as seções que não têm mais interesse. O índice de armazenamento é carregado na memória do servidor de armazenamento, de modo que, quando uma solicitação de células é emitida, ele pode ser predicado com valores de pesquisa. Eles são comparados ao Índice de Armazenamento e, em seguida, apenas as células relevantes precisam ser retornadas ao nó do banco de dados.
As vantagens de desempenho com um índice de armazenamento são mais evidentes quando a coluna indexada contém muitos nulos . Vantagens de desempenho massivas são obtidas ao digitalizar dados esparsos .
Desenvolvimento
O desenvolvimento do PostgreSQL foi realizado como parte do projeto AXLE (Advanced Analytics for Extremely Large European Databases). Este trabalho foi parcialmente financiado pelo Sétimo Programa-Quadro da União Europeia (FP7 / 2007-2013).
PostgreSQL
A implementação do PostgreSQL foi evidente pela primeira vez em 2013. BRIN apareceu na versão 9.5 do PostgreSQL no início de 2016.
