compressão de bancos de dados em ambientes móveis com...
TRANSCRIPT
FUNDAÇÃO EDSON QUEIROZ UNIVERSIDADE DE FORTALEZA – UNIFOR
Ricardo Wagner Cavalcante Brito
Compressão de Bancos de Dados em Ambientes Móveis com Recursos Computacionais Limitados
Fortaleza
2007
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
ii
FUNDAÇÃO EDSON QUEIROZ UNIVERSIDADE DE FORTALEZA – UNIFOR
Ricardo Wagner Cavalcante Brito
Compressão de Bancos de Dados em Ambientes Móveis com Recursos Computacionais Limitados
Dissertação apresentada ao Curso de
Mestrado em Informática Aplicada da
Universidade de Fortaleza como parte
dos requisitos necessários para a
obtenção do Título de Mestre em
Ciência da Computação.
Orientador: Prof. Dr.-Ing Ângelo Roncalli Alencar Brayner
Fortaleza 2007
iii
Ricardo Wagner Cavalcante Brito
Compressão de Bancos de Dados em Ambientes Móveis com Recursos Computacionais Limitados
Data de Aprovação: _______________
Banca Examinadora:
_________________________________________ Prof. Ângelo Roncalli Alencar Brayner, Dr.-Ing.
(Presidente da Banca)
_________________________________________ Prof. Marcus Costa Sampaio, Docteur
(Universidade Federal de Campina Grande)
_________________________________________ Prof. Francisco Nivando Bezerra, Docteur
(Universidade de Fortaleza)
iv
BRITO, RICARDO WAGNER CAVALCANTE
Compressão de Bancos de Dados em Ambientes Móveis com
Recursos Computacionais Limitados [Fortaleza] 2007
xii, 67p., 29,7 cm (MIA/UNIFOR, M.Sc., Ciência da Computação, 2007)
Dissertação de Mestrado – Universidade de Fortaleza, MIA
1. Banco de Dados
2. Banco de Dados Móveis
3. Compressão de Dados
I. MIA/UNIFOR II. TÍTULO (série)
v
Dedico este trabalho à minha mãe,
meu pai (in memorian), minha
esposa e meus irmãos.
vi
Agradecimentos
À minha querida mãe por ter estado sempre presente nos momentos mais difíceis e importantes da minha vida, pelo amor incondicional e pela dedicação completa que sempre dispensou a mim, por tudo o que sempre me ensinou e pela maneira irretocável com a qual me educou e me acompanha a vida inteira.
À minha esposa, por todo o companheirismo e apoio que sempre me propiciou, pela maneira como sempre me faz buscar o melhor de mim, pelo amor e carinho que me faz presente todos os dias da minha vida.
Aos meus irmãos, por todos os felizes anos de convivência familiar que levo para o resto da minha vida.
Ao Professor Ângelo Brayner pela atenção, dedicação, compromisso e acompanhamento que sempre dispensou a mim e a este trabalho, mesmo antes da idéia surgir, e pelos conselhos e sugestões sem as quais esta dissertação jamais seria possível.
Aos meus colegas de projeto de pesquisa, projeto no qual este trabalho surgiu e tomou forma, Dorotéa Karine, Magno Prudêncio, Wandré Araújo, Wendel Bezerra, Danielle Amorim, Wander Castro, Marília Soares e Thiago Leite por toda a amizade, companheirismo e competência que sempre demonstraram em três anos de convivência diária.
Ao Professor Nabor Mendonça pela importante participação nas etapas iniciais do projeto e pelas sugestões sempre tão proveitosas que ofereceu.
Ao Professor Plácido Pinheiro pela brilhante coordenação que realiza junto ao Mestrado em Informática Aplicada da Unifor e pela atenção inigualável que dispensa a todos os seus alunos e orientandos.
Aos funcionários do NATI – UNIFOR Ector e Alexandre pelo suporte sempre presente que nos propiciaram durante todo o decorrer do projeto, demonstrando sempre seriedade e competência em tudo o que foi solicitado.
A Universidade de Fortaleza pela oportunidade de ter participado do projeto de pesquisa Palm Celestica, local onde surgiu a idéia e onde toda a implementação deste trabalho foi realizada.
Finalmente, ao meu falecido pai, no qual sempre procurei me espelhar e que serve como referencial para tudo o que faço, pela honestidade, integridade, seriedade, amor e carinho que sempre me ofertou de maneira tão intensa e por tudo o que representa na minha vida mesmo não estando mais entre nós.
vii
Resumo da Dissertação apresentada ao MIA/UNIFOR como parte dos requisitos
necessários para a obtenção do título de Mestre em Ciência da Computação
COMPRESSÃO DE BANCOS DE DADOS EM AMBIENTES MÓVEIS COM
RECURSOS COMPUTACIONAIS LIMITADOS
Ricardo Wagner Cavalcante Brito
Dezembro / 2007
Orientador: Dr.-Ing. Ângelo Roncalli Alencar Brayner
Programa: Ciências da Computação
Dada a popularização cada vez mais freqüente dos dispositivos móveis com recursos computacionais limitados como handhelds e Personal Digital Assistants (PDAs) e diante da característica inerente a tais dispositivos no que se refere a limitação de recursos, faz-se cada vez mais necessária uma estratégia para melhor aproveitamento do espaço em memória utilizado e do poder de processamento de tais dispositivos. Esse trabalho apresenta uma estratégia de compressão a ser aplicada sobre os dados presentes em tais dispositivos de forma a otimizar espaço em memória. A arquitetura utilizada implementa uma estrutura de armazenamento orientada a colunas onde os dados de uma mesma coluna pertencem ao mesmo registro lógico. Além disso, a estratégia de compressão apresentada – composta por várias técnicas simples e de baixo custo computacional onde para cada tipo de dados é aplicada uma técnica diferente – combina perfeitamente com esse tipo de armazenamento. Os resultados experimentais obtidos mostraram que a utilização dessa estratégia propicia uma melhoria significativa na utilização do espaço de memória sem que haja problemas de performance do sistema.
viii
Abstract of Thesis presented to MIA/UNIFOR as a partial fulfillment of the requirements for the degree of Master of Science Computer
DATABASE COMPRESSION IN MOBILE ENVIRONMENTS WITH LIMITED COMPUTATIONAL RESOURCES
Ricardo Wagner Cavalcante Brito
December / 2007
Advisor: Dr.-Ing. Ângelo Roncalli Alencar Brayner
Department: Computing Science
Due to increasing popularization of mobile devices with limited computacional resources such as handhelds and Personal Digital Assistants (PDAs) and inherent feature of limitation of resources present in such devices, the use of an architecture to optimize the used memory and the processing power of such devices is important. This work presents a compression strategy to be applied over data existing in such devices to optimize the memory space. The used framework implements a storage column oriented architecture in which data existing in the same column belong to the same logical record. Besides that, the compression strategy used – formed by several lightweight techniques in which to each data type a different technique is used – matchs perfectly with that kind of storage architecture. The experimental results show that the use of a compression strategy offers a significant improvement in use of memory space without problems in system performance.
ix
Sumário
1. INTRODUÇÃO...............................................................................................................................13
1.1 MOTIVAÇÃO.............................................................................................................................13 1.2 OBJETIVOS ...............................................................................................................................15 1.3 ESTRUTURA DO TRABALHO......................................................................................................16
2. ARMAZENAMENTO DE DADOS ..............................................................................................18
2.1 INTRODUÇÃO ...........................................................................................................................18 2.2 ESTRUTURA DE ARMAZENAMENTO DE DADOS NO AMBIENTE PALM OS .................................18 2.3 ARMAZENAMENTO DE DADOS ORIENTADO A COLUNAS ..........................................................24
2.3.1 Armazenamento Orientado a Tuplas x Armazenamento Orientado a Colunas .......................24 2.3.2 C-Store: Estratégia de Orientação a Coluna...........................................................................25
2.4 ESTRATÉGIA DE ARMAZENAMENTO EFICIENTE DE DADOS ......................................................30
3. ESTRATÉGIAS DE COMPRESSÃO EM BANCOS DE DADOS ............................................34
3.1 INTRODUÇÃO ...........................................................................................................................34 3.2 VANTAGENS E DESVANTAGENS DA UTILIZAÇÃO DE COMPRESSÃO SOBRE OS DADOS..............34 3.3 TÉCNICAS E ALGORITMOS DE COMPRESSÃO ............................................................................37 3.4 COMPLEXIDADE E GRANULARIDADE DE ALGORITMOS ............................................................38
4. ESTRATÉGIAS DE COMPRESSÃO PARA AMBIENTES COM RESTRIÇÃO COMPUTACIONAL ...............................................................................................................................41
4.1 INTRODUÇÃO ...........................................................................................................................41 4.2 DEFINIÇÕES BÁSICAS ...............................................................................................................41 4.3 COMPRESSÃO NUMÉRICA.........................................................................................................42 4.4 COMPRESSÃO DE BOOLEANO ...................................................................................................46 4.5 COMPRESSÃO DE STRING .........................................................................................................46
5. ACESSO A DADOS COMPRIMIDOS.........................................................................................49
5.1 INTRODUÇÃO ...........................................................................................................................49 5.2 GRANULARIDADE E PERFORMANCE .........................................................................................49 5.3 DADOS DO TIPO INTEIRO..........................................................................................................50 5.4 DADOS DO TIPO BOOLEANO.....................................................................................................52 5.5 DADOS DO TIPO STRING...........................................................................................................52 5.6 ESTRUTURA DOS ARQUIVOS.....................................................................................................53
6. RESULTADOS EXPERIMENTAIS.............................................................................................57
6.1 INTRODUÇÃO ...........................................................................................................................57 6.2 EXPERIMENTOS REALIZADOS ...................................................................................................57
7. CONCLUSÃO.................................................................................................................................63
7.1 CONSIDERAÇÕES FINAIS E CONTRIBUIÇÕES DO TRABALHO .....................................................63 7.2 TRABALHOS FUTUROS .............................................................................................................64
BIBLIOGRAFIA......................................................................................................................................66
Lista de Figuras
Figura 1: Arquitetura da Memória do Ambiente Palm OS .................................................... 20
Figura 2: Estrutura do Arquivo PDB .................................................................................... 22
Figura 3: Estrutura Tradicional de Armazenamento de Dados .............................................. 23
Figura 4: Componentes da arquitetura do C-Store ................................................................ 27
Figura 5: Estrutura de Armazenamento de Dados Adotada................................................... 31
Figura 6: Representação binária de valores não comprimidos............................................... 44
Figura 7: Representação Binária de Valores Comprimidos ................................................... 45
Figura 8: Estrutura de um Registro de Controle para Coluna do Tipo Inteiro........................ 51
Figura 9: Estrutura de uma Coluna do Tipo String e seu Registro de Controle...................... 53
Figura 10: Organização dos Registros de Controle e de Dados de uma Tabela ..................... 54
Figura 11: Estrutura de um Arquivo PDB de uma Tabela com Três Colunas ........................ 55
xi
Lista de Tabelas
Tabela 1. Codificação do tamanho de inteiros ...................................................................... 51
Tabela 2: Tamanho (em bytes) de Tabelas Comprimidas e Não-Comprimidas ..................... 58
Tabela 3: Tempo (em ms) de Tabelas Comprimidas e Não-Comprimidas............................. 58
Tabela 4: Comparação entre bancos no SQL Server e na PDM............................................. 62
xii
Lista de Gráficos
Gráfico 1: Relação entre Quantidade de Tuplas e o Tamanho da Tabela............................... 60
Gráfico 2: Variação entre o Tamanho da Tabela ZonaEleitorais ........................................... 61
1. Introdução
1.1 Motivação
A utilização de dispositivos móveis como handhelds e PDAs (Personal Digital
Assistants) tem se expandido rapidamente nos últimos anos. Devido a sua portabilidade e
facilidade de uso, estes equipamentos vêm se tornando a ferramenta ideal em atividades que
necessitem de mobilidade, pouco processamento e freqüente manipulação de dados. Além
disso, a crescente popularização das redes wireless tem permitido que um número cada vez
maior de usuários passe a utilizar esses equipamentos móveis.
No entanto, tais dispositivos se caracterizam por apresentarem recursos
computacionais limitados, com reduzido poder de processamento e pouco espaço de memória.
Embora a sua capacidade de armazenamento tenha aumentado consideravelmente em relação
aos primeiros equipamentos lançados no mercado, a exigência de memória das aplicações
atuais também cresceu bastante. Dessa forma, o armazenamento eficiente de dados e a
redução de espaço utilizado em memória são fatores críticos que precisam ser levados em
consideração quando se está lidando com esse tipo de ambiente.
As limitações inerentes a tais sistemas computacionais inviabilizam a utilização de
aplicações que necessitem de alto poder de processamento ou que trabalhem com grandes
quantidades de dados. Com isso, a aplicação de técnicas de compressão surge como uma
abordagem interessante em tal situação porque permite que os clientes mantenham seus dados
no formato comprimido, aumentando a quantidade de memória disponível para outras
aplicações.
Basicamente, a compressão de dados oferece duas importantes vantagens: redução do
espaço de memória utilizado e melhora na performance das aplicações devido ao aumento na
largura de banda de Entrada/Saída (E/S). Por outro lado, tal estratégia pode resultar em uma
14
considerável sobrecarga de CPU caso haja a necessidade da compressão e descompressão de
todos os dados que estiverem sendo lidos.
Existem atualmente muitos estudos e trabalhos desenvolvidos na área de compressão
de dados. Entre os algoritmos de compressão mais tradicionais estão a codificação Huffman
[10], codificação aritmética [23] e Lempel-Ziv (LZ) [24].
No entanto, ambientes de bancos de dados possuem certas características que limitam
a aplicação destes algoritmos de compressão mais tradicionais. A maioria dos trabalhos
relacionados com compressão neste tipo de ambiente tem se preocupado com a
implementação de novas técnicas de compressão, como ocorre em [4], [7], [9], [11] e [20].
Por outro lado, outros trabalhos têm como objetivo a aplicação de técnicas de compressão já
existentes que, quando aplicadas em conjunto de maneira adequada, tornem-se eficientes em
ambientes de bancos de dados, como ocorre em [22], onde os métodos de compressão
utilizados são muito similares aos métodos utilizados neste trabalho.
Outra característica importante da grande maioria dos sistemas de bancos de dados
para os quais esses trabalhos se destinam é o fato de trabalharem com o armazenamento
“orientado a tuplas”, conforme será discutido mais adiante. Em ambientes que estão
continuamente recebendo consultas que retornam grandes blocos de dados ‘verticais’, uma
arquitetura “orientada a colunas” poderia oferecer melhores ganhos de desempenho para o
sistema.
Essa abordagem apresenta-se como uma opção interessante porque facilita a utilização
de técnicas de compressão mais “leves”, ou seja, que não necessitem de muito poder de
processamento. Em [21] é apresentado um SGBD, chamado C-Store, otimizado para a leitura
de dados e cuja estratégia de armazenamento de dados é orientada a colunas e não a tuplas
como na maioria dos SGBDs.
De uma forma geral, a grande maioria dos trabalhos nessa área está relacionada com
bancos de dados para ambientes desktop tradicionais. Para ambientes com recursos
computacionais limitados, o número de trabalhos ainda é comparativamente pequeno até
porque sistemas gerenciadores de bancos de dados ainda não são tão comuns em tais
plataformas, mas tem crescido bastante nos últimos anos.
15
Algumas ferramentas de compressão existentes para esses ambientes, tais como,
HandyZip, FlyZip ou LightNzip, não são adequadas para sistemas de bancos de dados porque
os arquivos comprimidos devem ser totalmente descomprimidos ao seu tamanho original
quando forem acessados. Como será visto mais adiante, isso pode acarretar um sério
problema de sobrecarga de processamento.
Em [2], é apresentada uma estratégia para pesquisa em arquivos comprimidos em
dispositivos móveis. No entanto, tais arquivos são arquivos simples, sem quaisquer das
principais características presentes em bancos de dados relacionais.
Este trabalho apresenta uma estratégia de compressão de forma eficiente sobre
ambientes de bancos de dados para dispositivos com recursos computacionais limitados. Isso
o difere dos demais trabalhos, os quais aplicam técnicas de compressão ou sobre bancos de
dados desktop ou sobre arquivos simples em dispositivos com recursos computacionais
limitados.
1.2 Objetivos
O objetivo deste trabalho é apresentar uma estratégia de compressão para sistemas de
bancos de dados relacionais em ambientes operacionais desenvolvidos para PDAs como, por
exemplo, PalmOS ou Windows Mobile, visto a necessidade de se otimizar o espaço de
memória disponível, o que é um fator crítico em tais ambientes, sem que haja queda
significativa de performance do sistema.
A estratégia de compressão apresentada neste trabalho foi implementada sobre a
arquitetura Palm Database Manager (PDM) [17]. Essa arquitetura foi especificamente
projetada para ambientes de recursos computacionais limitados e leva em consideração os
principais aspectos envolvidos em tais ambientes, minimizando suas deficiências e
possibilitando que bancos de dados relacionais sejam criados e manipulados em um handheld.
A estratégia de compressão proposta foi definida de acordo com as características inerentes a
esta arquitetura.
A PDM trabalha com o armazenamento de dados orientado a colunas. Nesse caso, os
registros de dados estão organizados fisicamente de acordo com as colunas das tabelas e não
16
de acordo com as tuplas, como ocorre na grande maioria dos sistemas. Esse tipo de
armazenamento propiciou, como será discutido mais adiante, um melhor ganho de
compressão e uma menor sobrecarga de CPU. Se tais objetivos não fossem alcançados, a
utilização de técnicas de compressão tornar-se-ia inviável em qualquer tipo de ambiente
devido a queda de performance para níveis proibitivos.
Para se analisar a eficiência da estratégia proposta, foram realizados alguns testes para
se mensurar as taxas de compressão obtidas e os possíveis aumentos de tempo de carga dos
dados. Através da análise desses resultados experimentais, é possível se avaliar a importância
da utilização de técnicas de compressão em tais ambientes, determinando-se assim se tal
estratégia mostra-se viável e eficiente em dispositivos com recursos computacionais
limitados.
1.3 Estrutura do Trabalho
Esta dissertação está organizada da seguinte forma: no Capítulo 2 é descrita a estrutura
tradicional de armazenamento de dados em dispositivos em um ambiente com recursos
computacionais limitados, no caso o sistema operacional dos dispositivos Palm (Palm OS). É
exposto também como funciona um sistema de armazenamento de dados orientado a colunas
que é o tipo de armazenamento adotado neste trabalho. Finalmente, é apresentada uma
estratégia de armazenamento eficiente de dados que utiliza a estratégia de orientação por
colunas.
O Capítulo 3 discute a utilização de estratégias de compressão de banco de dados em
ambiente com recursos computacionais limitados. Além de mostrar as principais
características desse tipo de ambiente, este capítulo analisa ainda quais os tipos de técnicas ou
algoritmos de compressão que poderiam ser adequados em tal contexto.
O Capítulo 4 apresenta a idéia central deste trabalho onde são discutidos os tipos de
técnicas de compressão de dados utilizadas e são apresentados os motivos pelos quais essas
técnicas foram escolhidas para este trabalho.
O Capítulo 5 analisa como se dará o acesso aos dados comprimidos pelas técnicas de
compressão discutidas no Capítulo 4. Para cada tipo de técnica de compressão utilizada, o
17
acesso aos dados relativos a essa técnica é analisado. Este capítulo complementa a idéia
central do trabalho que é apresentada no capítulo anterior.
O Capítulo 6 apresenta os resultados experimentais que foram obtidos com a
implementação deste trabalho. São discutidos os ganhos ou perdas decorrentes da utilização
das técnicas de compressão sobre os dados. Através de tabelas e gráficos, será demonstrado
qual a viabilidade e os impactos da utilização da estratégia de compressão apresentada.
Finalmente, o Capítulo 7 analisa a estratégia de compressão de dados apresentada
neste trabalho e discute os principais ganhos que são alcançados por essa estratégia. São
apresentados ainda alguns temas de trabalhos futuros que podem ser desenvolvidos com base
na idéia aqui discutida.
18
2. Armazenamento de Dados
2.1 Introdução
Para demonstrar as singularidades presentes em arquiteturas de dispositivos móveis de
uma maneira geral e ilustrar de que forma a estratégia de compressão aplicada pode lidar com
as limitações de tais ambientes, este trabalho utilizou a estrutura de armazenamento presente
em ambientes Palm OS. No entanto, é importante destacar que a abordagem apresentada pode
ser utilizada em qualquer outro ambiente com características similares como, por exemplo, o
Windows Mobile para o Pocket PC.
Neste capítulo, será discutido como funciona o sistema de armazenamento de dados
em dispositivos que utilizam esse sistema operacional (Palm OS) e de que forma as
singularidades presentes em tal estrutura de armazenamento determinaram o tipo de
abordagem mostrada e utilizada para validar esta proposta.
Este capítulo está assim estruturado. A seção 2.2 apresenta a estrutura tradicional de
armazenamento de dados em ambientes Palm OS. São expostos os principais detalhes desse
tipo de implementação e as principais deficiências dessa arquitetura.
A seção 2.3 apresenta uma outra abordagem para o armazenamento de dados: a
arquitetura orientada a colunas. Nesse caso, a orientação dos registros de dados muda de tupla
para coluna, ou seja, as colunas é que são armazenadas de forma contígua no disco.
Finalmente, a seção 2.4 apresenta a estratégia de armazenamento de dados utilizada
nesta proposta. Essa estratégia visa otimizar o armazenamento e o acesso dos dados e são
discutidos os motivos pelos quais isso pode ocorrer.
2.2 Estrutura de Armazenamento de Dados no Ambiente Palm OS
Em um ambiente Palm OS, as memórias RAM e ROM situam-se em um módulo de
memória conhecido como card (ou cartão). Um cartão de memória é, na verdade, apenas uma
estrutura lógica utilizada pelo Palm OS. Um determinado dispositivo tanto pode trabalhar sem
nenhum quanto com múltiplos cartões.
19
O conjunto principal de aplicações existentes em cada dispositivo é construído na
memória ROM. Tal característica permite a substituição do sistema operacional e de todo o
conjunto de aplicações através de uma simples instalação de um módulo substituto. Isto é
possível porque todos os dados do usuário podem ser salvos em um computador através de
um processo de sincronização. Com isso, após a instalação do novo módulo, basta uma nova
sincronização com o desktop para que os dados sejam recolocados no dispositivo.
O Palm OS é projetado com base em uma arquitetura de endereços de 32-bits, com
tipos de dados básicos de 1, 2 e 4 bytes. Os endereços disponíveis oferecem um total de 4 GB
de espaço para armazenamento de dados e código, embora o Palm OS trabalhe eficientemente
com pequenas quantidades de memória RAM. Para cada cartão lógico são reservados 256 MB
de espaço.
A memória RAM disponível é dividida em duas áreas lógicas: a RAM dinâmica
(análoga a RAM tradicional de um sistema desktop) e a RAM de armazenamento (análoga ao
espaço de armazenamento em disco de um sistema desktop). A RAM dinâmica é utilizada
para alocações temporárias de variáveis globais e outros tipos de dados que não necessitam de
persistência entre execuções de uma aplicação. A RAM de armazenamento oferece uma área
de armazenamento permanente para aplicações e dados. Devido à limitação de energia
inerente a tais ambientes, essas duas áreas da RAM preservam seus conteúdos quando o
dispositivo é desligado. Quando o dispositivo sofre uma operação manual de reset, a área de
armazenamento é preservada, enquanto a área dinâmica é reiniciada.
No ambiente Palm OS, todos os dados são armazenados em blocos de memória
chamados de chunk. Um chunk é uma área contígua de memória cujo tamanho varia de 1 byte
até 64 Kbytes. Essa restrição de tamanho de 64 Kbytes não está relacionada com a API de
gerenciamento de memória, portanto isto pode ser modificado futuramente. Cada chunk reside
em um heap. Alguns heaps são baseados na ROM e outros são baseados na RAM. O
Gerenciador de Memória (Memory Manager) aloca memória em um heap dinâmico e o
Gerenciador de Dados (Data Manager) aloca memória em um ou mais heaps de
armazenamento. A Figura 1 apresenta a estrutura de memória presente no ambiente Palm OS.
Todo chunk utilizado para armazenar dados é considerado um registro de um “banco
de dados” implementado pelo Gerenciador de Dados. Tal “banco de dados” é, na verdade,
uma lista de chunks de memória associada com um cabeçalho de informações, ou seja, é uma
20
estrutura análoga a um arquivo de um sistema desktop convencional. Apesar da denominação
de database, esse arquivo não possui nenhuma das propriedades de um banco de dados
relacional, tais como tabelas, colunas ou restrições de integridade. Esses “bancos de dados”
armazenam registros relacionados, mantendo uma lista de todos os registros que pertencem a
ele, através de um identificador único. Os registros de um arquivo desse tipo podem ser
intercalados com outros registros de outros arquivos na memória.
Figura 1: Arquitetura da Memória do Ambiente Palm OS
Um sistema de arquivos tradicional inicialmente lê os dados de um arquivo no disco e
guarda essas informações em um buffer de memória. Após a devida utilização desses dados, o
sistema de arquivos grava as novas informações de volta no disco. Como os dispositivos Palm
não utilizam um disco, mas sim uma memória RAM não-volátil, um sistema de arquivos
tradicional não é adequado para armazenar e recuperar dados de usuário no Palm OS. Dessa
forma, todo tipo de acesso e atualização é realizado “in place”, eliminando o overhead de
transferir os dados de e para um buffer de memória.
21
Os dados são distribuídos através de múltiplos registros de tamanho finito. Operações
de adicionar, remover ou redimensionar (através de funções nativas do sistema) um registro
não implicam em manipulações sobre outros registros. Cada registro em um arquivo é um
chunk de memória.
No ambiente Palm OS, existem três tipos de arquivos com finalidades e tipos de dados
distintos: o PDB ou Palm Database (cujo propósito é armazenar dados que são acessados
pelas aplicações); o PRC ou Palm Resource (cuja finalidade é armazenar dados na forma de
código fonte) e o PQA ou Palm Query Application (que possui dados da World-Wide Web,
que são acessados através de aplicações da Palm.Net).
Por ter como finalidade o armazenamento de dados que são acessados por outras
aplicações, o arquivo PDB é o único tipo de dado abordado neste trabalho. Tal arquivo é
organizado como uma coleção de registros e é composto pelos blocos de:
• Cabeçalho;
• Lista de entrada de registros;
• AppInfoBlock
• SortInfoBlock
• Registros de dados propriamente ditos.
A estrutura do arquivo PDB pode ser observada na Figura 2.
O cabeçalho (header) é o único bloco de tamanho fixo (72 caracteres). Nele são
armazenadas as informações de identificação do arquivo PDB (nome do arquivo, versão,
datas de criação, modificação e backup, etc.) e as localizações dos outros blocos de
informações dentro do arquivo.
A lista de entrada de registros (Record List) funciona como um índice seqüencial com
a relação de todos os registros gravados no arquivo PDB. Essa lista contém as posições
absolutas (em bytes), a partir do início do cabeçalho, das entradas dos registros do arquivo. A
primeira entrada corresponde ao primeiro registro, a segunda entrada ao segundo registro e
assim por diante. Cada entrada tem o tamanho fixo de 8 bytes.
O AppInfoBlock pode ser utilizada para guardar qualquer tipo de informação. Por
exemplo: tipos dos dados de cada registro. É comum se utilizar o AppInfoBlock para gravar as
22
informações referentes a estrutura dos campos, já que não existe nenhum suporte nativo para
isso. Outra utilidade do AppInfoBlock é armazenar a categoria de um arquivo PDB.
O SortInfoBlock destina-se a aplicações específicas do desenvolvedor. Não existe
formato nem tamanho predefinido para esse bloco. A maioria das aplicações não utiliza essa
área de dados.
O último bloco do arquivo PDB é destinado a armazenar os registros de dados
propriamente ditos. O início de cada registro foi definido na Record List. Os registros não
possuem tipo ou formato predefinido, mas devem obedecer ao limite de 64 KB [13], [14],
[15] e [16].
Figura 2: Estrutura do Arquivo PDB
Nos arquivos PDB, o Gerenciador de Dados manipula os dados como um conjunto de
registros que podem conter tipos heterogêneos de dados. Cada registro pertence a um e
somente um arquivo. Os registros de um arquivo podem estar intercalados com registros de
outros arquivos em memória. Uma aplicação pode criar, apagar, abrir e fechar arquivos da
mesma forma que um sistema de arquivos tradicional pode operar sobre um arquivo
tradicional. Tal estratégia é similar à estratégia convencional de armazenamento de dados na
maioria dos sistemas gerenciadores de bancos de dados.
Para armazenar um banco de dados nesse ambiente, a estratégia mais comum é criar
um arquivo PDB para cada tabela do banco de dados. Nesse caso, cada registro desse arquivo
armazena os dados presentes em uma determinada tupla da tabela. O conceito de coluna
23
continua existindo se imaginarmos que cada registro pode conter o mesmo número de
campos. Dessa forma, os primeiros campos de cada registro formam uma coluna do arquivo
(e da tabela). O mesmo se aplica ao conjunto dos segundos campos de cada registro – que
formariam a segundo coluna – e assim por diante.
A Figura 3, através de um exemplo de uma tabela chamada de Produtos, ilustra essa
representação. Podemos observar que os registros do arquivo PDB são compostos pelas tuplas
da tabela e o conceito de coluna é meramente lógico. A primeira tupla (composta pelos
valores 1012, ‘Caneta’ e 1,50) está armazenada no primeiro registro (registro 1); a segunda
tupla (composta pelos valores 1924, ‘Caderno’ e 16,40), no segundo registro (registro 2); a
terceira tupla (composta pelos valores 2056, ‘Borracha’ e 0,80), no terceiro registro (registro
3) e a quarta tupla (composta pelos valores 2345, ‘Lápis’ e 0,95), no quarto registro (registro
4).
Cabeçalho
Lista de Entrada de Registros (chunks)
Registro 1 1012 Caneta R$ 1,50
Registro 2 1924 Caderno R$ 16,40
Registro 3 2056 Borracha R$ 0,80
Registro 4 2345 Lápis R$ 0,95
Figura 3: Estrutura Tradicional de Armazenamento de Dados
Nesse tipo de armazenamento, para se recuperar os dados referentes a uma
determinada coluna da tabela será necessário o acesso ao campo específico de todos os
registros existentes no arquivo. A coluna referente, por exemplo, à descrição do produto
poderia ser recuperada através do acesso a todos os segundos campos de todos os registros do
arquivo. Em um PDB com 1500 registros seria necessário utilizar 1500 vezes a função
apropriada para recuperação de um registro.
24
No ambiente Palm OS, essa estrutura de armazenamento de dados não é eficiente o
bastante quando se deseja trabalhar com bancos de dados relacionais. Uma estratégia que
estruture os dados de uma forma mais adequada pode ser mais interessante nesse cenário.
O próximo capítulo analisa uma abordagem de armazenamento de dados que agrupa
em cada registro os valores de uma coluna da tabela e não de uma tupla. Essa estratégia
mostra-se mais eficiente na manipulação de dados de bancos relacionais. Além disso, o
armazenamento de dados homogêneos em uma mesma coluna representa uma grande
vantagem quando se deseja trabalhar com as técnicas de compressão aqui aplicadas. Dessa
forma, a estrutura de dados utilizada não foi a estratégia tradicional, mas sim a estratégia
descrita a seguir.
2.3 Armazenamento de Dados Orientado a Colunas
2.3.1 Armazenamento Orientado a Tuplas x Armazenamento Orientado a Colunas
A grande maioria dos sistemas de banco de dados existentes tem o seu armazenamento
de dados orientado a tuplas. Nesse caso, os dados são agrupados de acordo com as tuplas das
tabelas, ou seja, as tuplas estão armazenadas em disco em registros de dados subseqüentes.
Neste tipo de arquitetura, basta uma única operação de escrita para que todos os campos de
um único registro sejam acessados em disco. Tais sistemas são considerados otimizados para
escrita (write-optimized) [21].
No entanto, alguns sistemas lidam freqüentemente com consultas que precisam
retornar grandes blocos de dados. Ambientes desse tipo, em vez de serem otimizados para a
escrita, devem ser otimizados para leitura (read-optimized) com o objetivo de minimizar a
sobrecarga de processamento decorrente do acesso a grande quantidade de dados. Nesse caso,
uma abordagem mais eficiente poderia acessar apenas os atributos necessários para processar
uma determinada consulta o que implicaria em uma carga menor para o processador, visto que
certos atributos desnecessários a consulta não precisariam ser acessados pelo sistema.
Na estratégia de orientação por colunas (column-oriented), os valores pertencentes ao
mesmo atributo, ou seja, a mesma coluna, mas de tuplas diferentes, estão fisicamente
25
agrupados em registros subseqüentes. Em outras palavras, tal estratégia agrupa as colunas – e
não as tuplas – de forma contígua em disco. Essa homogeneização dos dados pode apresentar
várias vantagens em relação à abordagem de orientação por tuplas (row-oriented) inclusive
satisfazendo a condição desejada de acessar apenas os campos realmente necessários na
consulta.
Em uma arquitetura orientada a colunas, um sistema de bancos de dados só precisará
ler do disco os valores das colunas necessárias para processar uma determinada consulta,
evitando trazer para a memória dados irrelevantes. Tal característica representa um
considerável ganho de performance. A aplicação de uma arquitetura desse tipo em ambientes
com recursos computacionais limitados, como é o caso de dispositivos móveis, também pode
representar interessantes ganhos de processamento.
Uma outra vantagem dessa arquitetura vem do fato de que o acesso aos dados do
banco de dados pode ocorrer de forma mais rápida. Nesse caso, o deslocamento (offset)
necessário para se determinar a posição de cada valor no registro – o qual armazena
informações de um mesmo tipo – pode ser calculado mais facilmente. Em colunas que
possuam um tamanho fixo, por exemplo, uma coluna de valores numéricos com tamanho fixo
de quatro (4) bytes, o deslocamento é facilmente calculado por ser sempre um valor múltiplo
de quatro.
Mesmo em colunas com tamanho variável, onde os dados de um determinado registro
são do mesmo tipo, há ainda uma importante vantagem em relação a uma arquitetura onde os
registros armazenam dados de tipos e tamanhos totalmente variados e distintos visto que,
nesta última, é mais difícil se determinar a posição dos valores.
2.3.2 C-Store: Estratégia de Orientação a Coluna
Diferentemente da maioria dos SGBD existentes no mercado, o C-Store [1], [21]
possui como característica o fato de implementar o armazenamento orientado a colunas. Tal
abordagem assemelha o C-Store à abordagem apresentada nesse trabalho já que ambos
utilizam a estratégia de definir o armazenamento orientado a colunas em detrimento do
armazenamento orientado a tuplas no que se refere à execução de consultas.
26
Uma das características mais importantes da arquitetura proposta no C-Store é o fato
de armazenar de forma redundante uma coleção de colunas, onde cada uma dessas coleções é
ordenada de acordo com uma determinada chave. A cada um desses grupos de colunas dá-se o
nome de “projeção”.
Por exemplo, uma tabela que armazena as informações sobre os funcionários de uma
empresa – tabela Empregado – poderia ter seu conteúdo repetido em múltiplas projeções.
Em cada uma dessas projeções o atributo escolhido como chave de busca é diferente. Uma
projeção A dessa tabela poderia estar ordenada pelo atributo matricula enquanto uma
outra projeção B (contendo os mesmos dados) poderia estar ordenada pelo atributo cpf e
mais outra projeção C ordenada pelo atributo salario. Apesar do conteúdo de todas essas
projeções ser exatamente o mesmo, a ordenação varia de uma projeção para outra conforme o
atributo escolhido como chave de busca.
Devido a essa redundância, cada coluna deve existir em diversas projeções, cada qual
ordenada por um atributo diferente. Essa característica visa propiciar condições de otimização
de consultas já que dessa forma uma consulta aplicada sobre uma chave de busca A pode ser
executada sobre a projeção na qual o atributo que a ordena seja o atributo A, no caso a
projeção mais vantajosa para essa consulta.
Outra característica fundamental dessa proposta é uma arquitetura híbrida com a
combinação de uma estratégia de armazenamento orientado a leitura e uma estratégia de
armazenamento orientado a escrita e atualização. O C-Store utiliza um componente otimizado
para freqüentes operações de inserções e atualizações e um componente otimizado
especificamente para desempenho de consultas.
Os componentes utilizados na estrutura apresentada são o Writeable Store (WS), o
Read-optimized Store (RS) e o Tuple Mover. O componente WS é projetado para suportar alto
desempenho em operações de inserções e atualizações. O componente RS tem a função de
suportar leitura de grande quantidade de dados com o objetivo de otimizar o processo de
leitura. O Tuple Mover é o conector entre esses dois componentes e tem a finalidade de
propiciar a movimentação de blocos de registros do WS para o segmento do RS
correspondente. A Figura 4 ilustra a arquitetura do C-Store em relação a esses três
componentes
27
Figura 4: Componentes da arquitetura do C-Store
As consultas podem acessar dados em ambos os sistemas de armazenamento. As
inserções são submetidas ao WS, as remoções são marcadas no RS para posterior retirada
pelo Tuple Mover e as atualizações são formadas por operações de inserção seguidas por
operações de remoção.
Uma inserção é representada como uma coleção de novos objetos no WS, sendo um
objeto para cada coluna para cada projeção, e a chave de ordenação da estrutura de dados.
Todas as operações de inserção correspondentes a um mesmo registro lógico possuem um
identificador em comum chamado de chave de armazenamento.
O C-Store utiliza ainda técnicas de compressão em sua arquitetura. O tipo de técnica
utilizada para uma determinada coluna depende de sua própria ordenação (self-order) ou dos
valores correspondentes de alguma outra coluna na mesma projeção (foreign-order). Os
quatro tipos de técnicas são:
• Tipo 1 (self-order com poucos valores distintos): a coluna é representada por
uma seqüência de triplas (v, f, n), onde v é o valor contido na coluna, f é a
posição na coluna da primeira ocorrência de v e n é a quantidade de
ocorrências de v na coluna. Em colunas do tipo self-order, existe uma tripla
para cada valor distinto dessa coluna.
• Tipo 2 (foreign-order com poucos valores distintos): a coluna é representada
por uma seqüência de tuplas (v, b) onde v é o valor contido na coluna e b é uma
seqüência de bits indicando as posições nas quais os valores estão contidos.
• Tipo 3 (self-order com muitos valores distintos): a coluna é representada por
uma seqüência onde cada valor é calculado com base na diferença para o valor
Writeable Store (WS)
Read-optimized Store (RS)
Tuple Mover
28
anterior. Por exemplo, o conjunto de valores 1,4,7,7,8,12 seria representado
pela seqüência 1,3,3,0,1,4.
• Tipo 4 (foreign-order com muitos valores distintos): nesse caso, ainda não
foram definidas técnicas de compressão adequadas até mesmo pelo fato de que
faria mais sentido, pela grande quantidade de valores, mantê-los de forma não-
codificada.
Nos resultados obtidos, quando comparado a estratégias que utilizavam orientação a
tuplas ou orientação a colunas puras, sem funcionalidades adicionais, o C-Store mostrou-se
consideravelmente superior na performance das consultas. As principais razões são:
• A representação por coluna evita leituras de atributos desnecessários. Somente
aqueles atributos envolvidos em uma determinada consulta precisarão ser lidos.
Atributos que, por outro lado, não façam parte da consulta, não precisarão ser
acessados.
• A redundância de dados na forma de múltiplas projeções permite o
armazenamento de múltiplas ordenações de uma mesma coluna e a utilização
da projeção mais eficiente para cada tipo de consulta.
• A compressão de dados permite mais ordenações no mesmo espaço. A medida
que o espaço de memória é otimizado, é possível o armazenamento de uma
quantidade maior de projeções.
• Os operadores de consulta podem ser executados na representação comprimida
evitando assim o esforço adicional de descomprimir esses dados.
Em todos os testes realizados com o C-Store, o tempo de resposta da estratégia
orientada a coluna mostrou-se muito menor do que na estratégia de orientação a tuplas. Além
disso, de um modo geral a arquitetura híbrida do C-Store mostrou-se mais eficiente do que as
estratégias orientada a tuplas e orientada a colunas. Uma possibilidade de futuras análises para
este trabalho é a utilização da estratégia híbrida no lugar da estratégia orientada apenas a
colunas.
No entanto, é importante ressaltar que o C-Store foi aplicado sobre um ambiente
desktop convencional no qual a questão do espaço de memória não é tão significante. Em
29
ambientes com restrições de recursos computacionais, como é o caso dos ambientes para os
quais este trabalho se aplica, a estratégia de redundância de dados, através da criação de várias
projeções das tabelas poderia se tornar proibitiva devido à própria limitação de memória
inerente aos dispositivos desse tipo. Dessa forma, apesar dos bons resultados alcançados pela
arquitetura híbrida utilizada pelo C-Store, a estratégia utilizada neste trabalho – orientada a
colunas – permanece como a estratégia com o melhor custo benefício para o sistema.
De qualquer forma, a superioridade de abordagem orientada a colunas sobre a
abordagem orientada a tuplas, demonstrada por todos os testes realizados pelo C-Store,
reforça as principais qualidades da arquitetura apresentada nesse trabalho. Os principais
motivos para isso são:
• Ambas as propostas utilizam o armazenamento orientado a colunas no lugar do
tradicional armazenamento orientado a tuplas existente na maioria dos SGBDs
do mercado. Tal característica tem por natureza a otimização das consultas e
são fundamentais para a melhoria na performance do banco de dados.
• Apesar dos tipos serem distintos, o fato de ambas as estratégias utilizarem
técnicas de compressão em suas abordagens indica o quanto essa questão é
importante na otimização de desempenho do banco de dados. Além disso, as
técnicas de compressão utilizadas nesse trabalho combinam com o tipo de
arquitetura utilizada (compressão por coluna e armazenamento orientado a
coluna).
• O fato dos operadores poderem trabalhar diretamente sobre os dados no
formato comprimido, tanto no C-Store quanto na PDM, são imprescindíveis
para manterem o alto nível de desempenho obtido. De outra forma, o esforço
de se descomprimir todos os dados a cada utilização seria totalmente proibitivo
para ambas as abordagens.
A próxima seção apresenta uma estratégia de armazenamento de dados para
dispositivos móveis com recursos computacionais limitados que leva em consideração as
características inerentes a ambientes desse tipo. Essa arquitetura provê uma maneira de se
armazenar e recuperar mais eficientemente as informações de um banco de dados em tais
dispositivos.
30
2.4 Estratégia de Armazenamento Eficiente de Dados
A arquitetura PDM [17] propõe um formato de armazenamento de dados orientado a
colunas para ambientes de dispositivos móveis com recursos computacionais limitados.
Basicamente, a idéia consiste em armazenar em cada registro (chunk) as informações de um
mesmo tipo de dado, ou seja, de uma mesma coluna, contrastando com o armazenamento
tradicional orientado a tuplas.
A disposição dos dados permanece seqüencial e o acesso é realizado da mesma
maneira, através de operações de deslocamento (offset). Como a identificação do início e do
final de cada campo varia de acordo com o tamanho do tipo definido, a abordagem proposta
facilita essa identificação porque os dados presentes em um mesmo registro são mais
homogêneos por serem do mesmo tipo [18].
A Figura 5 ilustra a estratégia utilizada, mostrando como seria o armazenamento dos
dados em um arquivo PDB. No exemplo, o arquivo possui uma lista de produtos de uma
empresa. Para cada um dos quatros produtos do exemplo, há um determinado código, uma
descrição e um preço. O primeiro registro armazena os dados da coluna referente aos códigos
dos produtos; o segundo registro armazena os dados da coluna referente à descrição de cada
produto e o terceiro e último registro armazena os dados da coluna referente aos preços de
cada produto.
Para se acessar os dados de uma determinada coluna (projeção), é preciso recuperar
todo o registro de dados correspondente a essa coluna. Nesse caso, como todas as informações
de uma mesma coluna estão em um único registro, será necessário acessar apenas esse
registro para recuperar as informações desejadas. Isso constitui uma vantagem fundamental
do armazenamento orientado a colunas quando comparado com o tradicional armazenamento
orientado a tuplas.
De uma maneira geral, a execução de consultas com projeções torna-se mais rápida do
que na estratégia tradicional devido à diminuição da quantidade de registros acessados. O
acesso aos dados estaria restrito apenas aos registros das colunas que fazem parte da consulta
enquanto que na abordagem tradicional todos os registros (tuplas) do arquivo precisariam ser
acessados.
31
Cabeçalho
Lista de Entrada de Registros (chunks)
Registro 1 1012 1924 2056 2345
Registro 2 Caneta Caderno Borracha Lápis
Registro 3 R$ 1,50 R$ 16,40 R$ 0,80 R$ 0,95
Figura 5: Estrutura de Armazenamento de Dados Adotada
Em situações nas quais apenas uma coluna faz parte da consulta, será necessário
apenas o acesso a um único registro, no caso, o registro correspondente a essa coluna. Esse
caso representa uma situação na qual a estratégia de armazenamento orientada a colunas
consegue sua melhor otimização quando comparada com a estratégia de armazenamento
orientada a tuplas [3].
Por outro lado, na execução de consultas com filtros horizontais (operação de seleção),
a abordagem tradicional pode ser mais eficiente do que na estratégia descrita, pois nesta
última será necessário se realizar o acesso a todos os registros do PDB para se recuperar
tuplas inteiras [18].
No entanto, essa desvantagem é minimizada através da utilização do conceito de
deslocamento. Esta técnica consiste no cálculo da posição física de um determinado campo.
Para isso, é necessário se levar em consideração o tipo do dado que está sendo armazenado no
registro físico e, de acordo com o espaço previamente estabelecido para tal tipo, pode-se
calcular a posição do campo procurado.
Dessa forma, para se realizar uma determinada consulta, inicialmente é necessária a
identificação das tuplas que satisfazem à condição de seleção. A busca pelo valor desejado
será realizada apenas no primeiro registro. Os registros subseqüentes serão acessados a partir
das posições (índices) previamente encontradas. Com essa estratégia, conquista-se um
importante ganho de desempenho visto que a busca pelas tuplas desejadas se dá apenas no
registro inicial.
32
Outra característica importante desta abordagem é a maior facilidade na manutenção
dos esquemas das tabelas. Para se incluir uma nova coluna na tabela, basta se realizar a
inclusão de um novo registro no PDB. Situação equivalente acontece para a operação de
exclusão na qual, para se remover uma determinada coluna somente é necessária uma
operação simples de remoção de um registro. As operações de inclusão e remoção de registros
são realizadas de forma rápida pelo sistema.
A abordagem descrita permite a manipulação dos dados como se estes estivessem
armazenados em banco de dados relacionais. Com isso, torna-se possível a criação de
mecanismos que garantam a consistência dos dados, tais como as restrições de integridade,
melhorem o gerenciamento dos esquemas do banco e possibilitem uma maior padronização
no armazenamento dos dados. Nada disso é possível no esquema tradicional de
armazenamento desses dispositivos porque este esquema funciona apenas como um simples
sistema de arquivos, sem nenhuma das características fundamentais de um ambiente de banco
de dados relacional.
Conforme as condições oferecidas nessa abordagem, os dados existentes em tais
ambientes de banco de dados podem ser manipulados através do conceito relacional com uma
maior garantia de consistência e com maiores facilidades para ambientes com limitação de
recursos computacionais. Vale ressaltar que esta abordagem pode ser implementada em
qualquer sistema operacional desenvolvido para PDAs como, entre outros, Palm OS ou
Pocket PC.
Essa estratégia oferece ainda uma estruturação de dados mais adequada para a
aplicação das técnicas de compressão utilizadas [3]. Em um banco de dados com
armazenamento de dados orientado a colunas, conforme será vista mais adiante neste
trabalho, tais técnicas podem ser aplicadas de uma maneira mais eficiente porque os dados
presentes em um mesmo registro são homogêneos, já que fazem parte de uma mesma coluna
tendo, portanto o mesmo tipo de dado.
Em sistemas tradicionais, orientados a tuplas, as técnicas utilizadas não se comportam
tão bem porque os valores que compõem uma coluna encontram-se espalhados por diferentes
registros, ou seja, os dados presentes um determinado registro podem ser de vários tipos
diferentes conforme pode ser observado na Figura 3.
33
Como será visto nos próximos capítulos, o armazenamento dos dados de uma mesma
coluna em um único registro permite que as técnicas de compressão utilizadas neste trabalho
sejam aplicadas de uma maneira mais adequada.
34
3. Estratégias de Compressão em Bancos de Dados
3.1 Introdução
Este capítulo faz um resumo das principais técnicas e algoritmos de compressão
existentes e analisa quais os fatores que tornam essas técnicas e algoritmos adequados ou
proibitivos a ambientes de banco de dados e/ou a ambientes de dispositivos com limitação de
recursos.
Este capítulo está estruturado como descrito a seguir. Na seção 3.2, são analisadas as
principais vantagens e desvantagens de se utilizar técnicas de compressão em ambiente de
banco de dados. Através desta análise, é possível identificar se a utilização das técnicas ou
algoritmos de compressão torna-se viável no ambiente em questão, no caso, um sistema de
banco de dados para dispositivos móveis com recursos computacionais limitados.
A seção 3.3 descreve e discute as principais técnicas e algoritmos de compressão
existentes analisando de que forma cada um funciona e como se comportará no ambiente
específico de banco de dados. Com isso, é possível determinar quais os tipos de compressão
que são proibitivos neste contexto.
Finalmente, a seção 3.4 discute dois fatores importantes na escolha das técnicas e
algoritmos de compressão analisados: complexidade e granularidade. Tais fatores podem, por
si só, determinar quais técnicas de compressão não se adequam ao ambiente da proposta.
3.2 Vantagens e Desvantagens da Utilização de Compressão sobre os Dados
A utilização de técnicas de compressão em um sistema de bancos de dados oferece
duas importantes vantagens:
• Redução do espaço de armazenamento e
• Aumento de performance devido à diminuição da quantidade de leituras físicas
necessárias.
35
A primeira vantagem é a mais óbvia e é diretamente obtida por qualquer tipo de
técnica de compressão utilizada. Apesar de ser um fator importante, especialmente no que se
refere a dispositivos com recursos computacionais limitados, essa vantagem é freqüentemente
discutida devido à constante diminuição nos preços de recursos de armazenamento.
Para alguns pesquisadores, os ganhos de espaço obtidos com a utilização de técnicas
de compressão não são suficientemente importantes para compensar as possíveis perdas que
tais técnicas podem causar. Essas perdas estão diretamente relacionadas com possíveis
sobrecargas de processamento resultantes da necessidade de se comprimir e descomprimir os
dados a cada acesso a estes. Isso poderia tornar proibitivo o uso de técnicas de compressão.
A segunda vantagem decorre do fato de que, ao se utilizar técnicas de compressão,
uma maior quantidade de dados pode ser carregada do disco para a memória principal a cada
operação. Em sistemas de bancos de dados tradicionais, tal aspecto resulta em um menor
número de acesso a discos e conseqüentemente em um aumento na performance geral do
banco de dados.
No entanto, as técnicas de compressão podem resultar em uma considerável
sobrecarga de CPU devido à freqüente compressão e descompressão dos dados que estiverem
sendo utilizados, o que pode aumentar consideravelmente o tempo de respostas de certas
operações. Essa desvantagem é constantemente considerada um fator crítico que poderia
inibir a utilização de estratégias de compressão em bancos de dados, pois qualquer tipo de
ganho obtido poderia ser inviabilizado por essa característica negativa. Conseqüentemente,
este aspecto precisa essencialmente ser minimizado quando se trabalha com compressão em
bancos de dados.
O ideal é que os dados sejam mantidos no formato comprimido o maior tempo
possível e que sejam descomprimidos apenas quando e se for realmente necessário. Se uma
determinada consulta deve retornar apenas o nome e o departamento de um determinado
empregado outros atributos como matrícula ou salário não precisariam ser descomprimidos.
Além disso, mesmo os campos nome e departamento seriam descomprimidos apenas no
momento da execução dessa consulta.
Essa estratégia é conhecida como descompressão preguiçosa (lazy decompression).
Dessa forma, o montante de dados sendo comprimido e descomprimido diminui e o problema
de sobrecarga de CPU relativo a esse problema é sensivelmente minimizado [4].
36
Para ilustrar a aplicação da estratégia supracitada, considere uma determinada consulta
sobre a tabela empregados que deseja retornar todos os empregados com matrícula variando
de 4000 a 5000. Suponha que a tabela empregados possua 10.000 tuplas, sua chave primária
seja o atributo matricula e que existam 5 tuplas por páginas resultando em 2.000 páginas para
essa tabela. Poderíamos considerar, por exemplo, que as tuplas que satisfaçam essa condição
estejam entre as páginas 800 e 1000.
Em um cenário em que os dados não estão comprimidos, a consulta acima precisaria
inicialmente de h acessos a disco para acessar a primeira página relevante através do índice. O
valor h se refere à altura da árvore B definida como índice dessa tabela. No pior caso, seriam
necessários mais 200 acessos a disco (páginas 800 a 1000) para se recuperar todas as
informações desejadas. Dessa forma, o número de acessos a disco seria calculado por h + 200.
Em um outro cenário, onde a tabela empregados estivesse comprimida com uma taxa
de 50%, poderíamos supor que as tuplas que satisfazem a condição estivessem entre as
páginas 400 e 500 (metade das páginas do exemplo sem compressão). Nesse caso, utilizando-
se uma técnica de compressão adequada, onde apenas as tuplas que satisfazem a condição
fossem descomprimidas, o número de acessos a disco no pior caso cairia de h + 200 para h +
100 (páginas 400 a 500).
Finalmente, poderíamos supor um último cenário similar ao anterior, mas com a
diferença de que a técnica de compressão utilizada precisasse descomprimir as tuplas de
empregados desde o início da relação até as tuplas que satisfazem a condição, mesmo tuplas
que seriam desnecessárias para essa consulta. Nesse caso, para acessar as tuplas entre as
páginas 400 e 500, seria necessária a descompressão adicional de todas as 400 primeiras
páginas dessa tabela. Dessa forma, o número médio de acessos a disco subiria para h + 100 +
400 (h + 500), o que anularia completamente qualquer ganho de performance que viesse a ser
obtido.
Podemos, então, perceber que a utilização de uma estratégia de compressão adequada
pode otimizar a performance do banco de dados no que diz respeito a quantidade de acessos a
disco. A próxima seção apresenta algumas das técnicas e algoritmos de compressão mais
utilizadas em sistemas computacionais.
37
3.3 Técnicas e Algoritmos de Compressão
As principais técnicas de compressão podem ser classificadas, basicamente, em dois
modelos: estatístico e baseado em dicionário.
Nos modelos estatísticos, cada caractere dos dados de entrada recebe uma codificação
de acordo com sua probabilidade de ocorrência. Os algoritmos mais conhecidos e utilizados
pertencentes a esse modelo são a codificação Huffman e a codificação aritmética.
A codificação de Huffman [10] é um método de compressão que utiliza as
probabilidades de ocorrência dos caracteres no conjunto de dados de entrada para determinar
códigos de tamanho variável para cada símbolo. Uma árvore binária completa (a árvore de
Huffman) é construída recursivamente com base em um processo de substituição dos
símbolos do conjunto de entrada. As folhas da árvore são formadas pelos caracteres do
alfabeto de entrada. Cada nó da árvore é rotulado com 1 bit (0 ou 1) e o código de um
caractere é formado pela seqüência de bits obtida pelo caminho da raiz até o nó
correspondente a esse caractere. Os caracteres mais freqüentes nos dados de entrada recebem
códigos mais curtos e os caracteres menos freqüentes recebem códigos mais longos.
Já a codificação aritmética ([23], [6]) é um algoritmo de compressão que não se baseia
em tabelas de símbolos. A partir de um modelo estatístico, é construída uma tabela com as
probabilidades do próximo símbolo lido ser um dos possíveis símbolos. Normalmente, tal
probabilidade é determinada simplesmente através da razão entre o número de ocorrências
desse símbolo no arquivo e o tamanho do próprio arquivo. A tabela é expressa na forma de
intervalos cumulativos e o algoritmo de codificação aritmética consiste em representar a
probabilidade de ocorrência de cada caractere de acordo com esses intervalos.
No modelo baseado em dicionário, cada cadeia de caractere é substituída por um
código que a identifica unicamente. Essas associações são armazenadas numa estrutura
auxiliar chamada de dicionário. O esquema LZW (Lempel-Ziv-Welch) [24] é um exemplo
desse modelo. Esse algoritmo tem o objetivo de evitar a utilização de um caractere literal
junto com o endereço de dicionário. Para isso, o dicionário já é criado com todos os símbolos
do alfabeto.
Os algoritmos de compressão podem também ser classificados em adaptativos,
estáticos e semi-estáticos. Os métodos adaptativos (como o LZ) reúnem as estatísticas sobre
38
os dados durante a compressão; os métodos estáticos reúnem essas informações
antecipadamente e os métodos semi-estáticos o fazem durante o re-processamento. Os
modelos adaptativos não são adequados a bancos de dados porque necessitam de grandes
blocos de dados como entrada para obterem boas taxas de compressão. Como a granularidade
dos algoritmos de compressão deve ser fina, somente os métodos estáticos e semi-estáticos
são aceitáveis [5], [12].
Nos esquemas adaptativos baseados em dicionário (família LZ), cada parte do texto
codificado depende da parte anterior. Dessa forma, a descompressão não pode ser aplicada em
pequenas partes dos dados.
A próxima seção discute alguns dos principais fatores que determinam quais tipos de
técnicas de compressão podem ser utilizadas de forma adequada em ambientes de bancos de
dados e quais técnicas mostram-se proibitivas em tais contextos.
3.4 Complexidade e Granularidade de Algoritmos
Para a aplicação eficiente de técnicas de compressão em bancos de dados, algumas
questões importantes precisam ser definidas, tais como: o algoritmo e a granularidade da
compressão. Esses fatores mostram-se de fundamental importância quando é preciso analisar
quais tipos de técnicas de compressão podem ou não ser adequadas para o ambiente em
questão.
Quanto à complexidade do algoritmo utilizado, é importante que a descompressão dos
dados seja realizada rapidamente, de forma a minimizar a sobrecarga no processamento do
sistema. Dessa forma, apenas métodos simples, ou seja, métodos que não necessitem de
muito poder de processamento, devem ser utilizados. Por outro lado, métodos complexos, que
necessitem de muito esforço da CPU, podem se tornar inviáveis para certas operações em
ambientes de bancos de dados.
Quanto à granularidade, a compressão pode ser aplicada, normalmente, em quatro
diferentes níveis: nível de arquivo, nível de página, nível de tupla e nível de atributo (ou
coluna). Os dois primeiros níveis necessitam que uma grande quantidade de dados seja
comprimida e descomprimida a cada operação de acesso à relação causando uma sobrecarga
39
proibitiva. Nesses casos, mesmo que a consulta seja apenas sobre uma única tupla, todo o
arquivo ou página precisa ser descomprimido pelo algoritmo, visto que essa é sua unidade
básica de compressão/descompressão [8].
Por outro lado, a granularidade de atributo apresenta taxas de compressão inferiores e
não permite a utilização de métodos adaptativos. No entanto, a descompressão é aplicada
apenas em uma pequena quantidade de dados eliminando a sobrecarga de processamento.
Dessa forma, apenas técnicas de granularidade fina, ou seja, realizadas sobre unidades de
dados pequenas, são permitidas para que seja possível o acesso aleatório a pequenas partes
dos dados.
Apesar da vasta diversidade de tipos de técnicas de compressão existentes, apenas um
pequeno grupo pode ser utilizado de maneira eficiente em sistemas de bancos de dados, visto
que os fatores expostos na seção anterior precisam ser levados em consideração.
Algoritmos tradicionais como o Lempel-Ziv necessitam descomprimir uma grande
quantidade de dados mesmo quando apenas parte desses dados é realmente necessária à
operação. Tais algoritmos não são adequados a sistemas de bancos de dados porque
incorreriam em um processamento desnecessário ao comprimir e descomprimir grandes
blocos de dados.
Outros tipos de algoritmos necessitam de alto poder de processamento e tal
complexidade os torna inadequados a sistema de bancos de dados na medida que resultariam
em um significante aumento na sobrecarga de CPU. Como visto anteriormente, tal
característica representaria uma queda na performance do sistema.
Devido à heterogeneidade de tipos dos atributos, uma estratégia de compressão de
bancos de dados eficiente poderia utilizar diferentes métodos de compressão para
diferentes tipos de dados, aplicando-se a mesma técnica em toda a coluna. Além disso, como
explicado anteriormente essas técnicas precisariam ser as mais simples possíveis para não se
gerar uma sobrecarga de processamento proibitiva.
Finalmente, os métodos de compressão utilizados devem ser de granularidade fina e
extremamente rápidos de forma a melhorar o tempo de resposta. Esse segundo requisito
torna-se particularmente ainda mais importante em dispositivos com recursos computacionais
40
limitados. Como existem diversas opções para comprimir uma tabela, a escolha da técnica
errada pode prejudicar consideravelmente a performance de um banco de dados.
A estratégia apresentada neste trabalho reúne, portanto, diferentes técnicas simples de
compressão aplicando cada uma dessas técnicas especificamente sobre um determinado tipo
de dado [3].
O próximo capítulo discute a estratégia de compressão utilizada nesta proposta,
detalhando os diferentes tipos de técnicas de compressão que a compõem e que são
específicas para cada tipo de dado.
41
4. Estratégias de Compressão Para Ambientes Com Restrição Computacional
4.1 Introdução
Conforme visto no último item do capítulo anterior, a estratégia de compressão mais
adequada em ambientes de banco de dados armazenados em dispositivos com recursos
computacionais limitados deveria fazer uso de uma série de técnicas simples que seriam em
conjunto eficientes.
Dessa forma, em vez de se utilizar apenas um determinado método, poderíamos
aplicar vários métodos dependendo do tipo de dado presente em cada coluna das tabelas do
banco de dados.
Essas técnicas de compressão são analisadas ao longo desse capítulo, discutindo-se
suas principais características e de que forma sua utilização pode representar ganhos de
performance para um ambiente de banco de dados para dispositivos com recursos
computacionais limitados.
Este capítulo está assim estruturado. A seção 4.2 apresenta as necessidades básicas que
foram identificadas e que precisam ser atendidas no ambiente da proposta. Nesta seção, é
exposta a estratégia de compressão a ser utilizada no trabalho e de que forma esta estratégia
poderá atender os objetivos previamente discutidos.
A seções 4.3, 4.4 e 4.5 discutem, respectivamente, as técnicas de compressão
utilizadas para os dados comprimidos dos tipos Inteiro, Booleano e String. São apresentadas
as principais particularidades de cada uma dessas técnicas e quais as possíveis reduções de
espaço que essas técnicas de compressão podem conquistar.
4.2 Definições Básicas
Devido à heterogeneidade de tipos dos atributos, uma estratégia de compressão de
bancos de dados eficiente poderia utilizar métodos de compressão diferentes para tipos de
dados diferentes. Dessa forma, podemos aplicar técnicas de compressão que se comportem
42
mais adequadamente sobre determinados tipos de dados. Além disso, é importante que a
mesma técnica de compressão seja aplicada sobre toda a coluna. É importante destacar que tal
característica combina com o tipo de armazenamento de dados utilizada nesta proposta:
orientado a coluna [3].
De acordo com o que já foi discutido anteriormente, a estratégia de compressão
utilizada nesta abordagem é composta por várias técnicas de compressão leves (não podem
demandar muito poder de processamento do sistema) e rápidas (devem ser executadas em um
curto espaço de tempo, senão tornam-se proibitivas). Essas técnicas devem compartilhar a
mesma idéia fundamental, mas podem apresentar suas próprias particularidades.
São utilizados cinco tipos primitivos diferentes de dados:
• Inteiro;
• String;
• Booleano;
• Float e
• Date.
Por questões de custo-benefício, a estratégia de compressão não foi utilizada sobre os
tipos Float e Date, visto que nenhuma das técnicas analisadas se mostrou suficientemente
eficiente para ser utilizada de forma que compensasse possíveis sobrecargas de
processamento. No entanto, para os outros três tipos de dados (Inteiro, String e Booleano),
foram utilizadas técnicas com características semelhantes, mas com particularidades próprias
e diretamente adequadas para cada tipo de dado ao que se destina. Tais técnicas serão
discutidas no restante desse capítulo.
4.3 Compressão Numérica
Essa técnica é baseada na supressão de nulos e codificação do tamanho do valor
comprimido. A idéia principal consiste em eliminar os zeros iniciais da representação de um
número inteiro, ou seja, utilizar a menor quantidade possível de bits para armazenar tais
valores. Por exemplo:
43
• O valor inteiro 1 (representação binária 00000001 levando-se em consideração
apenas 1 byte) só precisaria de 1 bit para ser gravado. Os sete primeiros bits
(todos iguais a zero) poderiam ser eliminados da representação binária do
número sem que isso alterasse seu valor.
• No entanto, o valor 100 (representação binária 01100100) precisaria de no
mínimo 7 bits para ser codificado. O primeiro bit (igual a zero), pelo mesmo
motivo apresentado no exemplo anterior, poderia ser removido de sua
representação binária.
Quanto maior o número de bytes destinados para esses valores, maior seria o número
de bits iniciais (todos iguais a zero) que poderiam ser removidos da representação binária
desses números.
Contudo, para que o sistema pudesse operar a esse nível de bits, ou seja, conseguisse
calcular corretamente a delimitação entre bits dos diferentes valores em seqüência a
quantidade de processamento necessária poderia afetar a performance do sistema. Com isso,
por essa questão de custo-benefício entre redução de espaço e provável perda de performance,
o esquema de codificação proposto neste artigo não trabalhará ao nível de bits, mas sim ao
nível de bytes.
Nesse caso, o algoritmo não eliminará os primeiros bits iguais a zero da representação
binária do número, mas sim os primeiros bytes iguais a zero. Assim, por exemplo, tanto o
inteiro de valor 1 quanto o inteiro de valor 100 seriam armazenados com a mesma quantidade
de bits – 8 – ou seja, em um único byte, o que mesmo assim ainda representa uma economia
de espaço em comparação com a maioria dos sistemas (Windows, Palm OS, Windows
Mobile, etc.), nos quais os inteiros – quaisquer que sejam esses números – são armazenados
com, pelo menos, 4 bytes.
Esse “alinhamento a byte”, apesar de representar uma menor economia de espaço,
resulta em uma maior velocidade de acesso aos dados – principalmente quando aplicado em
ambientes de dispositivos com recursos computacionais limitados – e foi escolhido por
apresentar uma melhor performance. O motivo dessa maior rapidez no acesso aos dados se
deve ao fato de que não será necessário o cálculo bit a bit do número (o que é bastante
oneroso ao sistema), mas sim byte a byte (bem mais rápido).
44
As Figuras 6 e 7 ilustram a diferença entre o armazenamento de dados sem e com a
utilização da técnica de compressão numérica. No primeiro exemplo (Figura 6), os valores 23,
23.782.348 e 58.316 são armazenados no formato não-comprimido com quatro bytes cada um
totalizando 12 bytes utilizados para esse armazenamento. Porém, de acordo com a idéia da
compressão numérica apresentada, o algoritmo poderia eliminar os primeiros bytes iguais a
zero da representação numérica desses valores.
Figura 6: Representação binária de valores não comprimidos
Podemos observar que o valor 23 possui seus três primeiros bytes iguais a zero e o
valor 58.316 possui seus dois primeiros bytes iguais a zero. Utilizando-se a técnica de
compressão numérica acima exposta haverá uma redução de cinco bytes desnecessários (os
três primeiros bytes do valor 23 e os dois primeiros bytes do valor 58.316). Assim, cinco
bytes que tinham valor igual a zero foram removidos e esse espaço foi liberado para utilização
por outros dados, conforme pode ser observado na Figura 7. É importante lembrar que apenas
os bytes iniciais da representação binária podem ser eliminados. Bytes iguais à zero em
posição intermediária, ou seja, após a existência de um byte diferente de zero, não podem ser
eliminados.
45
Figura 7: Representação Binária de Valores Comprimidos
No entanto, o algoritmo precisa saber com quantos bytes cada valor foi armazenado.
No caso acima, os valores 23, 23.782.348 e 58.316 utilizaram, respectivamente, 1, 4 e 2 bytes
para seu armazenamento. Dessa forma, um ponto chave desse tipo de técnica de compressão é
a necessidade de armazenamento do número de bytes destinado a armazenar os valores.
Esta informação será necessária no momento do acesso aos dados porque o sistema
precisa saber quantos bytes (ou bits) devem ser lidos para um determinado valor e não há
nenhum tipo de delimitação, pois os bytes estão armazenados de forma seqüencial. O sistema
precisa destinar algum local para armazenar essa informação para cada valor comprimido,
levando em consideração que isso deve ser feito de maneira que não represente um viés
significativo para a estratégia.
No próximo capítulo, será apresentada uma estratégia para gravar e recuperar esta
informação. Com isso, o sistema deve estar preparado para conseguir acessar cada valor
comprimido de forma eficiente.
46
4.4 Compressão de Booleano
A idéia central utilizada na compressão de tipo Booleano é semelhante à utilizada na
compressão numérica. Basicamente, o objetivo é armazenar os valores utilizando a menor
quantidade possível de bits para isso. Porém, enquanto que na compressão numérica o byte foi
escolhido como unidade mínima de armazenamento, na compressão de valores do tipo
Booleano, essa unidade pode ser ainda mais reduzida.
Como um dado deste tipo só pode assumir os valores ‘0’ ou ‘1’ (FALSE ou TRUE – o
valor NULL não será aceito nesta proposta) seu tamanho pode ser limitado a 1 bit, o que torna
possível armazenar oito valores desse tipo em um único byte.
Como pode ser percebido, essa estratégia representa uma economia considerável de
espaço em relação aos sistemas tradicionais que utilizam necessariamente 1 byte para
armazenar cada valor do tipo Booleano. Em uma tabela formada apenas por valores desse
tipo, seu tamanho seria reduzido para 1/8 do tamanho original.
Além disso, como o tamanho é fixo (sempre 1 bit para cada valor), não haverá a
necessidade de cálculos complexos para determinar o posicionamento dos dados. Para isso,
são necessárias apenas operações simples sobre o índice do valor desejado. Por exemplo, se o
valor a ser acessado encontra-se no índice 75 o algoritmo não irá retornar o byte 75, mas sim
o bit 75. Para determinar de qual byte esse bit faz parte, basta dividirmos o valor 75 por 8 (o
número de bits por byte) o que resulta em 9,375. Com isso, identificamos que o bit 75 faz
parte do byte 10 (os nove primeiros bytes totalizam 72 bits).
Dessa forma, mesmo utilizando o alinhamento ao nível de bits, não haverá queda
proibitiva na performance do sistema. Assim, o algoritmo poderá trabalhar de forma eficiente
com valores booleanos ao nível de bits e não ao nível de bytes como acontece para os valores
inteiros.
4.5 Compressão de String
Em sistemas tradicionais, os dados do tipo cadeia de caracteres (string) são
representados com o tipo CHAR. Nesse caso, tais campos têm seu tamanho definido
47
antecipadamente, no momento da criação da coluna ou tabela. Valores do tipo CHAR possuem
tamanho fixo porque, quando criados, eles são preenchidos à direita com espaços vazios até o
tamanho especificado.
Nesse caso, o espaço alocado para um valor desse tipo não depende do valor a ser
inserido, mas sim do tamanho indicado no momento de sua criação. Tal estratégia representa
um claro desperdício de armazenamento, pois quando criamos um campo CHAR de tamanho,
por exemplo, 200, mesmo que o valor inserido seja um único caractere, o espaço ocupado será
sempre o mesmo: 200 bytes.
Uma abordagem simples, mas eficiente poderia ajustar o tamanho destinado a
armazenar o atributo de acordo com o valor a ser inserido. Em outras palavras, esta estratégia
define a especificação de strings com o tipo VARCHAR, onde os valores possuem tamanho
variado, não sendo preciso destinar sempre o mesmo tamanho para todos os dados.
Dessa forma, será utilizado apenas o número de bytes necessário para se armazenar
um determinado valor. No caso de ser inserida a palavra “banco de dados” em uma coluna
com tamanho declarado de 255 caracteres, apenas 14 bytes serão alocados, não havendo a
inclusão desnecessária de espaços vazios à direita da palavra, desperdiçando espaço de
memória. Podemos observar que essa técnica de compressão, embora simples, pode resultar
em uma economia de espaço considerável, principalmente quando for aplicada sobre colunas
com tamanho fixo muito grande.
Obviamente, a taxa de compressão poderia ser melhorada ainda mais caso fossem
utilizadas técnicas de compressão mais complexas como as que foram descritas no item 3.3.
No entanto, é importante lembrar que tais técnicas ou algoritmos de compressão demandariam
maior poder de processamento do sistema e essa necessidade poderia se tornar proibitiva,
inviabilizando sua utilização, principalmente em ambientes como os que são utilizados neste
trabalho, com limitação de recursos computacionais.
Finalmente, da mesma forma que ocorre para valores do tipo Inteiro ou Booleano, o
tamanho da string também precisa ser armazenado porque será utilizado no momento da
leitura do dado.
O próximo capítulo analisa de que forma esses dados armazenados no formato
comprimido podem ser recuperados sem que haja queda significativa de performance. O
48
acesso aos dados comprimidos constitui um fator altamente importante quando analisamos
qualquer proposta de compressão de dados. Mesmo que a estratégia de compressão alcance
taxas de compressão elevadas, caso a performance dos sistemas de banco de dados seja
afetada seriamente, essa estratégia tornar-se-á inútil e não poderá ser utilizada de forma
adequada neste ambiente.
49
5. Acesso a Dados Comprimidos
5.1 Introdução
O capítulo anterior apresentou as técnicas que compõem a estratégia de compressão
utilizada nesta proposta. Cada técnica foi discutida separadamente e suas características foram
analisadas.
Neste capítulo, veremos como se dará o acesso aos dados mantidos no formato
comprimido. Para cada tipo de técnica de compressão, será utilizada uma codificação
diferente para o tamanho dos dados.
As seções seguintes da estrutura deste trabalho analisam como recuperar as
informações com base nas características de cada técnica de compressão.
A seção 5.2 analisa o nível de granularidade da consulta exigido em ambiente de
banco de dados e de que forma a performance do sistema pode ser seriamente afetada caso tal
fator não seja levado em consideração.
As seções 5.3, 5.4 e 5.5 expõem como se dará o acesso aos dados para as três técnicas
de compressão utilizadas no trabalho. Para cada caso, será discutido de que forma a proposta
deverá trabalhar para recuperar, sem perda de performance, os dados no seu formato
comprimido.
Finalmente, a seção 5.6 traz uma visão geral de como ficará a organizações dos
registros dentro dos arquivos do sistema, explicando de que forma o acesso aos dados
comprimidos poderá ser realizado mesmo que haja grande heterogeneidade dos tipos
envolvidos em uma mesma tabela.
5.2 Granularidade e Performance
A estratégia de compressão de dados utilizada nesta proposta tem como granularidade
o nível de colunas (atributos) de uma tabela. Para não haver uma queda na performance do
banco de dados, cada coluna pode ser comprimida e descomprimida individualmente, sem a
necessidade de ler ou atualizar colunas da tabela que não estejam envolvidas na consulta. Para
50
se recuperar, por exemplo, os campos Matricula e Nome de todos os empregados cujo valor
do campo Salario seja superior a 10.000,00 o código em SQL seria:
SELECT Matricula, Nome FROM Empregado WHERE Salario > 10000
Neste caso, somente as colunas Matricula, Nome e Salario seriam acessadas. Se a
tabela Empregado possuísse ainda outras colunas como Departamento, Endereco ou
Telefone, por exemplo, nenhuma delas necessitaria ser acessada. Dessa forma, ocorre que
somente as colunas que serão utilizadas na consulta precisarão ser acessadas. Tal
característica representa uma importante vantagem desse tipo de compressão dos dados [19].
A forma de acesso aos dados comprimidos varia conforme o tipo do campo a ser
acessado. Isso ocorre porque cada tipo necessita de um número diferente de bytes para ser
armazenado e, de acordo com a estratégia utilizada, diferentes técnicas de compressão são
aplicadas para diferentes tipos de dados. Nas próximas seções, são descritas as técnicas
utilizadas para se recuperar os dados comprimidos.
5.3 Dados do Tipo Inteiro
Devido ao “alinhamento a byte”, um inteiro comprimido só pode ter 1, 2 ou 4 bytes.
Dessa forma, para se armazenar essa informação são necessários apenas dois bits tanto para
campos que aceitam valores NULL quanto para campos que não aceitam valores nulos, ou
seja, campos NOT NULL conforme mostrado na Tabela 1. Em campos NOT NULL o código
“00” não é utilizado já que esse código destina-se a valores nulos.
Para se obter uma maior compressão, os pares de “bits de controle” são armazenados
em grupos de quatro nos “bytes de controle”. A inserção dos pares de bits de controle ocorre a
partir da esquerda (bit de mais alta ordem). Os bytes de controle formarão os registros de
controle, conforme ilustrado na Figura 8. Dessa forma, cada byte de controle guarda a
informação referente a quatro campos de uma determinada coluna.
51
Tabela 1. Codificação do tamanho de inteiros
Tamanho (em bytes) Código (par de bits) 0 00 1 01 2 10 4 11
Os registros de controle serão utilizados para se calcular o offset de cada valor
armazenado no registro de dados. Os valores dos bytes de controle serão somados para se
calcular a posição de um determinado dado.
0 1 0 1 1 0 1 0 1 1 0 1 1 0 0 0
12
77
346
2845
37421
43
789
NULL
Byte 1
Byte 2
Registro de Controle Coluna n
Figura 8: Estrutura de um Registro de Controle para Coluna do Tipo Inteiro
Devido à necessidade desse cálculo, a recuperação de um valor do tipo inteiro
comprimido necessita de certa sobrecarga de processamento. No entanto, se esse aumento na
carga de processamento for mantido em níveis aceitáveis, o desempenho geral do sistema não
será afetada de forma crítica e o custo-benefício da utilização da compressão poderá ser ainda
assim positivo.
52
5.4 Dados do Tipo Booleano
Conforme discutido anteriormente, nesta proposta um único byte pode comportar oito
valores do tipo Booleano devido ao fato que cada valor pode ser armazenado em um único bit
(0 para FALSE e 1 para TRUE). Além disso, como o tamanho desses valores é fixo (sempre
um único bit), não há necessidade da utilização de um registro de controle para guardar essa
informação. Contudo, conforme será discutido posteriormente, esse registro de controle será
criado – sem qualquer tipo de dado – apenas para efeito de controle e organização do
esquema.
Assim, a compressão do tipo Booleano atinge uma alta taxa de compressão porque os
valores desse tipo passam a utilizar apenas 1/8 de byte, no lugar de um byte inteiro e, além
disso, não haverá necessidade do armazenamento de informações adicionais, como ocorre nos
tipos Inteiro e String.
Os valores booleanos também são inseridos no byte a partir do bit mais à esquerda (de
mais alta ordem). No momento da escrita ou leitura de um determinado valor, é necessária
apenas a informação de sua coluna e de sua tupla. Um valor armazenado na tupla n e coluna m
estará localizado no byte n / 8 do registro de controle 2m (devido a paridade de um registro
de controle para cada registro de dados, conforme será discutido posteriormente). Com base
nestes dados, podemos gravar ou recuperar o bit referente ao valor.
5.5 Dados do Tipo String
Nesta proposta, os valores do tipo String são armazenados de uma maneira similar aos
valores do tipo Inteiro. A parte referente ao seu valor é gravada com um tamanho variável e
vai ocupar apenas o espaço mínimo necessário, de acordo com o número de caracteres do
dado.
Além disso, também é necessário armazenar a informação referente ao tamanho do
dado a qual será utilizada no momento de se acessar esse dado. Esta informação será
armazenada separadamente em um outro registro (registro de controle). Porém, assim como
53
acontece para os valores inteiros, será utilizado o mínimo espaço possível para guardar esta
informação.
No caso de um valor do tipo String, seu tamanho poderá variar nesta arquitetura entre
0 e 255 caracteres. Conseqüentemente, essa informação poderá ser armazenada em um único
byte de controle, visto que um único byte é capaz de armazenar todos os 256 tipos possíveis
de tamanho que o valor do tipo String pode assumir.
Com isso, o registro de controle para valores do tipo String terá tantos elementos
quanto o registro de dados, na proporção de um byte de controle para cada dado, ou seja, para
cada tupla. Um valor NULL terá seu tamanho representado pelo valor 0 (zero). A Figura 9
mostra um exemplo dessa estrutura.
6 14 9 5 10 0 6
“Brasil” “Estados Unidos” “Argentina” “Japão” “Inglaterra” NULL “Brasil”
Registro de Controle Coluna A
Figura 9: Estrutura de uma Coluna do Tipo String e seu Registro de Controle
5.6 Estrutura dos Arquivos
Nesta seção, será descrita a estrutura de arquivos necessária para garantir a
implementação da abordagem proposta de armazenamento e acesso aos dados comprimidos.
Para cada coluna haverá um registro de controle correspondente. Para facilitar o
acesso a estas informações, os registros de controle serão armazenados no mesmo arquivo dos
registros de dados, havendo uma alternância entre os dois tipos de registro, criando assim uma
relação de paridade entre eles, conforme ilustrado na Figura 10. No entanto, somente para as
54
colunas dos tipos Inteiro e String as informações desses registros serão utilizadas. Para as
colunas dos outros tipos, o registro de controle será criado apenas para manter a paridade e
facilitar o acesso aos dados.
Coluna A
Coluna B Coluna C
Registros de Dados
Registros de Controle
Figura 10: Organização dos Registros de Controle e de Dados de uma Tabela
Essa organização simplifica bastante o acesso às informações de controle ou aos dados
propriamente ditos com base apenas no índice da coluna. Isso ocorre porque quando se deseja
acessar uma coluna de índice n, por exemplo, basta acessar o registro de índice 2n do arquivo.
O registro de controle será o registro de índice 2n-1. Se essa paridade entre registro de
controle e registro de dado não fosse mantida, para se acessar uma determinada coluna de
índice n, o cálculo do índice dos registros de dados e de controle não seria tão simples.
Adicionalmente, seria necessária alguma estrutura auxiliar que realizasse a indexação dos
registros.
A Figura 11 ilustra a organização dos registros de dados no arquivo (PDB) referente a
uma determinada tabela do banco de dados. Neste exemplo, existem três colunas nessa tabela.
No entanto, devido à questão da paridade de registros, serão criados seis registros (três
registros de dados e três de controle), ou seja, o dobro do número de colunas que a tabela
possui.
Podemos observar que, no primeiro registro (de controle), está armazenado o valor
binário 01010100 cujo valor decimal é 84. Esse número representa os tamanhos (em número
de bytes) de um grupo de quatro dados, no caso, pela ordem os valores 1, 2, 3 e nulo (nesse
55
caso, não existe um quarto valor). Como os três primeiros valores só precisam de 1 byte para
ser armazenados, a informação relativa ao tamanho a ser salva para cada um desses valores é
o par de bits 01. O valor nulo ou vazio não precisa de nenhum byte para ser armazenado, ou
seja, o par de bits é 00.
Portanto, ao armazenarmos o valor 84 estamos guardando a informação referente ao
tamanho dos três valores presentes na primeira coluna da tabela e para isso só necessitamos
de um único byte. O segundo registro (registros de dados) armazena os dados propriamente
ditos. Como, no exemplo, existem apenas três valores e cada um desses valores necessita de
apenas 1 byte para seu armazenamento, o tamanho total desse registro de dados será de 3
bytes.
Figura 11: Estrutura de um Arquivo PDB de uma Tabela com Três Colunas
O terceiro e o quinto registros são similares, pois guardam a informação referente ao
tamanho de colunas do mesmo tipo: String. Nesse caso, o tamanho a ser salvo pode ser
calculado a partir do número mínimo de bytes que cada valor precisa para ser armazenado.
Como os valores da segunda coluna – o quarto registro – são as palavras ‘Brasil’, ‘Inglaterra’
e ‘China’, os valores armazenados no registro de controle serão respectivamente os inteiros 6,
10 e 5.
56
Portanto, o tamanho do registro de controle para essa coluna será de 3 bytes (um para
cada valor) e o tamanho do registro de dados será 21 bytes, calculado pela soma dos tamanhos
dos valores (6, 10 e 5). Situação análoga ocorre nos registros cinco (de controle) e seis (de
dados).
É importante lembrar que, mesmo que essa tabela tivesse um tipo de dado sobre o qual
não é aplicada nenhuma técnica de compressão (no caso deste trabalho, os tipos float e data),
ainda assim seria realizada a criação de um registro de controle específico para essa coluna.
Esse registro, apesar de não ter qualquer valor armazenado, teria a função de manter a
paridade entre registros de dados e de controle e conseqüentemente uma melhor organização
do arquivo.
57
6. Resultados Experimentais
6.1 Introdução
Este capítulo apresenta os resultados dos testes realizados para se analisar o
desempenho da estratégia de compressão discutida neste trabalho. A seção 6.2 apresenta os
resultados desses testes, discutindo detalhadamente quais os principais aspectos observados
após a aplicação dessa estratégia sobre um banco de dados em um dispositivo com recursos
computacionais limitados.
6.2 Experimentos Realizados
A ferramenta Palm Database Manager (PDM) [17] foi desenvolvida com o objetivo de
avaliar e validar as estruturas de armazenamento propostas neste trabalho que incluem: (1) o
conceito diferenciado de gravar os mesmo tipos de dados (colunas) em um mesmo registro e
(2) a forma de compressão desses dados visando, assim, otimizar a utilização da memória e o
gerenciamento dos dados armazenados. Esta ferramenta fornece suporte para que, em
ambientes com restrições de recursos, como é o caso do Palm OS, os dados armazenados
sejam vistos e manipulados como dados de bancos de dados relacionais.
Para uma avaliação da estratégia de armazenamento e compressão anteriormente
apresentada, foram realizados alguns experimentos sobre bancos de dados comprimidos e
não-comprimidos [3]. Os resultados obtidos levaram em consideração os tempos de resposta e
as taxas de compressão obtidas sobre as tabelas. Foram utilizadas tabelas com tipos de dados
heterogêneos e de fontes distintas, possibilitando assim uma melhor avaliação dos resultados.
Os experimentos foram realizados no handheld Tungsten C da Palm com 64 MB de memória
e processador Intel PXA255 de 400 MHz. Em todos os testes foi utilizada a ferramenta PDM.
A Tabela 2 mostra os tamanhos das tabelas comprimidas e não comprimidas enquanto
que a Tabela 3 apresenta os tempos de resposta para a carga dos dados de cada uma das
tabelas.
58
Tabela 2: Tamanho (em bytes) de Tabelas Comprimidas e Não-Comprimidas
Tabela Não-
comprimida Comprimida Taxa de Compressão
ZonaEleitorais 49.000 23.162 52,73%
InfoMunicipio 60.000 24.962 58,40%
CursosCapes 84.360 42.835 49,22%
ConceitoPorCentro 45.000 28.783 36,04%
Total 238.360 119.742 49,76%
As melhores taxas de compressão foram obtidas nas tabelas ZonaEleitorais e
InfoMunicipio porque estas possuem muitos valores numéricos. A predominância de colunas do
tipo Inteiro resultou em uma alta taxa de compressão porque a grande maioria dos valores
precisou de apenas um ou dois bytes para seu armazenamento, reduzindo bastante o espaço
em relação à tabela original que necessitava de quatro bytes para cada valor dessas colunas.
No entanto, essas duas tabelas apresentaram os maiores aumentos de tempo em relação à
versão não-comprimida. O aumento na tabela InfoMunicipio foi de quase 30% e para a tabela
ZonaEleitorais foi de 46 %. O motivo foi o mesmo que elevou a taxa de compressão: muitas
colunas do tipo inteiro. Para este tipo de dado, a necessidade de se calcular o tamanho e o
offset de cada valor é bastante cara do ponto de vista computacional porque estas informações
não estão ao nível de byte, mas sim ao nível de “par de bits”.
Tabela 3: Tempo (em ms) de Tabelas Comprimidas e Não-Comprimidas
Tabela Não-comprimida Comprimida
ZonaEleitorais 5.070 7.440
InfoMunicipio 7.430 9.580
CursosCapes 3.990 4.730
ConceitoPorCentro 6.810 7.510
Total 23.300 29.260
A tabela CursosCapes apresentava muitas colunas do tipo CHAR o que diminuiu a taxa
de compressão (49,22%) porque a grande maioria dos valores destas colunas tinha tamanhos
muito próximos aos declarados na criação da tabela. No entanto, o tempo de resposta
59
aumentou apenas 18% porque para valores CHAR o tamanho está armazenado sempre em 1
byte e não há necessidade de se calcular o posicionamento desses valores.
A tabela ConceitoPorCentro apresentou a mais baixa taxa de compressão porque apesar
de existirem algumas colunas do tipo Booleano (cuja taxa de compressão é de quase 90%) a
maior parte do seu tamanho se deve a uma coluna do tipo CHAR com tamanhos muito
próximos ao máximo da coluna. Essa predominância de strings foi o motivo do menor
aumento de tempo obtido: 10 %.
A taxa de compressão total e os tempos de resposta obtidos são melhores do que em
outras estratégias semelhantes aplicadas sobre bancos de dados como em [22], em que as
taxas de compressão variaram entre 10% e 45 % (contra taxas de 36% a 52% desta proposta)
e os tempos de carga dos dados estiveram de 20% a 50% maiores nos bancos de dados
comprimidos (contra aumentos de 10% a 46 % da proposta deste artigo).
Os resultados mostraram também que quanto maior a quantidade de colunas do tipo
Inteiro, maior será a taxa de compressão e maior será o aumento nos tempos de resposta. Por
outro lado, se houver muitos valores do tipo CHAR na tabela, haverá uma menor taxa de
compressão e um menor aumento no tempo de resposta das tabelas.
O Gráfico 1 mostra a variação do tamanho de acordo com o aumento do número de
tuplas das tabelas tanto para a versão comprimida quanto para a versão original. É possível
perceber que a taxa de compressão se mantém constante em relação ao aumento do número de
tuplas.
O Gráfico 2 mostra o crescimento do tamanho da tabela ZonaEleitorais no formato
comprimido de acordo com o aumento do tamanho dessa mesma tabela no formato não-
comprimido. Pode-se perceber que à medida que a tabela não-comprimida aumenta de
tamanho, a taxa de crescimento do tamanho da tabela comprimida se mantém constante, o que
indica que as taxas de compressão obtidas serão, aproximadamente, as mesmas para tabelas
com grande quantidade de dados.
É importante ressaltar também que todos os testes aqui apresentados foram realizados
em um dispositivo de alto poder de processamento: o Tungsten C. Em experimentos
realizados em dispositivos menos potentes, os aumentos nos tempos de resposta foram
60
consideravelmente menores porque nestes dispositivos a maior parte do tempo de
processamento estará voltado para outras operações.
Tamanho da tabela em relação ao n° de tuplas
0
10000
20000
30000
40000
50000
60000
0 200 400 600 800 1000
Nº de Tuplas da Tabela
Tam
an
ho
da T
ab
ela
(Byte
s)
Comprimida Não-comprimida
Gráfico 1: Relação entre Quantidade de Tuplas e o Tamanho da Tabela
Outro teste realizado teve o objetivo de avaliar a taxa de compressão do banco de
dados no dispositivo móvel obtida pela estratégia proposta quando comparado a um banco de
dados de um sistema desktop. Para tanto, foi desenvolvida uma aplicação desktop em Java
que possibilitasse a migração de um banco de dados qualquer de algum SGDB desktop
disponível no mercado para um dispositivo rodando o framework PDM.
A aplicação foi desenvolvida de forma a possibilitar que qualquer banco de dados
criado no Microsoft SQL Server, no Oracle ou no DB2 pudesse ser migrado para o dispositivo
com a PDM. Além disso, ainda foi implementada a funcionalidade de se migrar esse banco de
dados de volta para os SGBD de origem ou ainda um banco de dados qualquer criado na
arquitetura PDM.
Com a utilização desse aplicativo foi possível compararmos o tamanho de um mesmo
banco de dados em dois ambientes completamente distintos. Os bancos de dados escolhidos
para o teste foram dois bancos do Microsoft SQL Server: o Northwind e o pubs. Esses bancos
61
foram selecionados por serem nativos do próprio SGBD e por serem bastante heterogêneos,
com uma grande diversificação de tipos de dados.
Variação entre o tamanho (em bytes) da tabela
comprimida e não-comprimida
0
5000
10000
15000
20000
25000
30000
0 10000 20000 30000 40000 50000 60000
Tamanho da Tabela Não-comprimida
Tam
an
ho
da T
ab
ela
Co
mp
rim
ida
Gráfico 2: Variação entre o Tamanho da Tabela ZonaEleitorais
Em seu ambiente de origem – o ambiente desktop – os bancos de dados Northwind e
pubs possuíam, respectivamente, 3.328 KB e 1.792 KB (os tamanhos dos arquivos MDF).
Após a sincronização desses bancos de dados todos os dados e restrições de integridades
presentes originalmente no ambiente desktop foram migrados para a arquitetura PDM no
dispositivo móvel e seus tamanhos foram sensivelmente reduzidos. A Tabela 4 apresenta um
quadro comparativo dos tamanhos dos arquivos de banco de dados Northwind e pubs no seu
formato original (não-comprimido) e na arquitetura PDM (comprimidos).
Essa elevada taxa de compressão foi obtida através da aplicação da estratégia de
compressão proposta e através da forma de armazenamento utilizada neste trabalho. É
importante ainda lembrar que esses bancos de dados na arquitetura PDM permanecem com
todos os seus componentes e as suas restrições de integridade presentes no SQL Server. O
62
único tipo de dados desses bancos no SQL Server que não foi migrado para a PDM foi o tipo
image. Os tamanhos dos arquivos MDF já foram considerados sem os atributos desse tipo.
Todo o restante de informações foi migrado para a PDM.
Tabela 4: Comparação entre bancos no SQL Server e na PDM
Banco de Dados SQL Server PDM Taxa de Compressão
Northwind 3.328 150 95,49 %
Pubs 1.792 21 98,83 %
Total 5120 171 96,66 %
Podemos observar que uma taxa de compressão desse porte pode ser utilizada de
forma muito positiva para, por exemplo, enviar um banco de dados de uma dispositivo para
outro via Bluetooth ou WiFi. Certamente, o tempo de transmissão seria reduzido.
63
7. Conclusão
7.1 Considerações Finais e Contribuições do Trabalho
Em paralelo à crescente popularização da utilização de dispositivos móveis, está
ocorrendo também um crescimento na demanda por novas tecnologias e aplicações para essa
área. Alguns dos principais fatores motivadores para pesquisa relativa a esse assunto são as
restrições de recursos inerentes a tais dispositivos como energia, espaço de memória e poder
de processamento.
A principal motivação deste trabalho foi apresentar uma estratégia de compressão de
dados a ser aplicada sobre um banco de dados relacional para ambientes de dispositivos
móveis com recursos computacionais limitados. Esta estratégia levou em consideração todas
as restrições inerentes a tais dispositivos. Essas restrições determinaram diretamente o tipo de
estratégia a ser aplicada de forma que o sistema pudesse alcançar melhores taxas de
compressão dos dados sem sofrer com sobrecargas de processamento
A estratégia de compressão apresentada neste trabalho foi composta por várias
técnicas de compressão já consolidadas em vez de se utilizar um único método. Foi aplicada
individualmente para cada tipo de dado a técnica de compressão que pudesse alcançar uma
melhor taxa de compressão sem resultar em queda na performance do sistema. Essas técnicas
de compressão foram escolhidas com base em diretrizes que demonstraram quais
características seriam aceitáveis ou proibitivas para a situação.
Para o estudo de caso, foi utilizada uma arquitetura desenvolvida para o Palm OS
chamada Palm Database Manager (PDM) [17]. Essa arquitetura apresenta várias
características importantes, sendo a principal delas o fato de ser orientada a colunas, ou seja,
os dados são agrupados em registros de acordo com os valores das colunas e não das tuplas.
Essa característica combinou perfeitamente com o tipo de estratégia de compressão adotada
onde diferentes técnicas de compressão são aplicadas para diferentes tipos de dados.
Uma primeira característica desejável para a estratégia de compressão proposta foi que
o método de compressão a ser utilizada fosse leve, ou seja, não gerasse um aumento
proibitivo na carga de processamento do sistema. Caso isso não fosse levado em
64
consideração, a performance do banco poderia ser seriamente afetada e a estratégia de
compressão não poderia ser utilizada.
Além disso, outra preocupação fundamental foi determinar quando e o que deve ser
descomprimido a cada acesso aos dados. Como a ação de descompressão gera um
processamento adicional, o ideal é que esses dados fossem mantidos no formato comprimido
o maior tempo possível e, quando realmente necessário, fossem descomprimidos apenas os
dados imprescindíveis à consulta.
Nos experimentos realizados, a aplicação dessa estratégia de compressão sobre uma
amostra de dados real apresentou um desempenho eficiente porque conseguiu alcançar seu
objetivo: diminuir o espaço de memória utilizada pelos dados sem gerar um aumento de
processamento inaceitável. Nos testes realizados, em todas as tabelas utilizadas as taxas de
compressão e os aumentos no tempo de carga dos dados se mantiveram melhores do que na
estratégia similar proposta para ambientes desktop [22].
Esses resultados demonstraram que a estratégia apresentada teve um desempenho
eficiente porque conseguiu o objetivo proposto: alcançou altas taxas de compressão sobre os
dados sem resultar em sobrecarga no processamento do sistema.
Essa estratégia foi aplicada na prática em diversos aplicativos para ambientes com
recursos computacionais limitados e sua utilização mostrou-se altamente útil por tornar esses
aplicativos menos onerosos à sua plataforma em termos de espaço de armazenamento. Isso se
mostra altamente importante devido as restrições de recursos computacionais inerentes a tais
dispositivos.
7.2 Trabalhos Futuros
Alguns trabalhos podem ser futuramente incrementados a este trabalho. Dentre eles
temos:
• Implementação de técnicas de compressão para os tipos float e date. A
estratégia de compressão utilizada foi aplicada sobre três dos cinco tipos de
dados básicos do sistema (inteiro, string, booleano). Para os tipos float e date
65
não foi encontrada uma técnica que alcançasse uma redução no espaço de
memória sem afetar a performance de forma proibitiva.
• Análise acerca da utilização da arquitetura híbrida utilizada pelo C-Store.
Apesar dos ganhos de performance obtidos pela estratégia orientada a colunas,
uma estratégia híbrida, composta tanto por estruturas orientadas a tuplas
quanto por estruturas orientadas a colunas, pode representar uma estratégia
interessante a ser implementada. No entanto, a utilização dessa estratégia deve
levar em consideração a limitação de memória inerente aos dispositivos
móveis, visto que a arquitetura híbrida cria múltiplas projeções das tabelas
resultando em uma maior demanda por espaço de memória.
• Investigação de melhorias nas técnicas de compressão utilizadas. Apesar das
técnicas de compressão utilizadas já alcançarem elevadas taxas de compressão,
outros aspectos, principalmente em relação ao tipo string, poderiam ser
aprofundados com o objetivo de se obter taxas de compressão mais altas.
66
Bibliografia
[1] Abadi, D.; Madden, S. R. e Ferreira, M. C. Integrating Compression and Execution in Column-Oriented Database Systems. ACM SIGMOD 2006, Chicago, USA.
[2] Bellaachia, A e Rassan, I. A.. Efficiency of Prefix and Non-Prefix codes in String Matching over Compressed Databases on Handheld Devices. 2005 Symposium on Applied Computing, p. 993-997, 2005.
[3] Brayner, A.; Brito, R. W. C e Pitombeira, D. K. D. Uma Arquitetura Eficiente para Armazenamento, Compressão e Acesso a Dados em Dispositivos Móveis com Recursos Computacionais Limitados. 20° Simpósio Brasileiro de Banco de Dados, p. 250-264, Uberlândia-MG, 2005
[4] Chen, Z., Gehrke, J e Korn, F. Query Optimization in Compressed Database Systems. ACM SIGMOD 2001, 2001.
[5] Chen, Z. e Seshadri, P. An Algebraic Compression Framework for Query Results. In Proc. Of ICDE, p. 177-188, 2000.
[6] Cleary, J. G. e Witten, I. H. Data Compression Using Adaptive Coding and Partial String Matching. In IEEE Transactions on Communications, Vol. 32, No. 4, April 1984.
[7] Cormack, G. Data Compression in a Database System. Communications of the ACM, 28(12): 1336, 1985.
[8] Goldstein, J., Ramakrishnan, R. e Shaft, U. Compressing Relations and Indexes. In Proc. of ICDE, p. 370–379, 1998.
[9] Graefe, G e Shapiro, L. D. Data Compression and Database Performance. In ACM/IEEE-CS Symp. On Applied Computing, pages 22-27, April 1991.
[10] Huffman, D. A Method for the Construction of Minimum-redundanc Codes. In Proc. IRE, 40(9), p. 1098–1101, 1952.
[11] Iyer, B. R. and Wilhite D. Data Compression Support in Databases. In Proc. Of VLDB, pages 695-704, 1994.
[12] Moffat, A.; Zobel, J. e Sharman, N. Text Compression for Dynamic Document Databases. IEEE Transactions on Knowledges and Data Engineering, vol 9, Nº 2, March 1994.
[13] Palm, Inc. Palm OS 68K SDK Documentation: Palm OS File Format Specification. 2001. Disponível em http://www.palmos.com/dev/support/ palmos/ docs/68k_books.html. Último acesso em 22/04/2005.
[14] Palm, Inc. Palm OS 68K SDK Documentation: Palm OS Programmer’s API Reference. 2003. Disponível em http://www.palmos.com/dev/support/ docs/palmos/68k_books.html. Último acesso em 22/04/2005.
[15] Palm, Inc. Palm OS 68K SDK Documentation - Palm OS Programmer’s Companion - Volume I. 2003. Disponível em
67
http://www.palmos.com/dev/support/ docs/palmos/68k_books.html. Último acesso em 22/04/2005.
[16] Palm, Inc. Palm OS Protein SDK Documentation - Exploring Palm OS: Memory, Databases, and Files. Janeiro 2004. Disponível em http://www.palmos.com/dev/ support/docs/protein_books.html. Último acesso em 22/04/2005.
[17] Pitombeira, D. K. D.; Brito, Ricardo W. C.; Brayner, Angelo et al. PDM: Palm Database Manager. 19° Simpósio Brasileiro de Banco de Dados – I Sessão de Demos, Brasília, 2004.
[18] Pitombeira, D. K. D. Uma Arquitetura Eficiente para Armazenamento, Gerenciamento e Acesso a Dados em Dispositivos Móveis com Recursos Computacionais Limitados. Tese de Mestrado, Fortaleza, 2006.
[19] Ray, G.; Haritsa, J. R e Seshadri, S. Database Compression: A Performance Enhancement Tool. Advances in Data Management 95. Proceedings of the 7th International COMAD, 1995, Pune, Índia.
[20] Roth, M. e Van Horn, S. Database Compression. ACM SIGMOD Record, 22(3) p. 31-39, 1993.
[21] Stonebraker, M. et al. C-Store: A Column-oriented DBMS. Proceedings of the 31st VLDB Conference, Trondheim, Noruega, 2005.
[22] Westmann, T., Kossmann, D., Helmer, S. e Moerkotte, G.. The Implementation and Performance of Compressed Databases, SIGMOD Record 29(3), 2000.
[23] Witten, I. H., Neal, R. e Cleary, J. Arithmetic Coding for Data Compression. Communications of the ACM, 30(6), p. 520–540, 1987.
[24] Ziv, J. e Lempel, A. A Universal Algorithm for Sequential Data Compression. In IEEE Transactions on Information Theory, Vol. 31, No. 3, p. 337-343, 1977.
Livros Grátis( http://www.livrosgratis.com.br )
Milhares de Livros para Download: Baixar livros de AdministraçãoBaixar livros de AgronomiaBaixar livros de ArquiteturaBaixar livros de ArtesBaixar livros de AstronomiaBaixar livros de Biologia GeralBaixar livros de Ciência da ComputaçãoBaixar livros de Ciência da InformaçãoBaixar livros de Ciência PolíticaBaixar livros de Ciências da SaúdeBaixar livros de ComunicaçãoBaixar livros do Conselho Nacional de Educação - CNEBaixar livros de Defesa civilBaixar livros de DireitoBaixar livros de Direitos humanosBaixar livros de EconomiaBaixar livros de Economia DomésticaBaixar livros de EducaçãoBaixar livros de Educação - TrânsitoBaixar livros de Educação FísicaBaixar livros de Engenharia AeroespacialBaixar livros de FarmáciaBaixar livros de FilosofiaBaixar livros de FísicaBaixar livros de GeociênciasBaixar livros de GeografiaBaixar livros de HistóriaBaixar livros de Línguas
Baixar livros de LiteraturaBaixar livros de Literatura de CordelBaixar livros de Literatura InfantilBaixar livros de MatemáticaBaixar livros de MedicinaBaixar livros de Medicina VeterináriaBaixar livros de Meio AmbienteBaixar livros de MeteorologiaBaixar Monografias e TCCBaixar livros MultidisciplinarBaixar livros de MúsicaBaixar livros de PsicologiaBaixar livros de QuímicaBaixar livros de Saúde ColetivaBaixar livros de Serviço SocialBaixar livros de SociologiaBaixar livros de TeologiaBaixar livros de TrabalhoBaixar livros de Turismo