Linux

Conhecido pela sua eficiˆencia, o Linux ´e um sistema operacional open-source com v´arias distribui¸c˜oes dispon´ıveis, permitindo o uso deste sistema para diversas aplica¸c˜oes diferen- tes, como servidores, computadores pessoais, dispositivos m´oveis e at´e mesmo internet das coisas. Por causa da alta flexibilidade e abertura deste sistema, ´e poss´ıvel a escolha de melhor tecnologia poss´ıvel sem nenhum tipo de restri¸c˜ao comercial nem de licen¸ca, dei- xando o ambiente computacional mais favor´avel ao desenvolvimento de novas tecnologias. Al´em disso, o Linux ´e um sistema operacional muito est´avel, tornando o ambiente mais confi´avel e com baixo risco de falhas.

4.2.3

Tecnologia Escolhida

O CentOS, que ´e uma distribui¸c˜ao do Linux, tamb´em open-source, otimizada para uso em servidores foi o sistema operacional escolhido para uso em nosso ambiente devido `a excelente rela¸c˜ao custo-benef´ıcio. Considerando que nossas aplica¸c˜oes n˜ao dependem de nenhuma ferramenta da Microsoft que necessite de um ambiente Windows, foi poss´ıvel a escolha da melhor tecnologia para o uso em nosso servidor sem nenhuma preocupa¸c˜ao com compatibilidade de sistemas. Al´em disso, esta decis˜ao se mostrou bastante acertada durante o per´ıodo de uso do sistema, uma vez que ele atendeu `as expectativas e n˜ao apresentou nenhum tipo de falhas ou travamentos.

4.3

SGBD

No que diz respeito ao SGBD (Sistema de Gerenciamento de Banco de Dados) , algumas quest˜oes foram discutidas para que a ferramenta pudesse ser considerada adequada ao sistema. A lista a seguir define todos os crit´erios utilizados para esta avalia¸c˜ao:

• Familiaridade dos desenvolvedores: O curto tempo dispon´ıvel tornava necess´ario algum hist´orico de trabalho de ao menos parte dos desenvolvedores com esta, a fim de que fosse dispens´avel um investimento muito grande para aprender como manuse´a-la.

• Atender aos requisitos: A ferramenta deve ser capaz de armazenar os dados de forma a garantir a integridade dos mesmos e, ao mesmo tempo, permitir que os usu´arios

28 fa¸cam acessos simultˆaneos ao sistema. Al´em disso, por serem armazenados no banco dados considerados sens´ıveis, como senha e CPF, estes precisam ser protegidos con- tra acessos diretos `a base, por isso deve haver mecanismos internos de seguran¸ca de forma que tais informa¸c˜oes sejam criptografadas e escondidas de qualquer um que venha a ter acesso direto ao SGBD.

• Escalabilidade: ´E necess´ario ter um banco de dados que seja escal´avel, ou seja, tenha a capacidade de atender a um grande volume de requisi¸c˜oes de forma r´apida e que, conforme esse n´umero varie, o banco conseguisse absorver essa varia¸c˜ao e responder ativamente de alguma forma, pois, como temos uma ferramenta que disponibiliza aos alunos suas salas de aula e hor´arios, se todos estes resolvessem utilizar o sistema no mesmo instante, ter´ıamos nada menos do que 49.128 usu´arios fazendo requisi¸c˜oes simultˆaneas ao sistema e, com um n´umero t˜ao grande de usu´arios, ´e necess´ario que o sistema consiga, de alguma forma, atender a todos e respondˆe-los corretamente em um intervalo de tempo aceit´avel.

• Gerenciamento de uma grande massa de dados: Com aproximadamente 50 (cin- quenta) mil usu´arios em potencial, a massa de dados gerada diariamente seria gi- gantesca acarretando na necessidade de se ter um banco de dados que desse conta de gerir toda essa massa. Por serem dados hist´oricos que relatam sobre a vida de um aluno na universidade, desde presen¸cas a quantidade de per´ıodos, mat´erias cursadas, etc, esses dados n˜ao poderiam ser apagados, acarretando no fato de que a base s´o cresceria e nunca poderia ser reduzida, uma vez que qualquer aluno j´a inscrito no sistema pode acessar o site para realizar consultas.

• Compatibilidade: Era necess´ario ter uma ferramenta que fosse compat´ıvel com todas as demais tecnologias selecionadas para o projeto. Como todas as tecnologias eram uma decis˜ao dos desenvolvedores, a ferramenta de banco de dados tinha que ser compat´ıvel com todas as demais ferramentas, desde o Sistema Operacional at´e a Linguagem de Programa¸c˜ao escolhida.

4.3.1

PostgreSQL

O primeiro candidato ´e o PostgreSQL [The PostgreSQL Global Development Group, 2016]. Infelizmente, ele n˜ao atende ao primeiro ponto pois nenhum dos desenvolvedores do sis-

tema proposto possui hist´orico de uso com essa ferramenta.

Por ser um SGBD (Sistema de Gerenciamento de Banco de Dados), o PostgreSQL ´e capaz de atender ao segundo quesito sem problemas: Ele possui um sistema interno de controle de locks, que permite acessos simultˆaneos aos dados e garante que os dados consultados pela aplica¸c˜ao em cada conex˜ao sempre estar˜ao isolados dos dados que s˜ao produzidos pelas demais. Al´em disso, ele possui uma biblioteca que se chama pgcrypto, que permite encriptar certas colunas de determinadas tabelas do banco, de forma que esses dados sempre estejam protegidos de qualquer acesso externo que n˜ao seja atrav´es de requisi¸c˜oes da aplica¸c˜ao.

No caso do terceiro ponto, o Postgre ´e, dentre os SGBDs gratuitos, o mais utilizado em aplica¸c˜oes de grande porte, que necessitam de um grande volume de tr´afico de dados. Esse SGBD tamb´em possui heur´ısticas internas no seu m´odulo de otimiza¸c˜ao muito mais robustas e eficientes que as da maioria dos seus concorrentes, permitindo que, por exemplo, ele execute uma ordena¸c˜ao em dados de uma tabela utilizando o MergeSort antes de realizar uma busca, otimizando assim o acesso indexado a disco. Esses fatores indicam que ele atende a este ponto de forma satisfat´oria, apesar de apresentar lentid˜ao conforme o volume de dados aumenta muito.

No quarto ponto, o Postgre possui certos limites em rela¸c˜ao `a capacidade, que ser˜ao listados a seguir:

