UNIVERSIDADE DO SUL DE SANTA CATARINA

EDUARDO NIENKOTTER BOEING

RICARDO NIENKOTTER BOEING

ESTUDO DE TECNOLOGIAS PARA MELHORAR A PERFORMANCE NA BUSCA

DE DADOS

Palhoça
2018
 EDUARDO NIENKOTTER BOEING
RICARDO NIENKOTTER BOEING

ESTUDO DE TECNOLOGIAS PARA MELHORAR A PERFORMANCE NA BUSCA

DE DADOS

Trabalho de Conclusão de Curso apresentado ao Curso

de Graduação em Sistemas de Informação da
Universidade do Sul de Santa Catarina, como requisito
parcial à obtenção do título de Bacharel em Sistemas de
Informação.

Orientador: Prof. Aran Morales, Dr.

Palhoça
2018
 AGRADECIMENTOS

Ricardo Nienkotter Boeing agradece a:

Ao meu pai e minha mãe por todo apoio, tanto financeiramente nas horas difíceis
quanto no incentivo a conclusão do curso.
Ao meu irmão Eduardo que além deste trabalho realizou o curso todo junto
comigo, superamos todas as dificuldades juntos e assim fomos até o final com a realização
deste trabalho de conclusão.
Ao nosso orientador Prof. Aran Morales que nos conduziu nesse trabalho e nos
passou o conhecimento necessário para realizá-lo
A minha noiva Ana Paula por me apoiar sempre e me colocar para frente quando
eu pensava em desistir.
E a todos que direta ou indiretamente contribuíram tanto para minha formação
acadêmica quanto profissional.

Eduardo Nienkotter Boeing agradece a:

Aos meus pais, por todo apoio emocional, financeiro e pelo incentivo nas horas
mais dificeis do curso.
Ao meu irmão Ricardo, onde juntos conseguimos superar as dificuldades e
realizar este trabalho de conclusão.
Ao nosso orientador Prof. Aran Morales que nos guiou para o caminho certo,
dividindo seu conhecimento.
A todos os amigos e colegas que ajudaram diretamente ou indiretamente para a
conclusão deste curso
 RESUMO

Empresas que não possuem experiência na área de desenvolvimento ou que possuem

necessidade de alavancar recursos rapidamente acabam pulando uma importante parte do
projeto de software o planejamento, e com isso, nem sempre as melhores ferramentas serão
escolhidas para atender a necessidade do software, no caso deste estudo estamos falando do
banco de dados. No início do desenvolvimento do sistema não houve problemas de
performance nas consultas pois a quantidade de dados armazenada e a a quantidade de
acessos a tabela era pequena, porém com o passar do tempo esse cenário mudou e apareceram
os primeiros problemas de performance. Neste trabalho os autores aplicaram duas alternativas
para tentar solucionar o problema de consulta em uma tabela do banco de dados PostgreSQL.
A primeira foi o particionamento e a segunda foi aplicada uma extensão de base de dados
colunar na tabela em questão. Após realizar os benchmarks da solução atual e das duas
alternativas estudadas pelos autores, chegou-se a conclusão que o particionamento não trouxe
ganhos significativos para a performance de consulta, já a solução de base de dados colunar
conseguiu reduzir quase que pela metade o tempo de consulta das principais buscas realizadas
pelo sistema.

Palavras-chave: PostgreSQL. Performance. Particionamento. Base de dados colunares

 ABSTRACT

Companies that does not have expirience in development area or have the need of generate
resources quickly, skip an important part of the project, the planning, and with that,
sometimes the best tools are no chosen to fit the software needs. In this study scenario we
analyze the database. In the beginning of the development of the application there was no
problems with performance in queries because the quantity of data and accesses was small,
but, with time, this scenario changed and the first problems with performance appears. In this
study the authors applied two alternatives to solve the query problems in a table of database
postgreSQL. The first solution was the partition and the second was the application of a
extension for column oriented database. After Analise benchmarks of the current scenario and
the others solutions proposed by the authors, it was concluded that the partition had no
significant gains, but the column oriented database solution manage to reduce the query time
approximately by half for the main queries of the system.

Keywords, PostgreSQL. Performance. Partition. Column oriented database

 LISTA DE ILUSTRAÇÕES

Figura 1 – Relação de banco de dados…...…………………………………………………...18

Figura 2 – Modelo orientado à coluna...…….………………………………………………..20
Figura 3 – Limites PostgreSQL………………………………………………………………23
Figura 4 – Exemplo criação de um particionamento…………………………………………24
Figura 5 – Gráfico comparativo base colunar………………………………………………...25
Figura 6 – Gráfico comparativo sobre leitura de disco……………………………………….26
Figura 7 – Atividades metodológicas ………………………………………………………...28
Figura 8 – Fluxograma da aplicação...………………………………………………………..30
Gráfico 1 – Resultados busca por dia e por um veículo………………………………………36
Gráfico 2 – Resultados busca por dia e por todos veículos…………………………………..37
Gráfico 3 – Resultados busca por mês e por todos veículo…………………………………..38
Gráfico 4 – Resultados busca por mês e por um veículo……………………………………..38
Gráfico 5 – Resultados busca por semana e por um veículo…………………………………39
Gráfico 6 – Resultados busca por semana e por todos veículos……………………………...39
 SUMÁRIO

1 INTRODUÇÃO....................................................................................................................................9
1.1 PROBLEMÁTICA..........................................................................................................................10
1.2 OBJETIVOS.....................................................................................................................................10
1.2.1 Objetivos Gerais...........................................................................................................................11
1.2.2 Objetivos específicos....................................................................................................................11
1.3 JUSTIFICATIVA..............................................................................................................................11
1.4 ESTRUTURA DO TRABALHO......................................................................................................12
2 FUNDAMENTAÇÃO TEÓRICA....................................................................................................13
2.1 SGDB – SISTEMA DE GERENCIAMENTO DE BANCO DE DADOS.......................................13
2.1.1 Histórico........................................................................................................................................14
2.1.2 Propriedades ACID......................................................................................................................17
2.1.3 BD Relacionais: BD por linhas e por colunas............................................................................17
2.1.4 Particionamento...........................................................................................................................21
2.1.4.1 Particionamento horizontal.........................................................................................................21
2.1.4.2 Particionamento vertical.............................................................................................................21
2.2 POSTGRES......................................................................................................................................22
2.2.1 Particionamento no PostgreSQL................................................................................................23
2.2.2 PostgreSQL orientação a coluna.................................................................................................24
2.3 CONSIDERAÇÕES FINAIS...........................................................................................................26
3 MÉTODO...........................................................................................................................................27
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA...........................................................................27
3.2 ATIVIDADES METODOLÓGICAS................................................................................................28
3.3 DELIMITAÇÔES.............................................................................................................................29
4 RESULTADOS OBTIDOS................................................................................................................30
4.1 FLUXOGRAMA..............................................................................................................................30
4.2 REQUISITOS...................................................................................................................................32
4.2.1 Requisitos funcionais...................................................................................................................32
4.2.2 Requisitos não funcionais............................................................................................................32
4.3 CENÁRIO ATUAL...........................................................................................................................33
4.4 CENÁRIO PROPOSTO...................................................................................................................33
4.4.1 Particionamento...........................................................................................................................34
4.4.2 Extensão colunar..........................................................................................................................34
4.5 RESULTADOS OBTIDOS...............................................................................................................35
4.6 CONCLUSÕES DOS RESULTADOS.............................................................................................40
5 CONCLUSÕES E TRABALHOS FUTUROS................................................................................41
5.1 CONCLUSÕES................................................................................................................................41
5.2 TRABALHOS FUTUROS...............................................................................................................42
1 INTRODUÇÃO

