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.
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.
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
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
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.
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.
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
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.
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
• 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
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).
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”.
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
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 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.
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
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.
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:
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.
• 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
• 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.
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.
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.
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.
• 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.
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.
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
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.
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.
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:
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.
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.
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.
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
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-
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
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');
