| |
| Acadêmico(a): João Paulo Poffo |
| Título: Nova Organização para Estrutura de Dados em Bancos Relacionais: Estudo de Caso |
| |
| Conclusão: |
O objetivo geral deste trabalho, implementar um storage engine, realizar um benchmark e analisar o seu resultado foi alcançado em sua plenitude, assim como os objetivos específicos. Porém, de acordo com o resultado dos testes, os ganhos esperados, principalmente de desempenho, não foram atingidos.
O tipo de tabela Vogal é uma implementação de estrutura de dados que tem como objetivo quebrar o paradigma que os campos de um registro em um banco de dados devem permanecer juntos fisicamente. Dentre os benefícios desta mudança estariam principalmente a diminuição da redundância de dados e o aumento do desempenho.
O MySQL já implementa as operações principais do SQL como junção, união, funções de grupo e filtro e estas funcionalidades também estão disponíveis no tipo de tabela Vogal. Apesar de não estarem contemplados no projeto, ou seja, integridade referencial, filtros complexos, agrupamentos de dados, entre outros recursos disponíveis no SGDB podem ser utilizados nas tabelas de tipo Vogal.
Na arquitetura foi implementado um mecanismo de campo dinâmico que, através de um byte é possível delimitar quaisquer tamanhos de campo de forma ilimitada. Esse tipo de modelagem é importante para atender uma possível expansão da implementação. Porém foram atribuídos limites para que seja possível testá-los e validá-los no tempo disponível para a confecção desta monografia.
As seguintes limitações estão devidamente elencadas nos requisitos do projeto e correspondem aos principais itens identificados. Não são apenas itens que não funcionam na aplicação, são também recursos e limites não plenamente validados:
a) apenas são permitidos campos de tipo texto ou numérico inteiro;
b) os tipos texto serão limitados a 127 caracteres;
c) os tipos numéricos deverão estar entre -2147483648 e 2147483647 (inteiro de 32 bits);
d) as limitações de tamanho na definição do campo não são validadas.
Três itens vieram de encontro ao fator desempenho do Tipo de Tabela: falta de um gerenciamento de memória adequado que reduzisse o acesso a disco, a não implementação do mecanismo de índices disponibilizado pela API do MySQL e, como nos blocos de RIDs existem endereços para os dados, qualquer atualização nos blocos dos dados implica na necessidade de reorganização dos deslocamentos a cada atualização da base de dados.
O MySQL tem um gerenciamento de memória, mas este é completamente independente do tipo de tabela. Portanto, ao contrário do que se acreditava no início do projeto, este deve ser implementado por completo no storage engine. E assim o foi porém, de forma precária.
O mecanismo que a API do MySQL dispõe para utilização de índices não foi implementado pela razão de o tipo de tabela Vogal não criar índices secundários. Contudo, é necessário que o MySQL entenda que o storage engine possui formas de localizar de maneira eficiente a informação que ele necessita, ou seja, o SGDB faz toda preparação do plano de execução do SQL informado pelo usuário (ou aplicação cliente). Este plano é formado através de estatísticas obtidas do tipo da tabela, entre as quais estão informações de quais os melhores índices a serem ou não utilizados, de forma a otimizar esse plano de execução. A não implementação desse recurso no storage engine fez com que o MySQL entendesse toda consulta do tipo de tabela Vogal como varredura completa da tabela. Dessa forma, para otimizar as consultas é necessário implementar os métodos da API que são relacionados a índices, informando ao MySQL que o tipo de tabela Vogal possui índices porém, de uma forma diferente.
Os dados do Tipo de Tabela são organizados em duas estruturas: árvore de RIDs e árvore de registros. A primeira estrutura grava o valor do RID e o endereço (bloco e deslocamento) do dado na segunda. E a árvore de registros grava o valor do dado e o valor do RID, ou seja, caso a informação seja localizada pelo dado, é possível localizar o RID na árvore de RIDs através do número encontrado. Caso seja localizada através do RID, é possível obter o dado da coluna através de seu endereço. Porém, os dados mudam de posição dentro de um bloco de acordo com as atualizações impostas sobre eles ou seus irmãos. Isso imprime ao storage engine a necessidade de atualizar o endereço dos dados em suas respectivas árvores de RIDs. Assim, caso um bloco da árvore de registros possua cinco registros e seja inserido um novo registro que fique em primeiro no bloco, todos os registros subsequentes terão seu endereço alterado, necessitando um número maior de atualizações. Um gerenciamento de memória adequado poderia minimizar esse problema.
O tipo de tabela Vogal está disponibilizado para a comunidade de código aberto junto ao MySQL, esperando desta forma a contribuir e receber contribuições de quem se mostrar interessado.
|
| |
|