As empresas geralmente possuem um baixo valor de capital para iniciar o projeto

de desenvolvimento de software e também possuem intensa necessidade de alavancar os
recursos necessários no menor tempo possível, para poder dar continuidade no processo de
desenvolvimento. Algumas vezes, o planejamento do desenvolvimento de software é feita às
pressas, ou deixado de lado. Porém um dos primeiros e mais importantes estágios do
planejamento do desenvolvimento é definir o projeto de arquitetura de software.
(SOMMERVILLE, 2011).
De acordo com Sommerville (2011, p. 102) “O projeto de arquitetura está
preocupado com a compreensão de como um sistema deve ser organizado e com a estrutura
geral desse sistema.”. O projeto de arquitetura é importante pois, com base no projeto e nos
requisitos, é capaz de identificar os principais componentes estruturais e seus
relacionamentos. O resultado deste processo é um modelo que descreve como o sistema está
organizado em um conjunto de componentes de comunicação.(SOMMERVILLE, 2011)
É na parte do planejamento do projeto de arquitetura, que se define a estrutura do
software e como os componentes do sistema serão organizados. Dentre estes componentes
podemos destacar qual banco de dados será utilizado e a arquitetura utilizada para realizar a
comunicação do banco de dados e a aplicação. O processo de escolha do sistema de
gerenciamento de banco de dados para a aplicação é de extrema importância, uma má escolha
pode desencadear sérios problemas de performance a medida que a aplicação evolua.
Amadeu (2015, p. 22) afirma que “É comum que estejam incluídos no modelo de
dados, conceitos para especificar o aspecto dinâmico ou o comportamento de uma aplicação
de banco de dados.”
A harmonia do conjunto de componentes, e como eles se comportam, escolhidos
durante o planejamento da arquitetura de software, implica diretamente na qualidade do
produto.

9
1.1 PROBLEMÁTICA

Principalmente empresas que não possuem experiência na área de

desenvolvimento e possuem uma ideia de produto de software com potencial de crescimento,
por não possuir o conhecimento necessário para realizar um bom planejamento, acabam
pulando essa importante parte do projeto de software. Assim, uma vez iniciado o processo de
desenvolvimento, podem continuar sem realizar as etapas de análise de projeto, uma das
etapas seria a análise do SGDB que será utilizado na aplicação desenvolvida. É comum que a
escolha deste componente seja realizada de forma precipitada e sem um estudo aprofundado
de como esse banco de dados irá se comportar no futuro, para que a estrutura da aplicação
consiga lidar com o constante aumento de usuários. Com o aumento da quantidade de acessos,
surgem os primeiros problemas de performance.
O problema de performance começa a aumentar proporcionalmente à quantidade
de usuários e acessos ao sistema. Pois, devido a falta de planejamento na escolha do SGDB,
não foi levado em consideração como este software se comportaria com uma grande
quantidade de usuários.
Dessa forma, a quantidade de dados armazenada nas tabelas do banco de dados
começam a crescer na mesma proporção. E assim surgem as primeiras tabelas com milhões de
registros no banco de dados. Além de possuir uma quantidade grande de registros, são tabelas
que possuem grande quantidade de acessos simultâneos, tanto de escrita como leitura.
O trabalho parte do seguinte problema de pesquisa: como melhorar a performance
na consulta e escrita de uma tabela, com milhões de registros e múltiplos acessos simultâneos,
de um software que possui uma arquitetura consolidada.

1.2 OBJETIVOS

Este trabalho realiza uma pesquisa na área de banco de dados a fim de juntar
conhecimento necessário para solucionar o problema de pesquisa.

10
1.2.1 Objetivos Gerais

O objetivo geral da pesquisa é encontrar uma solução de baixo custo, tanto

financeiro como de implementação, e eficaz para os problemas de leitura e escrita por uma
tabela com milhões de registros e uma quantidade enorme de acessos simultâneos.

1.2.2 Objetivos específicos

• Pesquisar soluções que possam ser utilizadas na resolução do problema.

• Apresentar pontos positivos e negativos de cada solução encontrada.
• Avaliar nível de impacto na estrutura das aplicações para cada solução encontrada.
• Eliminar soluções com grande impacto na estrutura das aplicações.
• Testar as soluções selecionadas, e formular um relatório dos resultados.
• Indicar uma solução que resolva o problema de performance e possua um baixo de
ponto de vista financeiro e de implementação.

1.3 JUSTIFICATIVA

Dentro do cenário descrito, é estudado um sistema o qual já possui uma

arquitetura implementada, possui tabelas complexas com milhões de registros, uma
quantidade enorme de acessos simultâneos e um número muito alto de serviços que utilizam
esta tabela, tornando as consultas e escritas destas tabelas lentas e sobrecarregadas.
Notou-se, através de um estudo realizado pela equipe de desenvolvimento que um
dos autores participa, que existem diversos modos para se melhorar uma estrutura que se
enquadra neste cenário, porém não foi possível identificar qual seria a mais adequada para ser
aplicada em um sistema que já está implementado e em produção, com um banco relacional
que possui uma tabela com milhões de registros, com milhares de acessos simultâneos

11
realizados por usuários e micro serviços deste sistema. Com isso surgiu a necessidade de ser
realizada uma pesquisa para avaliar, dentre as soluções encontradas, qual seria a ideal para ser
aplicada no cenário contextualizado.

1.4 ESTRUTURA DO TRABALHO

O capítulo 1 traz aspectos introdutórios, para compreender a problemática e os

objetivos, seguindo para uma solução que será detalhada nos capítulos posteriores. O capítulo
2 apresenta os conceitos, técnicas utilizadas no desenvolvimento do trabalho. O capítulo 3
apresenta o método de desenvolvimento do trabalho. O capítulo 4 apresenta os resultados
obtidos. No capítulo 5 é apresentada a conclusão do trabalho baseando-se nos resultados
conquistados ao longo da pesquisa.

12
2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo é apresentado conceitualmente os sistemas gerenciadores de banco

de dados, um histórico com as suas evoluções e alterações com o passar do tempo, uma
introdução as propriedades ACID. É apresentado os bancos de dados relacionais por linha e
por coluna, particionamento na horizontal e na vertical.
Em seguida uma introdução ao banco de dados PostgreSQL, e como se aplica o
particionamento nesse banco de dados, e como se pode trabalhar o PostgreSQL como um
banco de dados colunar.