Limite Valor

Tamanho m´aximo da base Ilimitado Tamanho m´aximo de tabela 32 TB

Tamanho m´aximo de tupla 1.6 TB Tamanho m´aximo de campo 1 GB

Limite de linhas por tabela Ilimitado Limite de colunas por tabela 250 - 1600

Limite de ´ındices por tabela Ilimitado

Tabela 4.1: Limites de armazenamento do PostgreSQL

Como podemos perceber analisando a Tabela 4.1, a base de dados pode conter um tamanho ilimitado, o que atende `a demanda crescente de dados que o e-Chamada proporcionaria. Al´em disso, cada tabela possui um tamanho m´aximo de 32 TB, o que

30 tamb´em atende ao quarto ponto, pois, no geral, os dados produzidos pelo sistema s˜ao relativamente pequenos e, apesar de serem volumosos, ainda n˜ao seriam suficientes para que o limite fosse atingido com facilidade.

Em rela¸c˜ao ao quinto ponto, o PostgreSQL atende `as necessidades, pois ´e relativa- mente f´acil instal´a-lo no CentOS e trabalhar com ele utilizando Java, que, como visto nas se¸c˜oes 4.1 e 4.2, foram as tecnologias escolhidas para Sistema Operacional e Linguagem de Programa¸c˜ao, respectivamente.

4.3.2

MySQL

O segundo candidato selecionado foi o MySQL [Oracle, 2016]. Apesar de haver certo preconceito dentre os usu´arios do MySQL, este ´e o banco mais conhecido dentre os de c´odigo aberto atualmente. Criado em 1980, O MySQL ´e utilizado por diversas empresas que utilizam aplica¸c˜oes cr´ıticas, como a NASA e a Motorola, por exemplo.

Por ser um SGBD, O MySQL ´e capaz de garantir o segundo ponto com efic´acia, j´a que todos os SGBDs apresentam as propriedades ACID.

Em rela¸c˜ao ao terceiro ponto, o MySQL deixa a desejar em certos aspectos pois o seu m´odulo de otimiza¸c˜ao n˜ao ´e t˜ao robusto e poderoso como o do Oracle ou Postgre, por´em ele tamb´em ´e utilizado em aplica¸c˜oes de grande porte, o que indica que, mesmo com essa limita¸c˜ao, o MySQL consegue atender bem a esse requisito.

Limite Valor

Tamanho m´aximo da base Ilimitado

Tamanho m´aximo de tabela Varia de acordo com o SO Tamanho m´aximo de tupla 65 KB

Tamanho m´aximo de campo 65 KB Limite de linhas por tabela Ilimitado Limite de colunas por tabela 4096

Limite de ´ındices por tabela 64

Tabela 4.2: Limites de armazenamento do MySQL

Como podemos perceber pela Tabela 4.2, o MySQL limita bastante fatores como tamanho m´aximo de tupla, por´em o MySQL possui um diferencial dos demais SGBDs:

Ele armazena Blob e Text de forma diferenciada. Ele utiliza um esquema de referˆencias, n˜ao armazenando o dado propriamente dito na tabela, de forma que cada campo desses possua apenas de 9 a 12 bytes de tamanho. Apesar de todas essas limita¸c˜oes, por conta deste esquema de referˆencia, isso torna o MySQL vi´avel quando estudamos o quarto ponto. Por fim, o MySQL ´e compat´ıvel com o CentOS e existe um drive espec´ıfico para utiliz´a-lo em conjunto com Java. Isso somado com o fato de haver experiˆencia pr´evia do time com esta ferramenta torna ele um forte candidato `a aceita¸c˜ao.

4.3.3

SQL Server

Dentre os candidatos, o SQL Server ´e um dos mais promissores e um dos melhores. Po- r´em ele foi logo descartado pois, al´em de apenas funcionar em Sistemas Operacionais da Microsoft, sua licen¸ca custa $931,00. Logo, por conta deste empecilho, o SQL Server foi descartado da an´alise.