Ferramenta para apoio de sintonia fina de visões - PUC-Rio

Departamento de Informática
DBX: Fer r amenta par a apoio de sintonia fina de
visões mater ializadas em bancos de dados r elacionais/
Um Banco de Dados par a coleta de estatísticas do ENEM.
Aluno: Er ic Zajler Gr instein
Or ientador : Sér gio Lifschitz
Visões Mater ializadas automáticas
Na era dos grandes volumes de dados, o armazenamento e manipulação eficientes dos
mesmos se torna crucial. Em banco de dados, uma ação de sintonia fina, por parte de um
DBA (database administrator ou administrador de banco de dados), busca melhorias no
desempenho de um sistema de banco de dados por conta de sua influência na forma como
funciona o otimizador do SGBD (Sistema Gerenciador de Bancos de Dados).
Uma consulta (query) pode ter sua performance melhorada, entre outros, pela criação de
índices e visões materializadas [1]. Porém, a escolha de quais índices e visões devem ser
criadas, em qual momento, pode não ser uma tarefa trivial. A ferramenta DBX é capaz de
identificar visões materializadas benéficas para um dado conjunto de consultas em um sistema
de bancos de dados relacional.
A ferramenta DBX foi criada e é mantida pelo laboratório BioBD (Departamento de
Informática/PUC­Rio). A DBX seleciona, por meio de heurísticas, as visões materializadas
que têm potencial para que se obtenha melhor performance para uma determinada carga de
trabalho (um conjunto de consultas SQL e uma instância de banco de dados).
A ferramenta é não­intrusiva, não necessitando assim, daa alteração do código­fonte do
sistema de banco de dados particularmente utilizado. Sua arquitetura é baseada em
componentes implementados como Agentes de software, em especial, 3 agentes: Observer,
que coleta estatísticas da carga de trabalho executada; Predictor , que estima quais visões
materializadas da carga observada podem ser benéficas ao sistema; e Reactor , que, persiste no
sistema de banco de dados uma visão materializada benéfica para a carga de trabalho.
A heurística utilizada para determinar se uma visão é benéfica ou não é denominada
heurística de benefícios e busca obter a diferença entre o custo hipotético de uma consulta
utilizando a visão materializada criada e o custo da consulta sem a utilização da visão. Este
último custo é obtido através do comando SQL 'EXPLAIN PLAN' enquanto que o custo
hipotético é calculado pela aplicação desenvolvida no laboratório BioBD. Caso a diferença de
custos apresente valor positivo, a visão é tida como benéfica e sua criação é recomendada.
A ferramenta DBX foi apresentada como parte da dissertação de mestrado [2] do aluno Rafael
Pereira de Oliveira.
Primeiramente, foi necessária a ambientação tanto em conceitos de sintonia fina quanto da
própria ferramenta de sintonia. Foram lidas dissertações de mestrado e teses de doutorado
passadas, particularmente de membros do BioBD.
Em especial podemos mencionar a tese [3] que iniciou o desenvolvimento teórico da
aplicação. Foi necessário adquirir conhecimento aprofundado da linguagem Java [4] e seu
ambiente de desenvolvimento, NetBeans [5].
Após tal período de adaptação, foram corrigidas falhas e implementadas novas
funcionalidades na aplicação. Primeiramente, foi necessária a alteração do cálculo do custo
hipotético da heurística dos benefícios. Notou­se que visões materializadas que apresentavam
melhorias de performance em consultas não estavam sendo selecionadas pela heurística dos
benefícios, ao menos para o SGBD PostgreSQL [6]. Foi necessário reformular o cálculo deste
custo para tal SGBD, que possui mecanismo específico em seu otimizador de consultas e
gerador de planos de execução para cálculo do custo de uma consulta [7].
Departamento de Informática
Para melhoria de performance e comunicação entre agentes, foram implementados threads
para cada agente. Além disso, converteu­se a aplicação para utilização de tipos de inteiros de
tamanho dinâmico, para que a mesma possa lidar com consultas de bases de dados de grandes
volumes. Após isso, foram realizados testes iniciais, utilizando o benchmark industrial TPC­H
[8]. Este foi escolhido por possuir consultas que demandam alto poder de processamento, para
as quais visões materializadas são expressivamente benéficas [9].
Para os testes foi desenvolvida uma aplicação específica, capaz de executar as consultas do
benchmark constantemente por um número escolhido de repetições. Em conjunção com tal
ferramenta executou­se o DBX, que por sua vez coletou estatísticas e criou visões
materializadas de acordo com a carga recebida pelo banco pela ferramenta de disparo de
consultas.
O código escrito foi versionado utilizando o sistema GIT [11]. Inicialmente, o código foi
mantido em repositório privado, porém hoje pode ser encontrado no repositório público do
site GitHub [12]. Manteve­se durante o desenvolvimento da aplicação um blog privado, em
que foram documentados os avanços feitos, escolhas de desenvolvimento tomadas,
descobertas feitas e dúvidas suscitadas.
Banco de Dados ENEM
Além do projeto DBX, vem sendo realizado um projeto em parceria com o Colégio Liessin
(Ensino Médio) que tem como objetivo a transformação de dados do Exame Nacional do
Ensino Médio (ENEM) [10], disponibilizados pelo governo em formato de planilha, para uma
base de dados relacional PostgreSQL, de modo que possam ser consultados de forma clara e
eficiente.
A prova do ENEM é dividida em 4 áreas de conhecimento, com cada área contendo 45
questões de múltipla escolha com 5 possíveis respostas cada (e apenas uma correta dentre
elas). São elas: Linguagens e Códigos (LC), Ciências Humanas (CH, Ciências da Natureza
(CN) e Matemática (MT). Dentro da prova de Linguagens e Códigos, o aluno deve escolher
uma língua estrangeira (inglês ou espanhol) e responder 5 questões acerca da lingua
escolhida. A prova possui ainda uma redação com tema único para cada ano. Cada prova de
cada área pode conter uma das seguintes cores: azul (todas as áreas), amarelo (todas as áreas),
rosa (todas as áreas), branco (apenas CN ou CH) ou cinza (apenas LC e MT). Cada candidato
recebe cada prova de cada área de conhecimento em uma das cores possíveis para a mesma.
Provas de uma mesma área de cores diferentes possuem as mesmas 45 questões, porém em
diferentes ordens. A redação é corrigida com relação a 5 critérios, que somados resultam na
nota da redação do candidato (um número inteiro de 0 a 1000). As notas por área de
conhecimento são calculadas utilizando­se a “Teoria de Resposta ao Item (TRI)” cujo escopo
foge do deste trabalho. No ano de 2013, mais de sete milhões de pessoas realizaram o exame.
Os dados são relacionados às respostas individuais de candidatos que prestaram a prova em
determinado ano, contendo portanto gigabytes de informação. Tais dados são atualmente
disponibilizados em forma de uma única planilha no formato CSV (Valores Separados por
Vírgula), em que cada linha contém todas as informações de um candidato ao exame do ano.
Cada linha contém o número de inscrição do candidato, suas informações locacionais
(nacionalidade, cidade em que vive atualmente), as informações locacionais de sua escola
(caso seja aluno de uma), suas necessidades especiais (caso possua), suas respostas as
perguntas socioeconômicas (renda, quantidade de aparelhos de televisão que possui, dentre
outras) e, finalmente, suas respostas a cada questão de multipla escolha e suas notas em cada
área e em cada critério da redação.
A planilha contém portanto grande redundância de dados: as informações de determinada
escola, por exemplo, são repetidas para cada estudante da mesma. Ainda, informações como
Departamento de Informática
as necessidades especiais do aluno são irrelevantes para estudos que visam apenas a
comparação de notas entre alunos e escolas. A planilha possui ainda tamanho considerável (a
de 2013 continha 4.8 Gigabytes), fazendo com que não possa ser carregada em memória
principal por programas de edição de planilhas convencionais.
A criação de um modelo para os dados e a inserção dos mesmos em um banco de dados
relacional traz portanto inúmeras vantagens. A redundância dos dados é reduzida. A criação
de uma entidade escola e uma entidade candidato, por exemplo, garante com que todos os
dados de uma escola não sejam repetidos para cada candidato, ao contrário do que ocorre na
planilha diponibilizada pelo INEP. A separação de entidades de um mesmo assunto fazem
com que seja possível ignorar dados para determinados estudos, fazendo­os mais eficientes. O
banco de dados utiliza a linguagem SQL para suas consultas, profundamente difundida e
expressiva. Por fim, SGBDs possuem mecanismos internos para gerência de memória,
fazendo com que seja possível manipular volumes de dados de tamanho grande de maneira
eficiente.
Primeiramente, foi estudado o conjunto de dados disponibilizado. Cada linha da tabela possui
166 colunas, muitas vezes com nomes reduzidos cujo valor guardado não é claro. O órgão
disponibiliza juntamente dos dados um dicionário para o mesmo, contendo as informações
acerca de cada campo: Sua descrição e o tipo de dado (número, texto) armazenado pelo
campo.
Após tal estudo foi montado um modelo Entidade Relacionamento para a aplicação. As
entidades criadas foram Escola , Candidato, Prova, Redação e Questão. O modelo pode ser
encontrado em [13]. Para fins de nossa aplicação, foi decidido dispensar os campos
relacionados a necessidades especiais e ao questionário socioeconômico, Restando 52
atributos ao final. O modelo foi desenhado utilizando a ferramenta CASE BrModelo [14],
ferramenta que permite a modelagem da chamada “Entidade Associativa”. Após isso, foi
gerado o esquema lógico pela ferramenta, e após isso ajustado. O mesmo também pode ser
encontrado em [13]. O próximo passo natural foi a geração do esquema físico para criação de
tabelas no banco de dados Postgres.
Após a modelagem do banco, foi necessária a extração das informações da planilha.
Primeiramente foi feita a separação da planilha em 8 outras, cada uma contendo menos de um
milhão de linhas (aplicações como o LibreOffice, extensamente utilizado em sistemas Linux,
truncam planilhas com um valor superior de linhas). A separação foi feita utilizando a
ferramenta CSV Splitter [15]. Após isso, foram removidos os campos indesejados de cada
tabela utilizando a ferramenta CSVed [16]. Após tal etapa, o número de atributos diminuiu de
166 para 52, e o tamanho do conjunto de dados reduziu de 4.8 GB para 3.3 GB.
Foi feita a transformação de cada linha da tabela em uma inserção SQL. Como a planilha fora
separada em 8, se tornou possível que sejam processados os dados paralelamente de modo a
agilizar o processo. Dentre outras observações, cada marcação do candidato se torna uma
inserção na tabela Marca , totalizando 180 inserções (apenas nesta tabela) para cada candidato,
fazendo a performance do script se tornar um fator considerado. As informações relacionadas
a questões foram extraídas de uma planilha à parte, denominada “Itens ENEM”, contida no
pacote de dados disponibilizado pelo INEP. Foi necessária especial atenção para que a ordem
de mesmas questões de provas de cores diferentes fossem tratadas como questões iguais. Para
isso, foram utilizadas tabelas no script relacionando a ordem das questões de cada cor à ordem
da questão na prova de cor azul, usada como referência. O script gerará no seu término um
arquivo no formato SQL, contendo comandos de inserção nas tabelas.
Para o futuro, será gerada uma interface web para o banco de dados criado, em que serão
exibidos gráficos e estatísticas acerca da prova. Tais estatísticas serão propostas pelo colégio
Liessin. Pela natureza imutável dos dados, serão criadas visões materializadas e índices para a
melhoria de performance das consultas necessárias para a geração de tais estatísticas.
Departamento de Informática
Refer ências
1 ­ http://docs.oracle.com/cd/B10501_01/server.920/a96567/repmview.htm
2 – Oliveira, R. P. Sintonia Fina Baseada em Ontologia : O caso de visões mater ializadas
Rio de Janeiro: PUC. Departamento de Informática, 2015.
3 ­ Carvalho, A. W. Cr iação Automática de Visões Mater ializadas em SGBDs Rio de
Janeiro: PUC. Departamento de Informática, 2011.
4 ­ https://www.java.com/en/about/
5 ­ https://netbeans.org/
6 – https://www.postgresql.org
7 ­ http://www.postgresql.org/docs/9.0/static/using­explain.html
8 ­ http://www.tpc.org/tpch/
9 ­ Chaudhuri, S., Narasayya, V., Agrawal, S. Automated Selection of Mater ialized Views
and Indexes for SQL Databases. Microsoft Research, 2000.
10 ­ http://portal.inep.gov.br/basica­levantamentos­acessar
11 – http://git­scm.com
12 ­ https://github.com/BioBD/dbx
13 – https://github.com/BioBD/microdados­enem
14 ­ http://www.sis4.com/brModelo
15 ­ http://erdconcepts.com/dbtoolbox.html
16 ­ http://csved.sjfrancke.nl/