2.1 SGDB – SISTEMA DE GERENCIAMENTO DE BANCO DE DADOS

Antes mesmo do surgimento dos computadores havia a necessidade de armazenar

as informações, e para isso utilizava-se de blocos de anotações, agendas, livros de registros,
dentre outros métodos, para que as informações pudessem ser registradas e ficassem ao
alcance para quando fosse necessário manipulá-las.
Segundo com Date (2004) “Um sistema de banco de dados é basicamente apenas
um sistema de manutenção de registros, que pode ser considerado como o equivalente de um
armário de arquivamento; ou seja, ele é um repositório de arquivos computadorizados”.
Da mesma forma que se pode realizar atividades como consultar um registro que
foi escrito em uma agenda, alterar esse registro ou complementá-lo com alguma informação
adicional, ou simplesmente riscar o registro na agenda, os SGDBs também oferecem
operações para que os usuários possam manipular as informações nele armazenadas. De
acordo com Date (2004) os usuários de um sistema podem realizar (ou melhor, solicitar que o
sistema realize) diversas operações envolvendo tais arquivos - por exemplo:

• Acrescentar novos arquivos ao banco de dados

• Inserir dados em arquivos existentes
• Buscar dados de arquivos existente
• Excluir dados de arquivos existentes

13
 • Alterar dados em arquivos existentes
• Remover arquivos existentes do banco de dados

O mesmo autor ainda conclui o raciocínio dizendo:

“Em outras palavras, é um sistema computadorizado cuja finalidade geral é

armazenar informações e permitir que os usuários busquem e atualizem essas
informações quando as solicitar. As informações em questão podem ser qualquer
coisa que tenha algum significado ao indivíduo ou à organização a que o sistema
deve servir - ou seja, qualquer coisa que seja necessária para auxiliar no processo
geral das atividades desse indivíduo ou dessa organização.” (DATE, 2004)

Sendo assim os SGDBs fornecem essas operações para facilitar a manipulação dos
dados que são armazenados. Com o constante crescimento na área tecnológica não é difícil
perceber o armazenamento de dados sendo realizado em computadores e sendo deixado de
lado antigos métodos de armazenamento de informação. Segundo Ramakrishnan e Gehrke
(2008) “Desde os primeiros computadores, armazenar e manipular dados tem sido o principal
foco dos aplicativos”. Os mesmos autores ainda afirmam que “Um sistema de gerenciamento
de banco de dados, ou SGDB, é um software projetado para auxiliar a manutenção e
utilização de vastos conjuntos de dados.”

2.1.1 Histórico

Antes do surgimento dos primeiros SGBD os dados dos sistemas eram

armazenados por sistemas de processamento de arquivos, nos quais eram necessários vários
programas para extrair e armazenar informações em arquivos. Manipular informações dessa
maneira traz inúmeras desvantagens. (SILBERSCHATZ; KORTH; SUDARSHAN, 2008,
p.2).

Segundo o autor as desvantagens são:

• Inconsistência e redundância de dados: como os sistemas e arquivos são mantidos por

diversas pessoas durante longos períodos, é comum que os sistemas e arquivos

14
 possuam formatos e linguagens diferentes. (SILBERSCHATZ; KORTH;
SUDARSHAN, 2008, p.2).

• Dificuldade de acesso aos dados: caso seja necessário acessar algum dado específico
ou até mesmo realizar algum filtro sobre os dados armazenados em arquivos, será
necessário a criação de um programa para realizar o filtro ou a busca necessitada. Não
existe uma maneira mais eficiente de se realizar tais pesquisas. (SILBERSCHATZ;
KORTH; SUDARSHAN, 2008, p.3).

• Isolamento de dados: segundo (SILBERSCHATZ; KORTH; SUDARSHAN, 2008,

p.3) “Como os dados estão dispersos em vários arquivos, e estes arquivos podem
apresentar diferentes formatos, é difícil escrever novas aplicações para recuperação
apropriada dos dados”.

• Problemas de integridade: caso seja necessário uma mudança de restrição é muito

difícil de ser aplicada em todos os programas responsáveis pelos dados, e ele pode
crescer ainda mais caso essa mesma restrição seja aplicada a diversos itens de dados
em diferentes arquivos. (SILBERSCHATZ; KORTH; SUDARSHAN, 2008, p.3).

• Problemas de atomicidade: caso ocorra algum problema durante a execução de alguma

tarefa, como, por exemplo, migração de dados de um arquivo para outro, esse modelo
apresenta dificuldade em garantir a integridade da operação. (SILBERSCHATZ;
KORTH; SUDARSHAN, 2008, p.3).

• Anomalias no acesso concorrente: caso ocorram atualizações de dados

simultaneamente, esse modelo não pode garantir a consistência dos dados, dessa
maneira em alguns casos, são feitas algumas validações para não ocorrer acessos não
previstos. (SILBERSCHATZ; KORTH; SUDARSHAN, 2008, p.3).

• Problemas de segurança: quando se trabalha nesse ambiente, não é possível garantir a

efetividade das regras de segurança sobre os acessos de usuários não autorizados a
dados restritos. (SILBERSCHATZ; KORTH; SUDARSHAN, 2008, p.3).

15
 O autor finaliza dizendo que: “Estas dificuldades, entre outras, provocam o
desenvolvimento dos SGBDs”.

Quando se escuta a palavra “histórico” vem à cabeça algo antigo. Porém, quando
diz respeito a de banco de dados é algo bem recente. O primeiro sistema de gerenciamento de
banco de dados de propósito geral foi projetado por Charles Bachman no início da década de
1960, e foi nomeado “depósito de dados integrados”. Ele constituiu a base do modelo de
dados de rede, que influenciou muito os sistemas de banco de dados na década de 1960.
(Ramakrishnan e Gehrke, 2008).
O mesmo autor ainda fala que no final da década de 1960, a IBM desenvolveu o
SGBD Sistema de gerenciamento de Informação (IMS --- Information Management System),
ainda usado atualmente em diversas instalações. O IMS constituiu a base da estrutura de
representação alternativa de dados, chamada modelo de dados hierárquico.
Foi na década seguinte que nasceu o banco de dados que é utilizado na maioria
das aplicações hoje, como continua descrevendo o autor a respeito. Em 1970, Edgar Codd
propôs uma nova estrutura de representação denominada modelo de dados relacional, que foi
muito importante no desenvolvimento de vários sistemas de banco de dados que tomaram
como base o modelo relacional. Porém, foi na década de 1980, que o modelo relacional
consolidou sua posição como o paradigma dominante de SGBD, e o uso dos sistemas de
banco de dados continuou a se difundir cada vez mais, como afirma o mesmo autor.
O autor continua o histórico cronológico dizendo que, no final da década de 1980
e no início da década de 1990 houve muitos avanços nos sistemas de banco de dados.
Investiu-se em diversas pesquisas em busca de linguagens de consulta mais poderosas.
Diversos fabricantes atribuíram a seus sistemas a capacidade de armazenar imagens texto e
consultas mais complexas. Um dos períodos mais importantes foi o início do uso dos SGBD
nos sistemas web, onde houve uma transição de sistemas que armazenam seus dados em
arquivos dos sistemas operacionais, para o uso dos SGBD para armazenar dados acessados
através de um navegador. Foi quando todos os fabricantes investiram em seus bancos de
dados para torná-los mais adequados para o desenvolvimento web.
Ramakrishnan e Gehrke (2008) afirmam que “O gerenciamento de banco de dados
continua a ganhar importância conforme mais e mais dados tornam-se disponíveis on-line e
ainda mais acessíveis através da rede”.

