Conclusões do trabalho realizado

Nesta dissertação foram numa primeira fase identificadas e descritas as bases de dados NoSQL do tipo column-based mais representativas do mercado com base no seu prestígio, documentação disponível, o número de grandes empresas que já adotaram os seus serviços e tendo como base o ranking de base de dados disponibilizado pela DB- Engines. Essas bases de dados foram o Cassandra e o HBase. Apesar de serem ambas do mesmo tipo e terem como base o projeto BigTable da Google, são tecnologias distintas e com caraterísticas muito próprias como se pôde verificar na análise efetuada. É importante salientar que não é correto afirmar que uma é melhor que a outra porque o seu desempenho depende da sua aplicação e do cenário em questão, dado que ambas são bastante eficientes e fornecem altos índices de desempenho e fiabilidade dos dados. Numa segunda fase foi selecionada uma das bases de dados NoSQL em análise de forma a efetuar um estudo de caso que teve como base verificar o desempenho da mesma relativamente à tecnologia relacional, no que diz respeito ao tempo de resposta às mesmas consultas. Dado que o Cassandra é considerada como sendo a base de dados NoSQL do tipo column-based mais representativa, foi a escolhida para realizar o estudo de caso que não é justo que se nomeie como estudo comparativo já que foi algo desenvolvido em torno de um cenário específico, pelo que noutro tipo de cenário os resultados obtidos poderiam ser diferentes. Assim, com base no dataset escolhido foram criadas as estruturas de cada uma das bases de dados em estudo, nomeadamente Cassandra e MySQL. É importante referir que a abordagem do Cassandra é totalmente diferente da tecnologia relacional, dado que este segue uma filosofia direcionada para as consultas em que estas devem ser o primeiro aspeto a ser pensado com base no fluxo de trabalho e necessidades de uma dada aplicação. Assim, as tabelas no Cassandra devem ser criadas com base nas consultas pré-definidas onde a definição da chave primária é um fator chave, dado que define a forma como os dados serão armazenados e ordenados em disco e pelos vários

70 nós. A chave representa também um fator importante no que diz respeito aos dados a consultar para uma determinada tabela. Assim, o schema de uma tabela Cassandra deve ser desenvolvido com vista a obter o melhor desempenho possível para determinado acesso à base de dados, retornando sempre o menor número de registos possível entre grandes volumes de dados.

O estudo de caso teve como foco o desempenho das consultas definidas relativamente ao volume de dados mas também do ponto de vista do acesso simultâneo às consultas por parte de vários utilizadores. O que se verificou foi que para acessos de apenas um utilizador e para os primeiros volumes de dados o Cassandra e o MySQL apresentaram desempenhos próximos um do outro, sendo que à medida que o volume de dados foi aumentando e o número de acessos simultâneo de utilizadores também, o Cassandra foi apresentando melhor desempenho que o MySQL. Isto verificou-se nas primeiras consultas que exigiam ao MySQL aceder a várias tabelas para retornar uma resposta à consulta e onde aliado a isso o número total de registos retornado para os vários volumes de dados não se verificou como muito avultado. O mesmo não se verificou na terceira consulta, em que do ponto de vista do MySQL, pelo fato de apenas ter de aceder a três tabelas e com base nos índices criados para otimizar o seu desempenho, se registaram tempos médios de resposta bastante reduzidos em todos os volumes de dados e até quando acedida por vários utilizadores. Por sua vez o Cassandra apresentou um desempenho inferior relativamente a esta consulta, dado que o número de registos verificado se revelou elevado e foi aumentando à medida que o volume de dados foi aumentando o que traduziu numa diminuição de desempenho gradual do Cassandra. O mesmo se registou para múltiplos acessos simultâneos à consulta. Pode-se dizer que por se tratar de uma situação em que o Cassandra tem que realizar um “large scan” aos dados, a estrutura da tabela teria que ser otimizada de forma a dar uma resposta mais eficiente à consulta.

Em suma, é importante ter em conta que estas são bases de dados bastante diferentes e ambas são bastante úteis para cenários de trabalho específicos. É muito importante um utilizador ter em mente aquilo que necessita antes de optar por uma destas bases de dados ou de pensar em mudar da tecnologia relacional para o Cassandra por exemplo. Apesar do Cassandra lidar de uma forma bastante eficiente, rápida e flexível com grandes quantidades de dados, podendo estes ser armazenados de forma estruturada ou não estruturada, o cliente deve ter em consideração a mudança de paradigma que envolve esta alteração e ainda o facto de o Cassandra não permitir efetuar operações como joins ou

71 subconsultas aos dados. Assim, apesar de o Cassandra apresentar um elevado desempenho é importante o cliente fazer uma análise do que realmente necessita para o cenário de trabalho em questão e perceber se realmente necessita de uma base de dados NoSQL e de todas estas mudanças de paradigma que estas implicam, para apresentar um bom desempenho. Este foi assim um dos desafios encontrados ao longo desta dissertação, a adaptação a um novo paradigma e uma nova forma de pensar, dado que no decorrer no curso apenas tinha trabalhado com tecnologia de base de dados relacional.

No decorrer desta dissertação destaco também a presença na conferência CAPSI 2015 enquanto autor de um artigo baseado em parte do trabalho realizado nesta dissertação, respetivamente o estudo exploratório realizado acerca das bases de dados NoSQL do tipo column-based mais representativas do mercado, o Cassandra e o HBase. Foi uma experiência nova que considero ter sido bastante enriquecedora e que me permitiu estar em contacto com colegas e profissionais da área das tecnologias e sistemas de informação e trocar algumas ideias com os mesmos acerca das bases de dados NoSQL e do impacto que as mesmas têm tido.