16
2.1.2 Propriedades ACID

Um SGBD deve garantir quatro propriedades importantes de transações para

manter os dados de acesso corretos e sem erros de sistema (RAMAKRISHNAN; GEHRKE,
2008, p.435), sendo elas:

1. Os usuários devem ser capazes de enxergar cada execução como atómica, ou seja,
todas as transações são executadas ou nenhuma delas é executada. Os usuários não
devem se preocupar com transações incompletas (RAMAKRISHNAN; GEHRKE,
2008, p.435).

2. Cada transação, deve preservar a consistência de banco de dados. O SGBD presume

que a consistência é prevista por transação. Garantir essa propriedade de uma
transação é responsabilidade do usuário (RAMAKRISHNAN; GEHRKE, 2008,
p.435)

3. Os usuários devem ser capazes de realizar uma transação sem se preocupar com o
efeito de outras transações em execução, mesmo que o SGBD intercale as ações de
várias transações por motivos de desempenho. Essa propriedade é conhecida como
isolamento (RAMAKRISHNAN; GEHRKE, 2008, p.435).

4. Segundo Ramakrishnan e Gehrke (2008, p.436) “Uma vez que o SGBD informe ao
usuário que uma transação foi concluída com êxito, seus efeitos devem persistir,
mesmo que o sistema falhe antes que todas as suas alterações sejam refletidas no
disco”. Esta propriedade é conhecida como durabilidade.

2.1.3 BD Relacionais: BD por linhas e por colunas

O modelo relacional surgiu em 1970, e atualmente é o modelo de dados mais

utilizado no mercado e também o modelo mais utilizado pelos SDGBs mais influentes, como

17
SQLServer e Oracle. Segundo Ramakrishnan e Gehrke (2008, p.49) “Os sistemas de banco de
dados relacional são onipresentes no mercado e representam um negócio de bilhões de
dólares”.
Como o seu próprio nome diz, a base do modelo de dados relacional é a relação:
os dados são organizados com uma tabela simples de linhas e colunas, de forma que a leitura
nos dados dessa tabela seja tão simples que até uma pessoa leiga no assunto consiga
compreender os dados ali contidos. Segundo (RAMAKRISHNAN; GEHRKE, 2008, p.49)
“As principais vantagens do modelo relacional em relação aos modelos de dados mais antigos
são sua representação de dados simples e a facilidade com que mesmo consultas complexas
podem ser expressas.
No modelo relacional, podemos comparar a relação com uma tabela de valores, na
qual a tupla da relação será a linha de dados da tabela e o atributo é o cabeçalho da coluna.
Amadeu (2015, p. 62)
Na figura 1 pode-se observar uma relação no banco de dados:

Figura 1: Relação de banco de dados

Um banco de dados tão bom quanto a confiabilidade da informação que nele é

armazenada e, portanto, um SGDB deve ajudar que dados incorretos não sejam armazenados
na base de dados. (RAMAKRISHNAN; GEHRKE, 2008, p.53)
Para isso, o banco de dados relacional conta com algumas restrições de
integridade. O mesmo autor afirma que: “Uma restrição de integridade (RI) é uma condição
especificada sobre um esquema de banco de dados e limita os dados que podem ser
armazenados em uma instância do banco de dados.
Amadeu (2015) divide as restrições em três categorias principais:

• Restrições inerentes baseadas no modelo ou restrições implícitas.

18
 • Restrições baseadas em esquema ou restrições explícitas, que podem ser expressas
diretamente nos esquemas do modelo de dados.

• Restrições baseadas na aplicação, ou restrições semânticas, ou regras de negócio, que

não podem ser expressas diretamente nos esquemas do modelo de dados e, portanto,
devem ser expressas e impostas pelos programas de aplicação.

Portanto as restrições baseadas em esquema são as que podem ser aplicadas

diretamente no modelo de dados, Amadeu (2015) ainda divide essas restrições em
subconjuntos:

• Restrições de domínio – Essa restrição garante que a informação contida em cada

atributo da tupla seja do domínio a que ele representa. Por exemplo, se um atributo da
tupla é do domínio string, então o dado armazenado deve ser obrigatoriamente do
mesmo tipo.

• Restrições de chave – As restrições de chave garantem que duas tuplas distintas em

qualquer estado da relação não podem ter valores idênticos para todos os atributos na
chave. Isso garante a integridade da tabela e evita que dados possam ser duplicados.
Por exemplo, a relação de pessoal, a chave pode ser o seu CPF, e isso garante que
nenhuma outra tupla terá o mesmo CPF.

• Restrições sobre valores NULL – Garante que o atributo da tupla possua um valor
válido diferente de NULL

• Restrições de integridade de entidade – Garante que nenhuma parte da chave primária

da entidade seja NULL.

• Restrições de integridade referencial – Garante que não se faça referência a algum

objeto que não exista na base de dados, por exemplo, um cadastro de boleto bancário
fazer referência à pessoa com um CPF não cadastrado na base de dados.

19
 Com essas restrições no modelo de dados relacional, algumas regras de
integridade são aplicadas para que a confiabilidade dos dados armazenados possa ser
validada, a fim de garantir a qualidade do banco de dados.
Um SGBD orientado à coluna se difere no fato de suas consultas de pesquisa
serem superiores ao modelo orientado à linhas.

Os SGBD com orientação a coluna apoiaram a construção do seu núcleo sobre a

constatação cujo Data Warehouse/Data Mart apresenta uma freqüência de leitura
muito superior a de operações de modificação – insert, update e delete. Tal fato
determina seu desempenho ótimo para leituras seletivas – pequeno conjunto de
colunas – sobre extenso volume de dados. (JOSKO 2014)

JOSKO (2014) também conclui que esse modelo faz com que o tempo de resposta
de operações de cálculo e/ou agregações massivos seja inferior àquele da abordagem por
linhas.
A figura 2 mostra a diferença na estrutura de um banco de dados relacional por
linhas e um banco de dados relacional por colunas.

Figura 2: Modelo orientado à coluna

2.1.4 Particionamento

O particionamento de banco de dados tem como foco o ganho em desempenho e

simplicidade de manutenção. Ao se fragmentar uma tabela muito grande em outras menores
as consultas se tornam mais rápidas, pois a quantidade de dados que são escaneados se tornam
20
muito menores. E as tarefas de manutenção e backups se tornam mais rápidas pela quantidade
de dados (MICROSOFT, 2016).

Particionamento não condiz apenas em divisão de tabelas, ele também pode ser
alcançado através de alocação de tabelas fisicamente em unidades individuais de disco.
Dividir tabelas relacionadas em unidades físicas distintas pode melhorar as consultas, pois
quando é necessário o uso de junções diversos cabeçotes de disco lerão os dados ao mesmo
tempo (MICROSOFT, 2016).

2.1.4.1 Particionamento horizontal

O particionamento horizontal corresponde à divisão de registros de uma tabela em

várias outras tabelas com as mesmas colunas. Por exemplo, se uma tabela armazena 1 bilhão
de registros, eles podem ser divididos em 12 tabelas, cada uma representando um mês de
dados de um ano específico (MICROSOFT, 2016).

2.1.4.2 Particionamento vertical

O particionamento vertical corresponde à divisão de uma tabela em várias outras

tabelas; porém, ao contrário do particionamento horizontal, são geradas tabelas com menos
colunas (MICROSOFT, 2016).

Existem dois tipos de particionamento vertical:

1. Normalização: é o processo utilizado para remover colunas redundantes de uma tabela

e realocadas em tabelas secundárias, vinculando-as através de chaves estrangeiras.

21
 2. Particionamento de linhas: o particionamento por linhas divide a tabela original
verticalmente em tabelas com menos colunas. Como afirmado por (MICROSOFT,
2016) “Cada linha lógica em uma tabela dividida coincide com a mesma linha lógica
das outras tabelas conforme é identificado por uma coluna UNIQUE KEY idêntica,
em todas as tabelas particionadas” .

O mesmo autor finaliza dizendo que “O particionamento vertical deve ser

considerado com cautela, porque a análise de dados de várias partições requer consultas que
unem as tabelas”.

2.2 POSTGRES

PostgreSQL é um sistema de banco de dados open source e objeto-relacional. Ele

tem mais de 15 anos de desenvolvimento e uma arquitetura comprovada que ganhou uma
forte reputação de confiabilidade, integridade de dados e correção. (POSTGRES, 2016).
A Comunidade Brasileira de PostgreSQL (2016) afirma que ele é totalmente
compatível com ACID, tem suporte completo a chaves estrangeiras, junções (JOINs), visões,
gatilhos e procedimentos armazenados (em múltiplas linguagens). Suporta também o
armazenamento de objetos binários, incluindo figuras, sons ou vídeos, e possui uma vasta
documentação.
A mesma comunidade ainda cita algumas funcionalidades mais sofisticadas a
nível corporativo, como o controle de concorrência multiversionado, recuperação em um
ponto no tempo, tablespaces, replicação assíncrona, transações agrupadas, cópias de
segurança a quente, um sofisticado planejador de consultas (otimizador) e registrador de
transações sequencial (WAL) para tolerância a falhas. Suporta conjuntos de caracteres
internacionais, codificação de caracteres multibyte, Unicode e sua ordenação por localização,
sensibilidade à caixa (maiúsculas e minúsculas) e formatação. É altamente escalável, tanto na
quantidade enorme de dados que pode gerenciar, quanto no número de usuários concorrentes
que pode acomodar.
A Comunidade Brasileira de PostgreSQL (2016) ainda comenta a respeito dos
limites desse banco de dados, apresentados na forma de uma tabela na figura 3:

22
 Figura 3: Limites PostgreSQL

E também afirma que existem sistemas ativos utilizando PostgreSQL em

ambientes de produção que gerenciam mais de 4TB de dados.

2.2.1 Particionamento no PostgreSQL

É possível realizar o particionamento horizontal através de meios nativos do

postgres. Segundo Postgres (2016) para configurar um particionamento é necessário seguir
alguns passos:

• Criar uma tabela “pai”, a partir do qual todas as partições herdaram o seu
comportamento. Esta tabela não deve conter nenhum dado e nenhuma restrição,
apenas se for pretendido que todas as tabelas que a herdaram também tenham essas
restrições.

• Criar várias tabelas “filhas” nas quais cada uma herdará a tabela “pai”. Normalmente
esses quadros não irão adicionar as colunas ao conjunto herdado.

• Adicionar restrições para as tabelas de partição para definir os valores de chave

permitidos em cada partição.

• Para cada partição, criar um índice na coluna de chave(s), bem como quaisquer outros
índices que o usuário quiser.

23
 • Opcionalmente, definir um disparador ou regra para redirecionar os dados inseridos na
tabela pai para a partição apropriada.

• Certificar-se de que o parâmetro de configuração constraint_exclusion não está

desativada no postgresql.conf. Se for, consultas não será optimizada como desejado.

Figura 4: Exemplo criação de um particionamento

A figura 4 exemplifica os processos da criação de um particionamento. Na

próxima sessão será abordada a orientação a coluna no bando de dados PostgreSQL.

2.2.2 PostgreSQL orientação a coluna

O PostgreSQL não possui orientação à coluna nativa. Para implementar esse

conceito existem algumas extensões fornecidas pela comunidade que implementam a base
orientado a coluna no PostgreSQL, como a solução oferecida pela Citusdata, uma solução
open source de base de dados orientado à coluna para PostgreSQL.
De acordo com Citusdata (2016) essa extensão de armazenamento colunar usa o
formato Optimized Row Columnar (ORC) para o seu layout de dados. ORC melhora o
formato RCFile desenvolvido no Facebook, e traz os seguintes benefícios:

• Compressão: reduz em memória e em disco tamanho de dados por 2-4x. Pode ser
estendido para oferecer suporte a diferentes codecs.

• Projeções de coluna: somente lê os dados da coluna relevante para a consulta. Melhora

o desempenho das consultas

24
 • Suporta mais de 40 tipos de dados do Postgres. O usuário também pode criar novos
tipos e usá-los.

A Cistusdata compara a diferença de performance de uma query utilizando o

PostgreSQL e a base de dados colunar, utilizando uma fonte de dados de uma pesquisa de
usuários da Amazon do ano de 1998 como exemplo.
Ela mostra que a diferença na velocidade da consulta entre o banco de dados
convencional (PostgreSQL) para o de base de dados colunar (cstore) é aproximadamente duas
vezes mais rápida, ele ainda faz uma comparação com a base colunar com um algoritmo de
compressão nativo do PostgreSQL (cstore(PGLZ)) como mostra a figura 5.

Figura 5: Gráfico comparativo base colunar

A figura 6 mostra um comparativo a respeito da leitura de disco comparando as

mesmas tecnologias anteriores. Pode-se observar que houve uma redução de
aproximadamente 10x na leitura do disco na consulta que utilizava a base de dados colunar,
utilizando uma quantidade de dados de 4GB.

25
 Figura 6: Gráfico comparativo sobre leitura de disco

Com a análise e pesquisa realizada, no próximo capítulo serão feitas as

considerações referentes as informações coletadas.

2.3 CONSIDERAÇÕES FINAIS

Com a pesquisa realizada, foram encontradas duas possíveis soluções para a

problemática do trabalho, que visa melhorar o desempenho das consultas em uma tabela que
possui milhões de registros e acessos simultâneos.
A primeira alternativa é utilizar o particionamento nativo do PostgreSQL, e a
segunda alternativa é utilizar uma solução open source para transformar a tabela em questão
em uma tabela de base de dados colunar.

26
3 MÉTODO

Neste item é apresentado o tipo de pesquisa que é realizada neste trabalho,

apresentando as etapas metodológicas necessárias para atingir os objetivos. São apresentados
também a proposta de solução, as delimitações e o cronograma que é apresentado no
apêndice.

3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA

Com base no que foi proposto anteriormente pode-se classificar esta pesquisa
como aplicada, pois ela busca apresentar uma solução imediata a um problema real, com base
nas delimitações apresentadas. Barros e Lehfeld (2008, p.93) afirmam que a pesquisa
“aplicada” é aquela em que o pesquisador é movido pela necessidade de conhecer para a
aplicação imediata dos resultados. Contribui para fins práticos, visando à solução mais ou
menos imediata do problema encontrado na realidade.

Como a pesquisa que é realizada tem como base dados brutos de natureza real e
que a solução se da sobre uma análise de desempenho sobre estes mesmos dados e também
existência da necessidade de implantação desta solução, pode-se classificar a pesquisa como
quantitativa. Fonseca (2002, p.20) esclarece que a pesquisa quantitativa se centra na
objetividade. Influenciada pelo positivismo, considera que a realidade só pode ser
compreendida com base na análise de dados brutos, recolhidos com auxílio de instrumentos
padronizados e neutros.

Levando em consideração que o foco desta pesquisa é buscar e apresentar a

solução que, dentro dos critérios, seja a melhor para o caso analisado, pode-se classificar a
pesquisa como explicativa. Este tipo de pesquisa preocupa-se em identificar os fatores que
determinam ou que contribuem para a ocorrência dos fenômenos (GIL, 2007), ou seja, este
tipo de pesquisa busca esclarecer e apresentar os resultados obtidos.

27
 Também pode-se classificar a pesquisa como experimental, pois através de dados
selecionados, serão observados e analisados valores estatísticos sobre o desempenho de
diferentes metodologias aplicadas sobre um banco de dados, e com base nestes valores
obtidos será descoberto a que se aplica na necessidade apresentada. Fonseca (2002, p.38)
afirma que a pesquisa experimental seleciona grupos de assuntos coincidentes, submete-os a
tratamentos diferentes, verificando as variáveis estranhas e checando se as diferenças
observadas nas respostas são estatisticamente significantes. Este trabalho também pode ser
classificado como uma pesquisa bibliográfica, pois o embasamento para este trabalho é feito
com base em livros, artigos e documentações.

3.2 ATIVIDADES METODOLÓGICAS

As atividades metodológicas deste trabalho iniciam pelo referencial teórico e

finalizam com os resultados obtidos neste trabalho.

Figura 7: Atividades metodológicas

As atividades estão organizadas do seguinte modo:

• Realizada a pesquisa sobre como devem ser realizados os próximos passos.

• Coletados os dados nos quais serão feitos os testes.
• Preparação das bases de dados que serão armazenados os dados coletados.
• Configuração das bases de dados para serem realizados os testes.
• Realizados testes sobre os diferentes ambientes.
28
 • Análise dos resultados gerados pelos testes.
• Definição da melhor solução com base na problemática.
• Conclusão.

3.3 DELIMITAÇÕES

• Será levado em consideração apenas o sistema operacional Linux.

• Só será utilizado o banco de dados PostgreSQL.

29
 Os dados são transmitidos dos módulos através de sinal GPRS, item 3 do
fluxograma, para um sistema desenvolvido na linguagem Delphi, item 4 do fluxograma, como
cada tecnologia transmite os dados em um padrão diferente, esse sistema é responsável por ler
esses dados, e gerar informações brutas, tais como : estado da ignição do veículo, velocidade
atual, temperatura, entre outras.

Os dados gerados pelo sistema Delphi são armazenados em uma base de dados
Postgres, item 5 do fluxograma, essa base de dados serve para alimentar dois sistemas a parte,
um sistema desktop, representado pelo item 6, no qual não iremos nos aprofundar, e um
sistema web, sendo esse o sistema onde os testes foram realizados, representado pelo item 9
do fluxograma.

O sistema web possui um banco isolado, representado pelo item 8, também

postgres, logo há necessidade de importar as posições do banco do sistema delphi para o
banco da web, ambos postgres, porém modelados de forma diferente, sendo assim, há
necessidade de traduzir as informações e armazená-las da forma correta, para isso
importadores desenvolvidos em ruby são responsáveis em transportar e formatar essas
informações, conforme item 7 do fluxograma.

Com os dados das posições dos veículos armazenadas no banco de dados da web,
vários serviços as consomem, gerando informação para o usuário final. Essas informações são
geradas em tempo real (rastreamento), em relatórios pré processados, relatórios em tempo real
demonstrados nos itens 10, 11 e 12. Logo as consultas na tabela de posições de veículos se dá
a todo momento por muitos usuários. Ao mesmo tempo que outras milhares de posições estão
sendo importadas pelos pelos serviços de importação, ou seja, a tabela possui uma grande
quantidade de escrita e leitura.

31
4.2 REQUISITOS

Para que o sistema consiga atender, tanto às expectativas dos usuários que visam
uma melhora na usabilidade, quanto às expectativas da equipe de desenvolvimento, que visam
uma solução simples e eficaz para o problema. Alguns requisitos foram levantados a fim de
guiar a escolha da melhor alternativa.
Estes requisitos foram divididos em requisitos funcionais e requisitos não
funcionais.

4.2.1 Requisitos funcionais

• Diminuir o tempo de processamento dos relatórios com dados de até 30 dias em 20%
• Diminuir o tempo de processamento dos relatórios com dados de um dia em 40%
• Diminuir o tempo de processamento dos serviços que processam dados da tabela de
posições em tempo real em 20%

4.2.2 Requisitos não funcionais

• A solução deve ser implementada preferencialmente utilizando o banco de dados

PostgreSQL
• A performance de escrita na tabela de posições (vehicle_states) não pode ser afetada
negativamente
• A performance de leitura na tabela de posições (vehicle_states) deve ser otimizada
• A solução não deve gerar grandes alterações na implementação do software, deve ser
uma implementada a nível de banco de dados.

32
4.3 CENÁRIO ATUAL

Para simular o cenário de atual do banco de dados estudado, foram criados

serviços de inclusão e consulta com a linguagem de programação Ruby simulando a
comunicação dos veículos com o sistema de rastreamento.
O primeiro serviço é responsável por simular o envio de dados referentes a
localização de um veículo para o banco Kernel, onde essas informações irão ser processadas e
tratadas para que seja possível utilizá-las na aplicação web. Conforme descrito no fluxograma.
O segundo serviço é responsável por buscar as informações já pré processadas
pelo primeiro serviço, e inseri-las no banco de dados da aplicações web, como são muitas
posições para serem processadas, é possível ter múltiplas instâncias desse mesmo serviço,
assim otimizando o processamento de dados.
Utilizando os serviços foram inseridas cerca de 1 milhão e trezentas mil posições,
estas divididas entre 6 veículos distintos, levando em consideração que cada veículo envia sua
posição a cada um minuto, no período de 6 meses. Onde 6 meses é a data limite em que os
dados são mantidos a fins de histórico. Não foram inseridos mais dados para mais veículos
devido a limitação de hardware, pois não é possível ter a mesma infraestrutura empresarial
utilizada

4.4 CENÁRIO PROPOSTO

Conforme os objetivos do estudo, trabalha-se em dois cenários visando a melhoria

da performance do banco de dados. O primeiro é o particionamento da tabela, sendo este feito
o particionamento onde a granularidade será diária, e um particionamento por de
granularidade mensal. O segundo cenário é aplicar uma extensão de base de dados colunar na
tabela estudada.

33
4.4.1 Particionamento

O cenário de particionamento foi dividido em dois, o particionamento por dia e o

particionamento por mês. Essa divisão se fez necessária pois o número de tabelas
particionadas pode influenciar nos resultados, dependendo do número de dados no qual está
sendo buscado e pelas queries que estão sendo executadas.
Para construir os cenários de testes para os modelos de particionamento foi criado
um script SQL que tem como objetivo criar as tabelas particionadas pela primeira vez,tanto
por dia, quanto por mês, em um período de 6 meses, o script pode ser visto no apêndice A .
Após todas as tabelas já estarem criadas, foi criada uma trigger e uma função, exibida no
apêndice B responsável por encaminhar todos os novos dados que forem inseridos na tabela
para suas devidas partições. Com toda a estrutura funcionando foi utilizado um terceiro script,
responsável por buscar todas as posições geradas na proposta anterior e inseri-las nos novos
bancos particionados, como não é possível realizar queries diretas entre bancos, foi necessário
a utilização do dblink, uma ferramenta postgres para consultas em conexões em bancos
distintos, o script pode ser visto no apêndice C.

4.4.2 Extensão colunar

A construção do cenário colunar foi feita através de um biblioteca open source

para extensões colunares postgres chamada cstore_fdw. Para ser possível a utilização desta
extensão foi necessário a instalação de algumas bibliotecas informadas em sua documentação.
Após todas as dependências serem instaladas, foi gerado um script de criação para a tabela
colunar e com base nos exemplos da biblioteca, sem a necessidade de mudança dos tipos de
colunas existentes na tabela original, pois esta extensão possui suporte a todos os campos
necessários.

Com a estrutura da tabela criada, se deu necessário realizar a inclusão dos dados,
porém a inserção de dados nesta nova tabela colunar não pode ser realizada por scripts como

34
na proposta anterior, existe a necessidade de todos os dados a serem inseridos estarem em um
arquivo csv pois esta extensão não possui suporte a inserções de dados através de queries. A
partir disso, foi gerado um arquivo com todos os dados do banco atua e executada a query de
inserção a partir deste arquivo.

COPY vehicle_states FROM ‘path_to_file' WITH CSV;

4.5 RESULTADOS OBTIDOS

Para medir o desempenho de cada solução proposta e compará-las com o cenário

atual da aplicações algumas consultas foram realizadas em cada arquitetura implementada.
Todas as consultas que foram utilizadas para realizar os benchmarks foram escolhidas por
serem consultas utilizadas constantemente pelos serviços do sistema e possuírem baixa
performance.
A primeira consulta a ser analisada será a busca de posições de um dia para um
veículo, ela é utilizada para mostrar ao usuário as informações em tempo real de um veículo
específico. Em média cada usuário logado no sistema dispara a consulta a cada 10 minutos.
Esta consulta também é utilizada por diversos serviços do sistema para gerar informações para
o usuário. Foram escolhidos um dia e um veículo aleatório da base de dados de teste para
realizar as consultas na solução atual e nas soluções propostas. Os resultados podem ser
verificados no gráfico 1:

35
4.6 CONCLUSÕES DOS RESULTADOS

Com base nos benchmarks realizados anteriormente percebe-se que a solução de

particionamento não causou ganhos significativos na consulta dos dados da tabela, não
importando qual granularidade fosse utilizada, sendo que em alguns casos as consultas
ficaram ligeiramente mais lentas que o cenário atual. Sendo assim, para o cenário do sistema o
particionamento não atende as expectativas e não justifica o custo de implementação.
Já a solução implementada com a extensão de base de dados colunar se mostrou
muito performática na consulta dos dados utilizadas pelo sistema, reduzindo quase que pela
metade os tempos de consulta, não importando qual fosse o intervalo entre datas utilizadas.
Porém a extensão de base de dados colunar aplicada não da suporte a single row inserts,
DELETE e UPDATE.
Como a inserção de dados na tabela estudada é constante, e há serviços no sistema
que necessitam destas consultas para fornecer informações em tempo real, ficaria complicado
trabalhar com a base de dados colunar. Porém há uma parte do sistema que utiliza registros
mais antigos desta tabela para fornecer relatórios aos usuários. As consultas dos relatórios
tendem a ser muito pesadas pois buscam uma grande quantidade de registro destas tabelas.
A extensão de base de dados colunar se mostrou muito eficiente na inclusão de
novos registros, sendo que estes necessitam estar no formato CSV, para os testes foram
realizadas a inclusão de cerca de 1 milhão e 300 mil registros na tabela de base de dados
colunar a partir de um arquivo CSV, e esta inclusão demorou cerca de 30 segundos.
Então uma possível solução para melhorar a performance do sistema estudado
seria a criação de uma tabela de base de dados colunar separada da tabela que armazena as
posições hoje, onde no final de cada período fosse feita a migração dos dados da tabela
relacional para esta tabela de base de dados colunar, que ficaria disponível para os serviços
que não trabalham com informações de tempo real. Tirando assim muita carga das tabelas
atuais.

40
5 CONCLUSÕES E TRABALHOS FUTUROS

Neste capítulo são apresentadas as conclusões finais deste trabalho, tendo como
base o objetivo proposto. Assim como os resultados obtidos com este trabalho e a proposta de
trabalhos futuros.

5.1 CONCLUSÕES

Este trabalho apresentou conceitos sobre sistemas de gerenciamento de banco de

dados, banco de dados relacionais por linhas, por colunas e particionamento de tabelas. Tendo
como foco melhorar a performance em uma tabela do banco de dados Postgres.
A pesquisa realizada neste trabalho levou os autores a quebrar o paradigma de
utilizar somente banco de dados relacionais no desenvolvimento de softwares, apesar de ser o
mais comum e na maioria das vezes atender muito bem a demanda, ainda assim há outras
formas muito eficazes de se armazenar dados que dependendo da proposta do software,
podem ser muito mais performáticas.
Tendo o embasamento teórico levantado, os autores iniciaram a implementação de
duas novas soluções, sendo estas:

• Uma solução de particionamento para banco de dados relacional

• Uma extensão de banco de dados colunar para Postgres.

Com as soluções implementadas e com o banco de dados alimentado com uma

amostra de dados. Iniciou-se um benchmark para levantar como cada solução proposta se
comportaria em relação a implementação atual. A fim de encontrar uma melhora significativa
que motivasse a implementação no ambiente de produção.
Foi levantado que a solução de particionamento não ocasionou melhorias
significativas dentro da arquitetura atual do sistema, já a extensão de base de dados colunar
reduziu quase que pela metade o tempo das consultas hoje utilizadas no sistema.

41
 De modo geral, o trabalho atingiu os objetivos propostos, já que a solução de base
de dados colunar se mostrou muito performática na busca de dados para alimentar os serviços
do sistema. E por ser uma implementação que não ocasionará grandes mudanças na
arquitetura atual do sistema, também se enquadra nos objetivos buscados pelo trabalho.

5.2 TRABALHOS FUTUROS

Com os resultados em mãos, e com o visível beneficio do uso da extensão de bases

colunares para postgreSQL, foi levantado o questionamento, caso a estrutura legada não fosse
um impedimento, o quão otimizado poderia ser o banco de dados caso utilizada uma base
colunar nativa, ou até mesmo uma base colunar em memória. Desta forma desprendendo-se
da estrutura relacional.

42
 REFERÊNCIAS

DATE, C. J.. Introdução a sistemas de Banco de Dados. 8. ed. Rio de Janeiro: Pearson, 2004.

RAMAKRISHNAN, Raghu; GEHRKE, Johanned. Sistema de Gerenciamento de Banco de

Dados. 3. Ed. New York: Mcgraw-hill, 2011.

DULLIUS, A.; SCHAEFFER, P. AS CAPACIDADES DE INOVAÇÃO EM STARTUPS:

CONSIDERAÇÕES INICIAIS. Disponível em:

<http://www.altec2015.org/anais/altec/papers/599.pdf> Acesso em: 30 agost. 2016.

SOMMERVILLE, I . ENGENHARIA DE SOFTWARE 9 EDIÇÂO. Disponivel em:

<http://unisul.bv3.digitalpages.com.br/users/publications/9788579361081/pages/_1> Acesso
em: 30 agost. 2016.

AMADEU, C. V. BANCO DE DADOS. Disponivel em:

<http://unisul.bv3.digitalpages.com.br/users/publications/9788543006833/pages/-12> Acesso
em: 30 agost. 2016

CITUSDATA (Org.). PostgreSQL Columnar Store for Analytic Workloads. Disponível em:

<https://www.citusdata.com/blog/2014/04/03/columnar-store-for-analytics/>. Acesso em: 23

out. 2016.

MICROSOFT. Particionamento. 2016. Disponível em: <https://technet.microsoft.com/pt-

br/library/ms178148(v=sql.105).aspx>. Acesso em: 23 out. 2016.

JOSKO, João Marcelo Borovina. SGBD relacionais orientados a coluna: uma nova roupagem
ao Data Warehousing. 2014. Disponível em:

<http://www.devmedia.com.br/sgbd-relacionais-orientados-a-coluna-uma-nova-roupagem-ao-
data-warehousing-parte-01/11349>. Acesso em: 23 out. 2016

43
POSTGRES (Org.). About. 2016. Disponível em: <https://www.postgresql.org/about/>.
Acesso em: 23 out. 2016.

POSTGRES (Org.). Partitioning. 2016. Disponível em:

<https://www.postgresql.org/docs/current/static/ddl-partitioning.html>. Acesso em: 23 out.

2016.

SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S.. SISTEMA DE BANCO

DE DADOS. 3. ed. São Paulo: Pearson, 2008.

COMUNIDADE BRASILEIRA DE POSTGRESSQL (Ed.). Sobre o PostgreSQL. 2016.

Disponível em: <https://www.postgresql.org.br/sobre>. Acesso em: 25 out. 2016.

AMADEU, C. V.; BANCO DE DADOS. Disponível em:

<http://unisul.bv3.digitalpages.com.br/users/publications/9788543006833/pages/-12 > Acesso

em: 30 agost. 2016.

BRETERNITZ, V. J.; SILVA, L. A.; BIG DATA: UM NOVO CONCEITO GERANDO

OPORTUNIDADES E DESAFIOS. Disponível em:

<http://201.55.32.167/RETC/index.php/RETC/article/view/74/pdf > Acesso em: 30 agost.

2016.

BARROS, Aidil Jesus da Silveira; LEHFELD, Neide Aparecida de Souza. Fundamentos de

Metodologia científica. 3. ed. São Paulo: Pearson Prentice Hall, 2008.

FONSECA, J. J. S. Metodologia da pesquisa científica. Fortaleza: UEC, 2002. Apostila.

Disponível em: <http://www.ia.ufrrj.br/ppgea/conteudo/conteudo-2012-
1/1SF/Sandra/apostilaMetodologia.pdf> Acesso em: 30 agost. 2016.

44
GIL, Antonio Carlos. Como Elaborar Projetos de Pesquisa. 4. ed. São Paulo: Atlas, 2007.
Disponível em:

<https://professores.faccat.br/moodle/pluginfile.php/13410/mod_resource/
content/1/como_elaborar_projeto_de_pesquisa_-_antonio_carlos_gil.pdf>. Acesso em: 16
nov. 2016.

CITUSDATA. Cstore_fdw. 2018. Disponível em <https://github.com/citusdata/cstore_fdw>

Acesso em: 01 jun. 2018

45
APÊNDICES

46
 APÊNDICE C – INSTALAÇÃO CSTORE_FDW

Tutorial completo
https://github.com/citusdata/cstore_fdw

Instalação de dependencias:

# Ubuntu 10.4+
sudo apt-get install protobuf-c-compiler
sudo apt-get install libprotobuf-c0-dev

Dentro do projeto cstore_fdw, incluir caminho do pg_config no comando make

PATH=/usr/local/pgsql/bin/:$PATH make
sudo PATH=/usr/local/pgsql/bin/:$PATH make install

Adicionar configuração em postgresql.conf

shared_preload_libraries = 'cstore_fdw'

Criar extensão

CREATE EXTENSION cstore_fdw;

CREATE SERVER cstore_server FOREIGN DATA WRAPPER cstore_fdw;

Criar tabela a ser utilizada, exemplo:

CREATE FOREIGN TABLE customer_reviews

(
customer_id TEXT,
review_date DATE,
review_rating INTEGER,
)
SERVER cstore_server
OPTIONS(compression 'pglz');

50