Pós-Graduação em Ciência da Computação
JOÃO BOSCO DE SOUZA JUNIOR
NoSQLClusterAdmin: Uma Ferramenta para Configuração,
Gerenciamento e Monitoramento de SGBD NoSQL
Fragmentados e Replicados
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
RECIFE 2017
João Bosco de Souza Junior
NoSQLClusterAdmin: Uma Ferramenta para Configuração, Gerenciamento e Monitoramento de SGBD NoSQL Fragmentados e Replicados
ORIENTADORA: Profa. Valéria Cesário Times, PhD
COORIENTADOR: Prof. Claudivan Cruz Lopes, PhD
RECIFE 2017
Este trabalho foi apresentado à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre Profissional em Ciência da Computação.
Este trabalho foi apresentado à Pós-Graduação EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE PROFISSIONAL EM CIÊNCIA DA COMPUTAÇÃO.
ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE PROFISSIONAL EM CIÊNCIA DA COMPUTAÇÃO.
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
S729n Souza Junior, João Bosco de
NoSQLClusterAdmin: uma ferramenta para configuração, gerenciamento e monitoramento de SGBD NoSQL fragmentados e replicados / João Bosco de Souza Junior. – 2017.
146 f.: il., fig., tab.
Orientadora: Valéria Cesário Times.
Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, 2017.
Inclui referências, apêndices e anexo.
1. Banco de dados. 2. Avaliação experimental. I. Times, Valéria Cesário (orientadora). II. Título.
025.04 CDD (23. ed.) UFPE- MEI 2017-195
João Bosco de Souza Junior
NoSQLClusterAdmin: Uma Ferramenta para Configuração,
Gerenciamento e Monitoramento de SGBD NoSQL Fragmentados e
Replicados
Aprovado em 28/ 07/ 2017.
BANCA EXAMINADORA
____________________________________________ Prof. Fernando da Fonseca de Souza
Centro de Informática / UFPE
____________________________________________ Prof. Flavius da Luz e Gorgônio
Universidade Federal do Rio Grande do Norte
____________________________________________ Profa. Valéria Cesário Times
Centro de Informática / UFPE (Orientadora)
Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre Profissional em 28 de julho de 2017.
DISSERTAÇÃO APRESENTADA AO PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DA UNIVERSIDADE FEDERAL DE PERNAMBUCO, COMO REQUISITO PARCIAL PARA A OBTENÇÃO DO TÍTULO DE MESTRE PROFISSIONAL EM 28 DE JULHO DE 2017.
DISSERTAÇÃO APRESENTADA AO PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DA UNIVERSIDADE FEDERAL DE PERNAMBUCO, COMO REQUISITO PARCIAL PARA A OBTENÇÃO DO TÍTULO DE MESTRE PROFISSIONAL EM 28 DE JULHO DE 2017.
DISSERTAÇÃO APRESENTADA AO PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DA UNIVERSIDADE FEDERAL DE PERNAMBUCO, COMO REQUISITO PARCIAL PARA A OBTENÇÃO DO TÍTULO DE MESTRE PROFISSIONAL EM 28 DE JULHO DE 2017.
Dedico esta dissertação a minha esposa, meu(minha) filho(a) que estar por vir e meus pais, Luanna Abílio (esposa), Filho(a), João Bosco de Souza e Maria do Carmo.
AGRADECIMENTOS
Em primeiro lugar, agradeço a Deus, pelo inesgotável amor, misericórdia e fidelidade. Obrigado Senhor!
Aos meus pais, João Bosco e Maria do Carmo, pelo apoio incondicional prestado em todos os momentos da minha vida e, principalmente, pela educação que é a maior herança que um pai e uma mãe podem deixar para o filho, e pelo amor e dedicação que nunca poderei recompensar.
À minha esposa e meu grande amor, Luanna Abílio, fonte de carinho, compreensão e que me apoiou nos momentos difíceis desta caminhada.
Aos meus familiares, que de alguma forma contribuíram e contribuem até hoje com minha formação como ser humano.
À minha competente orientadora, professora Valéria Times, pela dedicação a tudo que fez por mim nessa jornada, pela compreensão e paciência nos momentos difíceis, pelos valorosos ensinamentos, orientações, e pela confiança depositada neste trabalho.
Ao meu grande amigo e coorientador, professor Claudivan Lopes, pelas renúncias dos seus momentos de lazer em detrimento das nossas reuniões e discussões sobre a pesquisa, pela paciência, compreensão, apoio nos momentos de dificuldade, e pelos pertinentes ensinamentos e confiança depositada neste trabalho.
Ao professor da UFRN, Flavius Gorgônio, e aos professores do CIn, em especial, ao professor Fernando da Fonseca, pela formação proporcionada, pelos ensinamentos, e pelas relevantes contribuições que foram colocadas para melhorar a qualidade deste trabalho.
Aos amigos Allan e Éverton Trindade pelos ensinamentos técnicos complementares que me ajudaram no desenvolvimento deste trabalho.
Aos colegas de trabalho da coordenação de TI do IFPB Campus Patos, Gleidson Palmeira, Leonardo Navarro e Thales Pordeus, pela compreensão e divisão das tarefas nos momentos que precisei me ausentar em decorrência das atividades do mestrado.
À direção do IFPB Campus Patos, pelo total apoio na busca dessa conquista. Ao IFPB, e a SETEC/MEC por viabilizarem a realização deste mestrado.
Enfim, agradeço a todos que direta e indiretamente me ajudaram a trilhar essa longa e árdua caminhada que é um mestrado e que contribuíram para o sucesso dessa caminhada.
“Por isso não tema, pois estou com você; não tenha medo, pois sou o seu Deus. Eu o fortalecerei e o ajudarei; eu o segurarei com a minha mão direita vitoriosa. ”
RESUMO
Sistemas de gerenciamento de bancos de dados não relacionais, denominados SGBD NoSQL, geralmente apresentam uma arquitetura distribuída entre vários servidores, o que permite a fragmentação e replicação dos dados. Isso possibilita o processamento distribuído e, consequentemente, um melhor desempenho na manipulação de grandes volumes de dados. Para as tarefas de configuração, gerenciamento e monitoramento dessa arquitetura distribuída, os administradores de SGBD NoSQL necessitam de ferramentas para auxiliar nessas tarefas, pois na proporção que a quantidade de dados e servidores aumenta, tais tarefas se tornam mais dispendiosas, complexas e sujeitas a erros. Durante esta pesquisa foram identificadas ferramentas com o propósito de auxiliar os administradores nas tarefas de configuração, gerenciamento e monitoramento de SGBD NoSQL fragmentados e replicados. Contudo, as ferramentas estudadas são predominantemente restritas para uso em um único SGBD NoSQL, tendo em vista as distinções de arquitetura distribuída e procedimentos adotados para realização das tarefas de configuração, gerenciamento e monitoramento adotados por cada SGBD. Outra limitação observada diz respeito às funcionalidades disponíveis nessas ferramentas, que em muitos casos, se restringem a auxiliar na realização apenas de uma das três tarefas citadas. Assim, este trabalho apresenta a especificação, projeto, implementação e avaliação de uma ferramenta web e open source, denominada NoSQLClusterAdmin, cuja contribuição principal é auxiliar os administradores de bancos de dados nas tarefas de configuração, gerenciamento e monitoramento de SGBD NoSQL fragmentados e replicados, independentemente da solução de SGBD adotada. Outra contribuição é o fato da ferramenta uniformizar os procedimentos para configuração, gerenciamento e monitoramento dos SGBD, independentemente da solução NoSQL utilizada. A ferramenta desenvolvida para plataforma web foi avaliada por meio de testes de usabilidade aplicados com estudantes e profissionais com experiência no manuseio desse tipo de SGBD. Os resultados dessa avaliação mostraram que: (i) 70% dos usuários indicaram que a ferramenta NoSQLClusterAdmin pode ser utilizada em vários SGBD NoSQL distintos; (ii) a variedade de funcionalidades de configuração, gerenciamento e monitoramento disponíveis na ferramenta satisfez 80% dos usuários; e (iii) 85% concordou que a ferramenta padroniza a realização das tarefas de configuração, gerenciamento e monitoramento de SGBD NoSQL fragmentados e replicados, independentemente da solução de SGBD utilizada.
Palavras-chave: Fragmentação de SGBD NoSQL. Replicação de SGBD NoSQL. Ferramentas
ABSTRACT
Not Only SQL database management systems, called NoSQL DBMSs, typically have a distributed architecture across multiple servers, which allows for the fragmentation and replication of data. This enables distributed processing and consequently better performance in handling large volumes of data. For the configuration, management, and monitoring tasks of this distributed architecture, NoSQL DBMS administrators need tools to assist in these tasks, as the amount of data and servers increases, such tasks become more costly, complex, and error prone. During this research, tools were identified to assist administrators in the tasks of configuration, management and monitoring of fragmented and replicated NoSQL DBMS. However, the tools studied are predominantly restricted for use in a single NoSQL DBMS, in view of the distributed architecture distinctions and procedures adopted to perform the configuration, management and monitoring tasks adopted by each DBMS. Another limitation observed relates to the functionalities available in these tools, which in many cases, are restricted to assist in performing only one of the three tasks mentioned. This work presents the specification, design, implementation and evaluation of a web and open source tool, called NoSQLClusterAdmin, whose main contribution is to assist database administrators in the tasks of configuration, management and monitoring of fragmented and replicated NoSQL DBMS, regardless of the adopted DBMS solution. Another contribution is the fact that the tool standardizes the procedures for configuration, management and monitoring of DBMS, regardless of the NoSQL solution used the tool was developed for web platform and was evaluated through usability tests applied with students and professionals with experience in the handling of this type of DBMS. The results of this evaluation showed that: (i) 70% of users indicated that the NoSQLCluster Admin tool can be used in several different NoSQL DBMS; (ii) the variety of configuration, management and monitoring functionalities available in the tool satisfied 80% of users; And (iii) 85% agreed that the tool standardizes the performance of the fragmented and replicated configuration, management and monitoring tasks of NoSQL DBMS, regardless of the DBMS solution used.
Keywords: NoSQL DBMS Fragmentation. NoSQL DBMS Replication. NoSQL DBMS
LISTA DE FIGURAS
Figura 1 – Exemplo do modelo orientado a chave-valor ... 29
Figura 2 – Exemplo do modelo orientado a colunas ... 29
Figura 3 – Exemplo do modelo orientado a documentos ... 30
Figura 4 – Exemplo do modelo orientado a grafos ... 31
Figura 5 – Topologia MongoDB – Fragmentado (Sharding) e replicado ... 33
Figura 6 – Topologia Cassandra – A) replicação sem fragmentação B) fragmentação com replicação ... 34
Figura 7 – Arquitetura do Framework TIRAMOLA – para provisionamento elástico de bancos de dados NoSQL ... 49
Figura 8 – Arquitetura do Framework MET – Para configuração, monitoramento e gerenciamento automático de clusters na nuvem ... 51
Figura 9 – Diagrama de casos de uso da ferramenta – configuração ... 63
Figura 10 – Diagrama de casos de uso da ferramenta – gerenciamento ... 64
Figura 11 – Diagrama de casos de uso da ferramenta – monitoramento... 65
Figura 12 – Arquitetura da ferramenta – Módulo de configuração ... 67
Figura 13 – Arquitetura da ferramenta – Módulo de gerenciamento ... 67
Figura 14 – Arquitetura da ferramenta – Módulo de monitoramento ... 68
Figura 15 – Síntese das fases de planejamento, execução e análise dos resultados do experimento ... 79
Figura 16 – Síntese das etapas seguidas na realização dos testes de usabilidade... 87
Figura 17 – Distribuição dos usuários testadores por pais e estado/cidade ... 91
Figura 18 – Distribuição dos usuários testadores por formação profissional ou acadêmica ... 92
Figura 19 – Distribuição dos usuários por tempo de experiência na área de TI ... 92
Figura 20 – Distribuição dos usuários por tempo de experiência com banco de dados ... 92
Figura 21 – Distribuição dos usuários por tempo de experiência apenas com SGBD NoSQL ... 93
Figura 22 – Quantidade de SGBD NoSQL distintos manuseados por usuário ... 93
Figura 23 – SGBD NoSQL manuseados pelos usuários ... 94
Figura 24 – Percentual de usuários que vivenciou alguma experiência de trabalho com SGBD NoSQL fragmentados e replicados ... 94
Figura 26 – Percentual de usuários que já utilizou ferramentas para auxiliar no processo de
configuração, gerenciamento e (ou) monitoramento de SGBD NoSQL fragmentado e replicado ... 95
Figura 27 – Tempo de experiência dos usuários com ferramentas para auxiliar no processo de
configuração, gerenciamento e (ou) monitoramento de SGBD NoSQL fragmentado e replicado ... 95
Figura 28 – Tela com a visualização das instâncias de clusters de SGBD NoSQL configuradas
... 117
Figura 29 – Tela para adição de novo nó ao cluster Classandra ... 117 Figura 30 – Tela com a lista dos nós configurados em um cluster Cassandra ... 117 Figura 31 – Painel de gerenciamento dos serviços configurados para o cluster Cassandra .. 118 Figura 32 – Painel de visualização do status dos nós configurados para o cluster Cassandra
... 118
Figura 33 – Painel de visualização das métricas gerais das máquinas que mantem os nós
configurados para o cluster Cassandra ... 119
LISTA DE QUADROS
Quadro 1 - Recursos disponíveis nas versões da ferramenta OPSCenter ... 42
Quadro 2 – Recursos disponíveis nas ferramentas da MongoDB, Inc. ... 44
Quadro 3 – Recursos disponíveis na ferramenta Redise Pack ... 45
Quadro 4 – Recursos disponíveis na ferramenta ManageEngine ... 46
Quadro 5 – Recursos disponíveis na ferramenta Hecuba ... 48
Quadro 6 – Recursos disponíveis no framework TIRAMOLA ... 50
Quadro 7 – Recursos disponíveis no framework MET ... 51
Quadro 8 – Recursos disponíveis nas demais ferramentas citadas ... 54
Quadro 9 – Comparação entre as soluções estudadas nas seções anteriores ... 56
Quadro 10 – Comentários negativos sobre a ferramenta ... 108
LISTA DE TABELAS
Tabela 1 – Percentuais de respostas para as perguntas relacionadas as impressões gerais sobre
a ferramenta ... 96
Tabela 2 – Percentuais de respostas para as perguntas relacionadas as telas da ferramenta ... 97
Tabela 3 – Percentuais de respostas para as perguntas relacionadas as terminologias e informações utilizadas na ferramenta ... 98
Tabela 4 – Percentuais de respostas para as perguntas relacionadas a aprendizagem da ferramenta ... 98
Tabela 5 – Percentuais de respostas para as perguntas relacionadas à capacidade da ferramenta ... 99
Tabela 6 – Percentuais de respostas para as perguntas relacionadas às funcionalidades associadas à configuração de bancos de dados NoSQL fragmentados e replicados da ferramenta ... 99
Tabela 7 – Percentuais de respostas para as perguntas relacionadas às funcionalidades associadas ao gerenciamento de bancos de dados NoSQL fragmentados e replicados da ferramenta ... 100
Tabela 8 – Percentuais de respostas para as perguntas relacionadas às funcionalidades associadas ao monitoramento de bancos de dados NoSQL fragmentados e replicados da ferramenta ... 101
Tabela 9 – Análise da Dimensão 1 ... 103
Tabela 10 – Análise da Dimensão 2 ... 103
Tabela 11 – Análise da Dimensão 3 ... 104
Tabela 12 – Análise da Dimensão 4 ... 104
Tabela 13 – Análise da Dimensão 5 ... 104
Tabela 14 – Análise da Dimensão 6 ... 105
Tabela 15 - Análise da Dimensão 7 ... 105
Tabela 16 – Análise da Dimensão 8 ... 105
Tabela 17 – Análise global das oito dimensões ... 107
LISTA DE EQUAÇÕES
Equação 1– Fórmula para cálculo do tamanho da amostra de uma população desconhecida 37 Equação 2 – Cálculo do tamanho da amostra de participantes para realização dos testes de
SUMÁRIO
1 1.1 1.2 1.3 1.4 2 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.1.7 2.2 2.2.1 2.3 3 3.1 3.1.1 3.1.2 INTRODUÇÃO ... 18 Contextualização ... 18 Motivação ... 19 Objetivos ... 20 Estrutura da Dissertação ... 21 FUNDAMENTAÇÃO TEÓRICA ... 22Bancos de Dados NoSQL ... 22
Escalabilidade ... 23
Elasticidade ... 24
Disponibilidade ... 24
Teorema CAP ... 26
ACID Vs BASE ... 27
Modelos de Banco de Dados NoSQL ... 28
Topologias das Soluções NoSQL ... 32
Testes de Usabilidade de Software ... 35
Etapas ... 37
Considerações Finais do Capítulo ... 38
TRABALHOS RELACIONADOS ... 40
Ferramentas Comerciais ... 41
DataStax OPSCenter ... 41
3.1.3 3.1.4 3.2 3.2.1 3.2.2 3.2.3 3.3 3.4 3.5 4 4.1 4.2 4.2.1 4.2.2 4.3 4.3.1 4.3.2 4.4 4.4.1 4.4.2 4.5 5 Redise Pack ... 44 ManageEngine ... 46 Ferramentas Acadêmicas ... 47 Hecuba ... 47 TIRAMOLA ... 48 MET ... 50 Outras Ferramentas ... 52
Análise das Ferramentas ... 55
Considerações Finais do Capítulo ... 57
A FERRAMENTA NoSQLClusterAdmin ... 58
Considerações Iniciais do Capítulo ... 58
Aspectos de Análise ... 58
Requisitos ... 59
Casos de Uso ... 62
Aspectos de Projeto ... 65
Arquitetura da Ferramenta ... 66
Interação entre os Módulos da Ferramenta ... 68
Aspectos de Implementação ... 70
Funcionalidades Implementadas ... 70
Tecnologias Adotadas ... 75
Considerações Finais do Capítulo ... 76
5.1 5.2 5.2.1 5.2.2 5.2.3 5.3 5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.4 5.4.1 5.4.2 5.4.3 6 6.1 6.2 6.3 Estrutura do Capítulo ... 78 Planejamento ... 80
Definição dos Objetivos, Metas e Hipóteses ... 80
Definição do Universo Populacional e da Amostra ... 81
Definição e Preparação dos Instrumentos ... 82
Execução ... 86
Divulgação ... 88
Agendamento ... 89
Preparação do Ambiente de Teste ... 89
Realização do Teste de Usabilidade ... 90
Coleta dos Dados ... 90
Análise dos Resultados ... 91
Apresentação dos Dados Quantitativos ... 91
Análise Estatística dos Dados Quantitativos ... 101
Apresentação dos Dados Qualitativos ... 107
CONCLUSÃO ... 110
Contribuições da Dissertação ... 111
Limitações ... 112
Trabalhos Futuros ... 112
REFERÊNCIAS ... 113
APÊNDICE B – Documentação de Apoio a Realização dos Testes de Usabilidade ... 120
1 INTRODUÇÃO
Em decorrência do volume de dados manipulados, é uma tendência que os Sistemas de Gerenciamento de Bancos de Dados Not only SQL1, ou SGBD NoSQL, utilizem diversos
servidores (nós) para distribuição dos seus dados. No entanto, à medida que a quantidade de nós aumenta, as tarefas de configuração, gerenciamento e monitoramento desses vão se tornando dispendiosa e sujeita a erros, sendo necessária a utilização de ferramentas que auxiliem os administradores de bancos de dados nessas tarefas. Com esse propósito, foram identificadas soluções de ferramentas e frameworks (DATASTAX, 2017; MANAGEENGINE, 2017; REDIS LABS - HOME OF REDIS, 2017; MONGOCLIENT, 2017). Contudo, as soluções estudadas são restritas para o uso de um SGBD NoSQL particular ou, quando abrangem mais de um, suas funcionalidades se limitam geralmente a configurar, ou a gerenciar ou a monitorar os respectivos SGBD NoSQL. Dessa forma, observou-se a necessidade de desenvolvimento de uma ferramenta compatível e adaptável às diversas soluções de SGBD NoSQL, contemplando funcionalidades para configuração, gerenciamento e monitoramento de SGBD NoSQL fragmentados e replicados. Neste capítulo, é apresentada a contextualização do trabalho realizado e é descrita a motivação que direcionou o desenvolvimento desta dissertação. Por fim, são apresentados os objetivos da pesquisa realizada e a estrutura dos próximos capítulos deste documento.
1.1 Contextualização
O crescimento vertiginoso de aplicações web que manipulam grandes volumes de dados, como Facebook, Google Search e Twitter, obrigam a distribuição desses dados em mais de um servidor para que se mantenha o nível de desempenho satisfatório durante essa manipulação. No entanto, para que ocorra essa distribuição, o uso de Sistemas de Gerenciamento de Bancos de Dados Relacionais (SGBDR) pode se tornar inviável, tendo em vista que esses não foram tradicionalmente concebidos para trabalharem de forma distribuída (CORBELLINI, MATEOS, et al., 2017).
1 Em uma tradução livre para o português quer dizer “não apenas SQL”. Foi utilizado pela primeira vez por Carlo
Strozzi no ano de 1998 para mencionar um SGBD que não oferecesse interface SQL, no entanto, hoje o termo é utilizado para referenciar soluções de SGBD que proveem alternativa ao modelo relacional (BRITO, 2010).
Uma alternativa para suprir esta limitação é o uso de SGBD NoSQL. Tais SGBD NoSQL têm como característica promover a escalabilidade dos dados por meio da utilização de vários servidores para distribuição desses, ocasionando a fragmentação dos dados e, permitindo dessa forma um processamento distribuído e um bom desempenho na manipulação de grandes quantidades de dados. Além disso, de forma a garantir a alta disponibilidade dos dados diante das falhas que possam eventualmente ocorrer nos servidores, os SGBD NoSQL apresentam uma outra característica que é o espelhamento dos dados armazenados em vários servidores, por meio da replicação (CORBELLINI, MATEOS, et al., 2017).
Mesmo sendo características nativas de SGBD NoSQL, a escalabilidade promovida por meio da fragmentação, e a disponibilidade promovida por meio da replicação dos dados entre os servidores pertencentes ao ambiente distribuído precisam ser, em alguns casos, configuradas de maneira explícita no respectivo SGBD NoSQL. No entanto, a configuração e o posterior gerenciamento desse ambiente podem se tornar dispendiosos, complexos e sujeito a erros à medida que o volume de dados aumenta, implicando na necessidade de inclusão de novos servidores ao ambiente distribuído.
Outra questão a ser observada é que, uma vez configurado e ativado o SGBD NoSQL fragmentado e replicado, os vários nós que o integram necessitam ser monitorados para munir os administradores do SGBD de informações que possam auxiliá-los na tomada de decisões gerenciais, como remover ou adicionar servidores no ambiente distribuído, ou adotar medidas corretivas quando falhas ocorrerem.
Em decorrência dessas questões, existe a necessidade de serem investigadas soluções de framework e ferramentas que possam auxiliar os administradores de SGBD nas tarefas de configuração, gerenciamento e monitoramento de SGBD NoSQL fragmentados e replicados.
1.2 Motivação
Os procedimentos para configuração, gerenciamento e monitoramento de SGBD NoSQL fragmentados e replicados, os quais englobam tarefas como: edição e criação de arquivos de configuração e pastas, inicialização e finalização de servidores, são realizados distintamente em cada solução de SGBD NoSQL disponível. Essa distinção é motivada pelo fato de que cada solução de SGBD NoSQL tem características próprias e peculiares umas das outras, como por exemplo a estrutura interna dos dados e a forma como os servidores (nós) integrantes da arquitetura distribuída (cluster) interagem entre si (CUNHA e PEREIRA, 2015).
A literatura reporta várias soluções de frameworks e ferramentas que auxiliam nas tarefas para configuração, gerenciamento e monitoramento de clusters de SGBD NoSQL, no entanto, são soluções que apresentam compatibilidade restrita a um número limitado de SGBD NoSQL, a depender da forma como os nós do cluster se comunicam entre si (topologia); da arquitetura de distribuição dos nós; e da solução de SGBD adotada (CRUZ, MAIA, et al., 2013; DATASTAX, 2017; FISHER, 2015; GIROUX, 2013; GITHUB, 2017; HECTOR, 2016; KONSTANTINOU, ANGELOU, et al., 2012; MANAGEENGINE, 2017; MONGODB, INC., 2017; REDIS LABS - HOME OF REDIS, 2017; BAAKIND, 2013).
A heterogeneidade existente entre os SGBD NoSQL dificulta a compatibilidade dessas soluções de framework e ferramentas para múltiplos soluções de SGBD NoSQL. Ao considerar essa dificuldade, torna-se necessário o desenvolvimento de uma ferramenta capaz de auxiliar os administradores de SGBD NoSQL nas tarefas de configuração, gerenciamento e monitoramento de SGBD NoSQL fragmentados e replicados, independentemente da solução de SGBD utilizada.
1.3 Objetivos
O objetivo geral do trabalho proposto é especificar, projetar e implementar uma ferramenta web e open source que auxilie nas tarefas de configuração, gerenciamento e monitoramento de SGBD NoSQL fragmentados e replicados, de modo a uniformizar os procedimentos de execução dessas tarefas, independentemente do modelo e solução de SGBD NoSQL adotada, minimizando a complexidade envolvida em cada uma dessas tarefas.
Para alcançar o objetivo geral, são definidos os seguintes objetivos específicos:
1. Especificar os requisitos, a arquitetura, os casos de uso, as funcionalidades, elaborar diagramas, projetar e implementar a ferramenta proposta, de forma que esta possa agregar o que há de positivo entre as ferramentas pesquisadas e, principalmente, sanar as fragilidades observadas nas soluções existentes;
2. Verificar, por meio da aplicação de testes de usabilidade a eficácia da ferramenta proposta nas tarefas de configuração, gerenciamento e monitoramento de SGBD NoSQL fragmentados e replicados; e
3. Averiguar o nível de satisfação dos usuários quanto a padronização dos procedimentos e minimização da complexidade dessas tarefas por meio do uso da ferramenta, além de
avaliar o grau de satisfação dos usuários quanto à possibilidade de utilização da ferramenta NoSQLClusterAdmin em soluções de SGBD NoSQL distintas.
1.4 Estrutura da Dissertação
O restante desta dissertação está organizado da seguinte maneira:
• No Capítulo 2, é descrita a fundamentação teórica dos principais temas envolvidos nesta dissertação, os quais abrangem conceitos e características dos sistemas de gerenciamento de bancos de dados não relacionais (SGBD NoSQL) e testes de usabilidade de software;
• No Capítulo 3, é apresentado um levantamento da literatura, cujo objetivo é revisar as principais ferramentas e framework que auxiliam a manipulação de SGBD NoSQL fragmentados e replicados;
• No Capítulo 4, é proposta a ferramenta NoSQLClusterAdmin, a qual auxilia os administradores de clusters de SGBD NoSQL nas tarefas de configuração, gerenciamento e monitoramento desses SGBD;
• No Capítulo 5, é apresentada a avaliação realizada com a ferramenta NoSQLClusterAdmin, iniciando com o planejamento do experimento, seguindo com os procedimentos executados, e finalizando com a análise dos dados coletados;
• No Capítulo 6, são apresentadas as conclusões obtidas com o desenvolvimento desta dissertação, as principais contribuições e indicações de trabalhos futuros.
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo, é apresentada a fundamentação teórica necessária ao entendimento dos objetivos deste trabalho. São explicados os principais conceitos e características relacionadas aos temas bancos de dados NoSQL e testes de usabilidade de software.
2.1 Bancos de Dados NoSQL
A manipulação de grandes volumes de dados sem comprometimento de desempenho é uma das maiores limitações apresentadas pelos SGBD relacionais quando configurados de forma distribuída em vários servidores (ACHARYA, PANDEY e RAUTARAY, 2013). Em contrapartida, existe uma forte tendência das aplicações web manipularem grandes quantidades de dados em ambientes distribuídos, sendo o Facebook2 e Twitter3, alguns exemplos bem conhecidos de tais aplicações (CORBELLINI, MATEOS, et al., 2017). Com propósito de suprir essa demanda, surgiram os SGBD NoSQL, que estão em plena ascensão de uso, principalmente pelo fato desses sistemas oferecerem um desempenho significativo na manipulação de grandes volumes de dados em ambientes distribuídos, quando comparados aos bancos de dados relacionais (BHOGAL e CHOKSI, 2015).
Os SGBD NoSQL podem ser utilizados nos casos em que os relacionais não apresentam desempenho satisfatória. O objetivo das soluções NoSQL não é substituir o modelo relacional em sua plenitude, mas apenas em situações em que seja necessária uma maior flexibilidade de estruturação do SGBD para obter um melhor desempenho na manipulação de grandes volumes de dados de forma distribuída (BRITO, 2010).
Os SGBD NoSQL não seguem uma padronização na organização e gerenciamento dos dados, cada um deles tem suas peculiaridades, como ausência completa ou quase que completa de um esquema de dados, ou esse esquema é flexível, podendo incluir ou remover atributos em sua estrutura a qualquer momento. No entanto, apesar de serem implementadas distintamente nas soluções de SGBD NoSQL, a escalabilidade e a disponibilidade são propriedades comuns entre essas, se tornando fatores preponderantes para garantia de níveis satisfatórios de desempenho dessas soluções na manipulação de grandes volumes de dados (SILBERSTEIN,
2 www.facebook.com 3 twitter.com
CHEN, et al., 2012). A seguir, são descritos os conceitos relacionados a essas propriedades aplicadas aos SGBD NoSQL.
2.1.1 Escalabilidade
A escalabilidade está relacionada à capacidade de um sistema computacional qualquer satisfazer um requisito de aumento da carga de trabalho pela adição de uma quantidade proporcional de recursos, enquanto continua a satisfazer toda demanda que lhe foi atribuída (PORTO, 2009).
Em se tratando de bancos de dados, quando o conjunto de dados a ser manipulado é maior do que a capacidade de recursos disponíveis (processamento, memória e armazenamento), surge a necessidade de criar uma condição para garantir o dimensionamento necessário para atendimento da demanda. Para isso, duas formas de escalabilidade podem ser adotadas (VIEIRA, 2012):
• A escalabilidade vertical, que consiste no acréscimo de mais recursos de hardware ao servidor que mantem o SGBD (processamento, memória e armazenamento); e
• A escalabilidade horizontal, que consiste na divisão e alocação dos dados de um SGBD entre vários servidores denominados “nós”, formando um agrupamento (cluster) de nós, que são alocados sob demanda.
A implementação da escalabilidade vertical é limitada, uma vez que o acréscimo de núcleos de processamento, memória e armazenamento está condicionado ao limite suportado pelo equipamento.
Em relação à escalabilidade horizontal, como está relacionada com a distribuição da demanda por diversos servidores, em teoria os recursos de processamento, memória e armazenamento se tornam ilimitados, uma vez que o acréscimo de recursos pode ser feito sob demanda e na quantidade necessária. Essa forma de escalabilidade pode se tornar mais barata em relação à forma vertical quando implementada no contexto de nuvem, haja visto que os custos só incidirão sob os recursos alocados para o dado momento, sendo variável ao longo do tempo (VIEIRA, 2012).
A forma de escalabilidade utilizada pelos SGBD NoSQL é a horizontal (CORBELLINI, MATEOS, et al., 2017), cujos dados são distribuídos entre os nós integrantes do respectivo cluster, nós estes, que podem ser somados ao cluster de acordo com a demanda apresentada. É
pertinente enfatizar que mesmo os dados estando distribuídos entre os nós do cluster, esses continuam pertencendo a um único banco de dados mantido pelo SGBD NoSQL, que por sua vez, pode manter vários bancos de dados.
Os SGBD NoSQL utilizam o método Sharding (fragmentação), para implementar a escalabilidade horizontal. Sharding, ou Database Sharding (banco de dados fragmentado), consiste na fragmentação e distribuição dos dados pertencentes a uma única base de dados em dois ou mais nós de um cluster, onde cada nó que integra o cluster é denominado shard (fragmento) e o conjunto de todos os nós integra um banco de dados (ELGHAMRAWY e HASSANIEN, 2017). Apesar dos dados estarem dispersos entre os nós, as transações realizadas em Databese Sharding são transparentes para o usuário, uma vez que a prerrogativa de gerenciamento dessa estrutura distribuída é do respectivo SGBD NoSQL.
2.1.2 Elasticidade
A elasticidade permite adicionar ou remover recursos, sem interrupções e em tempo de execução para lidar com a variação da carga. Um SGBD NoSQL é elástico se ele ajustar automaticamente a quantidade de nós para a necessidade de carga de trabalho atual; ou seja, adicionar novos nós ao cluster se a demanda aumentar e os recursos atuais forem insuficientes, ou remover nós do cluster se a demanda diminuir e os recursos atuais ficarem subutilizados (SOUSA e MACHADO, 2014).
A elasticidade é constantemente associada com a escalabilidade do SGBD NoSQL, mas existe uma sutil diferença entre elasticidade e escalabilidade. A elasticidade permite ao SGBD, também, reduzir a quantidade de nós quando a demanda diminui, enquanto a escalabilidade considera apenas situações de aumento da carga de trabalho (COUTINHO, SOUSA, et al., 2014).
Apesar da escalabilidade ser consenso entre os SGBD NoSQL disponíveis atualmente, o mesmo não ocorre em relação à elasticidade, sendo necessária para algumas soluções de SGBD a intervenção explícita do administrador do banco de dados na adição ou remoção de nós em um cluster (KONSTANTINOU, ANGELOU, et al., 2012).
2.1.3 Disponibilidade
A disponibilidade está associada à possibilidade de um usuário sempre conseguir ter acesso a um determinado dado a qualquer momento que precisar (PORTO, 2009). Em se
tratando de bancos de dados NoSQL, a disponibilidade é provida por meio do espelhamento dos dados em outros nós pertencentes ao cluster do SGBD NoSQL, garantindo, dessa forma, o acesso a esses dados mesmo quando houver falha no respectivo nó espelhado (WIESE, 2014). Cada nó espelhado passa a ser denominado réplica dentro do cluster.
Nos SGBD NoSQL a replicação pode ser implementada adotando uma das duas topologias descritas a seguir (LÓSCIO, OLIVEIRA e PONTES, 2011):
1. Master-Slave (Mestre-Escravo) – nesta implementação a escrita dos dados é feita em um nó, designado como mestre, sendo esta escrita espelhada posteriormente nos demais nós, denominados escravos, pelo próprio nó mestre. A leitura torna-se mais rápida, porém a capacidade de escrita torna-se um gargalo nesta forma de implementação, tendo em vista o número reduzido de nós que podem receber operações de escrita. Em geral, não é recomendada quando se tem um grande volume de dados a ser escrito de forma simultânea; ou 2. Multi-Master ou Pear to Pear (Ponto-a-Ponto) – nesta implementação, a escrita pode ser feita em qualquer nó, inclusive nas réplicas, a qual é posteriormente refletida nos demais, dessa forma, qualquer nó pode assumir o papel de mestre no momento em que um dado é escrito. Com essa implementação é possível diminuir o gargalo gerado pela escrita que ocorre na topologia mestre-escravo. Porém, a existência de diversos nós mestres pode causar um problema de conflito de dados e aumentar a probabilidade de ocorrerem inconsistências nos dados entre os nós, já que alterações simultâneas podem ocorrer em nós distintos mas sobre o mesmo dado.
Os SGBD NoSQL adotam uma das topologias de replicação e cabe ao administrador do SGBD definir a forma de configuração de suas réplicas com base nas características dos dados e aplicação. Na Seção 2.1.7 são explicadas as topologias adotadas em alguns SGBD NoSQL.
O nível de disponibilidade de um SGBD NoSQL está associado a quantidade de réplicas criadas de cada nó em um cluster. Existem dois pontos a serem observados com o aumento do nível de disponibilidade, um positivo e outro negativo. O ponto positivo é que quanto maior for o número de réplicas, menor é o tempo que se leva para consultar um determinado dado quando houver requisições simultâneas sobre ele, tendo em vista que esse dado pode ser consultado em qualquer uma dessas réplicas disponíveis. Por outro lado, a medida que réplicas são criadas,
pode aumentar proporcionalmente a ocorrência de inconsistências entre os dados replicados, tendo em vista a possibilidade de realização de consultas ao mesmo tempo em que esses dados são atualizados nas diversas réplicas, sendo esse, o ponto negativo. A questão da consistência é melhor detalhada na seção seguinte.
2.1.4 Teorema CAP
No ano de 2000, o professor Eric Brewer, da Universidade da Califórnia, Estados Unidos, fez uma afirmação que só foi confirmada dois anos depois, em 2002, por Steh Gilbert e Nancy Lynch, surgindo dessa forma o teorema de Brewer (GILBERT e LYNCH, 2002). De acordo com Brewer, em qualquer sistema computacional distribuído é desejável obter consistência, disponibilidade e tolerância ao particionamento. No entanto, na prática, essas propriedades são impossíveis de serem alcançadas ao mesmo tempo. Segundo o teorema, que ficou conhecido como Teorema CAP (Consistency, Availability end Partition Tolerance), em sistemas distribuídos só tem como ser garantida simultaneamente duas dessas propriedades, as quais são conceituadas a seguir (SOUSA, 2015):
• Consistency (Consistência), todos os nós de um sistema distribuído necessitam que a versão dos dados armazenados seja a mesma, independentemente do momento em que uma consulta a esses dados ocorra;
• Availability (Disponibilidade), ainda que um nó esteja inacessível, todos os usuários devem acessar pelo menos uma cópia dos dados sempre que necessitarem; e
• Partition Tolerance (Tolerância ao Particionamento), a implementação do sistema em mais de um servidor deve garantir a permanência dos dados e suas propriedades e características devem permanecer transparentes para o usuário.
Os SGBD NoSQL têm como prerrogativa, garantir a disponibilidade de dados e o alto desempenho das operações de leitura, escrita, exclusão e atualização dos dados, mesmo que para isso seja necessário abrir mão da consistência dos dados. Considerando tal prerrogativa, o Teorema CAP é aplicado nos SGBD NoSQL fragmentados e replicados, abrindo mão da consistência, sendo essa substituída pela “consistência eventual”, a qual ocorre somente quando não há operações de escrita sendo realizadas e assim os dados são atualizados em todas as réplicas.
Nesse contexto, em caso de falhas no cluster NoSQL, é garantido que todas as réplicas eventualmente atualizem seus dados entre si no momento que a falha for sanada e os nós
restabelecidos, passando o tempo que for necessário para que a sincronização desses dados ocorra entre eles. Sendo essa a justificativa para o desprezo da propriedade da consistência em detrimento da preservação da disponibilidade e tolerância ao particionamento (VIEIRA, 2012).
2.1.5 ACID Vs BASE
Uma das funções de um SGBD é o gerenciamento de transações. Uma transação representa o conjunto de operações executadas durante as atividades de escrita ou leitura realizadas no banco de dados (LÓSCIO, OLIVEIRA e PONTES, 2011). Para que uma transação em bancos de dados seja executada de forma segura, ela deve contemplar quatro propriedades, são elas: Atomicity, Consistency, Isolation e Durability, sendo assim representadas pela sigla ACID (CORBELLINI, MATEOS, et al., 2017). A seguir são descritos os conceitos relacionados:
• Atomicity (Atomicidade), caso ocorra alguma falha durante a execução de uma transação, os efeitos das operações executadas não são efetivados no banco de dados; • Consistency (Consistência), a integridade da base de dados é garantida no final da
transação. Todos os usuários enxergam o mesmo dado, mesmo quando ocorre atualizações simultâneas no banco;
• Isolation (Isolamento), se duas transações estão sendo executadas concorrentemente, seus efeitos devem ser isolados uma da outra; e
• Durability (Durabilidade), uma vez que uma transação ocorreu com sucesso, seu efeito não poderá mais ser desfeito, mesmo quando ocorrer falha.
Manter essas propriedades quando o ambiente é distribuído torna-se uma tarefa complexa, principalmente em relação à propriedade da consistência, haja vista a possibilidade eminente de fragmentação dos dados entre os diversos servidores integrantes daquele ambiente e a possibilidade de consulta a um dado desatualizado. Ainda que se consiga manter todas as propriedades ACID, o desempenho dos SGBD relacional em um ambiente distribuído pode ser comprometido, tendo em vista seu esforço interno na execução de outras operações em segundo plano na tentativa de preservar essas propriedades (CORBELLINI, MATEOS, et al., 2017). Sendo esta a justificativa para não recomendação de uso das soluções de SGBD Relacionais em ambiente distribuído.
Não sendo possível a preservação ACID em ambientes distribuídos, outras propriedades são estabelecidas, tais como: A Basic Availability (Disponibilidade Básica), Soft state (Estado
Leve) e a Eventual consistency (Consistência eventual), sendo representadas pela sigla BASE (GUEIDI, GHARSELLAOUI e AHMED, 2016). Disponibilidade básica, ou seja, o sistema permanece funcionando durante todo o tempo; em estado leve, o sistema não precisa ser consistente durante todo o tempo em que está funcionando; e eventualmente consistente, o sistema torna-se consistente no momento que for possível (PRITCHETT, 2008).
As propriedades BASE foram baseadas no Teorema CAP, sendo priorizada a disponibilidade dos dados em decorrência do particionamento, mesmo que seja preciso abrir mão da consistência desses dados, ocorrendo nesse caso a consistência eventual, na qual o sistema garante que, se nenhuma nova atualização for realizada sobre o objeto, eventualmente todos os acessos a esse objeto retornarão o último valor atualizado (BRITO, 2010).
É consenso a adoção das propriedades BASE como parâmetro para projetar, conceber e evoluir os SGBD NoSQL, tendo em vista os níveis de escalabilidade e disponibilidade pretendidos. A seguir serão apresentados os principais modelos de SGBD NoSQL e suas características.
2.1.6 Modelos de Banco de Dados NoSQL
Os bancos de dados NoSQL possuem como características comuns a escalabilidade, disponibilidade e esquema de dados flexível, como já foi evidenciado. Porém, eles se diferenciam quanto à orientação do modelo de dados utilizado, tendo em vista a forma como os dados são representados, estruturados e organizados internamente (CORBELLINI, MATEOS, et al., 2017). Nesta Seção são apresentados os principais modelos de dados NoSQL, enfatizando suas peculiaridades.
• Modelo Orientado a Chave-valor (key-value)
Esse modelo organiza os dados como uma tabela hash, sendo composta por um conjunto de chaves, na qual cada chave é vinculada a um único valor. A Figura 1, apresenta exemplo de um banco de dados que armazena informações de configuração de um aparelho celular no formato de chave-valor. A chave está representada pelos campos modelo e capacidade, enquanto que o valor representa a instância para o campo correspondente, sendo os dados acessados diretamente pela chave (LÓSCIO, OLIVEIRA e PONTES, 2011).
Figura 1 – Exemplo do modelo orientado a chave-valor
Fonte: Elaborada pelo Autor (2017)
A desvantagem do modelo chave-valor é que não permite a recuperação de objetos por meio de consultas complexas, utilizando por exemplo junções. Como exemplo de sistemas gerenciamento de bancos de dados NoSQL que seguem esse modelo podem ser citados: Riak4,
Redis5, LevelDB6, MemcacheDB7.
• Modelo Orientado a Colunas
Os dados são indexados por linha, coluna e timestamp. As linhas e colunas são identificadas por chaves e o timestamp permite a diferenciação de múltiplas versões de um mesmo dado. Outro conceito presente ao modelo é o de família de colunas (column family), o qual é associado a grupos de colunas que mantem o mesmo tipo de dado (SOUZA, PRADO, et al., 2014)
A Figura 2 apresenta um exemplo que modela as características de carros, onde versao e cilindrada são colunas pertencentes à família de colunas denominada motor. Seguindo a mesma lógica, as colunas bancos e pintura pertencem à família cor. Pode ser observado que para a linha 001, tem diferentes cores de bancos e pintura, existindo um timestamp para cada um. O modelo orientado a colunas só permite recuperar a linha inteira com todas as informações relacionadas, ou seja, mesmo que o interesse seja apenas na coluna cilindrada da linha 001, todas as colunas são retornadas quando esta linha for consultada.
Figura 2 – Exemplo do modelo orientado a colunas
Fonte: Elaborada pelo Autor (2017)
4 http://basho.com/ 5 redis.io
6 http://leveldb.org/ 7 http://memcachedb.org/
Entre os SGBD NoSQL que seguem o modelo orientado a colunas, podem ser citados: Hbase8, Cassandra9, Hypertable10.
• Modelo Orientado a Documentos
Os dados são armazenados como coleções de documentos. Um documento é um objeto com um identificador único e um conjunto de campos, sejam valores inteiros, conjunto de caracteres ou até mesmo outros documentos (DIANA e GEROSA, 2010).
Outra característica importante é que esse modelo tem uma estrutura flexível permitindo que a estrutura do documento seja alterada, adicionando novos campos sem comprometer o banco de dados
. A Figura 3, apresenta um exemplo de documento representando um veículo, onde os campos definidos são: Fabricante, Modelo e Ano. Posteriormente é possível atualizar a estrutura do documento adicionando mais um campo, como por exemplo TipoCombustivel, sem qualquer comprometimento.
Figura 3 – Exemplo do modelo orientado a documentos
Fonte: Fonte: Elaborada pelo Autor (2017)
Como principais soluções que adotam o modelo orientado a documentos destacam-se: MongoDB11, CouchDB12, RavenDB.
• Modelo Orientado a Grafos
Este modelo é constituído por três componentes: os nós (que são os vértices do grafo), os relacionamentos (que são as arestas) e as propriedades (ou atributos) dos nós com seus
8 hbase.apache.org 9 http://cassandra.apache.org/ 10 hypertable.com 11 mongodb.com 12 http://couchdb.apache.org/
relacionamentos (SOUSA, 2015). A Figura 4, ilustra um exemplo de grafo que representa os dados de uma aplicação que deseja manter informações relativas a locais que as pessoas trabalharam ou estudaram.
Figura 4 – Exemplo do modelo orientado a grafos
Fonte: Adaptado de LÓSCIO, OLIVEIRA e PONTES (2011)
A vantagem de utilização do modelo orientado a grafos fica bastante clara quando são exigidas consultas complexas pelo usuário (LÓSCIO, OLIVEIRA e PONTES, 2011). Exemplos de bancos de dados orientados a grafos: Neo4J13, InfoGrid14, HyperGraphDB15.
Um modelo não deve ser considerado melhor ou pior que o outro, uma vez que cada tipo de modelo pode apresentar melhor desempenho para determinadas aplicações (SADALAGE e FOWLER, 2013). Por exemplo, para manipulação de dados estatísticos pode ser utilizado um SGBD orientado a chave-valor ou documentos, como Redis e MongoDB, respectivamente. Aplicativos que necessitam de alta disponibilidade, onde a redução do índice de inatividade é fundamental, podem utilizar um SGBD orientado a colunas, como o Cassandra. Aplicações que exigem alto desempenho em consultas com muitas junções, podem adotar um SGBD orientado a grafos, como o Neo4j. A importância de conhecer cada solução e adotar aquela que for mais adequada, poderá contribuir para a diminuição do custo de criação
13 neo4j.com 14 http://infogrid.org 15 http://hypergraphdb.org/
do banco de dados, bem como para o aumento da eficiência no processamento dos dados (LÓSCIO, OLIVEIRA e PONTES, 2011).
2.1.7 Topologias das Soluções NoSQL
Quando se pretende implementar a escalabilidade, por meio da técnica de sharding; a disponibilidade, por meio da replicação; e a elasticidade, além do modelo, deve ser observada a forma como a solução de SGBD NoSQL projeta sua topologia de arquitetura distribuída, para que o administrador de banco de dados possa optar por aquela que venha a oferecer melhores benefícios de desempenho, tendo como referência o tipo de dados que deseja manipular.
A topologia compreende a definição do papel e comportamento de cada nó integrante do cluster NoSQL fragmentado e replicado. Com a prerrogativa de evidenciar essa distinção existente entre os SGBD NoSQL, a seguir serão descritas as topologias utilizadas pelas soluções MongoDB e Cassandra. Essas duas soluções de SGBD foram escolhidas tendo em vista que uma adota como topologia de replicação a mestre-escravo e a outra a ponto-a-ponto, possibilitando evidenciar a distinção de comportamento que existe entre elas duas.
• Topologia MongoDB
O SGBD MongoDB, deve ser configurado manualmente para funcionar como cluster. A topologia de fragmentação e replicação do MongoDB, ilustrada na Figura 5, é constituída pelos seguintes componentes (MONGODB, INC., 2017):
1. Aplicação, é o software que encaminha as requisições ao MongoDB e recebe as respostas dessas requisições;
2. shards (fragmentos), cada shard, denominado a nível de implementação “mongod”, contém uma parte dos dados mantidos pelo SGBD configurado; 3. réplicas, cada réplica está associada a um shard, a qual mantém uma cópia dos
dados do respectivo shard ao qual foi vinculado. Os dados são escritos sempre no shard e copiados para as respectivas réplicas. A leitura pode ser realizada em qualquer dos nós disponíveis, seja shard ou réplicas. Caso o shard fique indisponível, um dos servidores de configuração assume o papel de “árbitro” e nomeia uma das respectivas réplicas para assumir o papel de shard, que passará a ter essa atribuição mesmo em caso de retorno do nó que ocupava o status de shard. Com esse comportamento, fica evidente que o MongoDB implementa o
tipo de replicação mestre-escravo, a qual proporciona um melhor nível de consistência dos dados, em comparação com o tipo ponto a ponto;
4. roteadores, cada roteador, denominado no nível de implementação “mongos”, tem a função de encaminhar as requisições da aplicação, sejam de escrita ou leitura, para os shards. Todas as requisições são retornadas para o roteador requisitante, que encaminha para a aplicação. Quanto maior o número de instâncias de mongos, melhor o desempenho no atendimento de requisições simultâneas. Todas as requisições devem passar pelo roteador, melhorando, dessa forma, a consistência dos dados. Por outro lado, quanto maior o número de mongos, pior será o nível de consistência dos dados, tendo em vista que escritas poderão ocorrer de forma simultânea, aumentando esse risco;
5. servidores de configuração, cada servidor, que são shards que foram promovidos a servidores de configuração, tem como função armazenar os metadados e configurações da topologia do cluster. O roteador deve consultar um dos servidores de configuração que indica em qual dos shards será realizada a transação. Um shard pode ser promovido a servidor de configuração e vice-versa, no entanto, não poderá assumir o mesmo papel simultaneamente. A presença deste ator na topologia do MongoDB viabiliza a elasticidade, uma vez que os nós podem ser promovidos ou removidos por este ator.
Figura 5 – Topologia MongoDB – Fragmentado (Sharding) e replicado
• Topologia Cassandra
O SGBD Cassandra, nativamente, tem sua topologia configurada como cluster. Os nós disponíveis no cluster têm a topologia distribuída em forma de anel, conforme está apresentado na Figura 6 (DATASTAX, 2017).
A configuração padrão estabelece que todos os nós do cluster devem manter uma cópia de cada dado escrito, por tanto, todos os nós são réplicas, verificado na Figura 6A. Outra característica observada é que não existe hierarquia entre os nós, de forma que um dado pode ser lido ou escrito em qualquer um deles, adotando dessa forma o tipo de replicação ponto-a-ponto, o qual apresenta um nível de inconsistência maior em relação à replicação mestre-escravo. Outro ponto a observar é que um dado pode ser gravado em qualquer dos nós, o qual é replicado para os demais no sentido horário (DATASTAX, 2017):
O Cassandra também pode ser configurado em modo sharding, conforme apresenta a Figura 6B. Nesse modo, os dados são fragmentados e distribuídos entre as réplicas pertencentes a cada fragmento, permanecendo as mesmas regras de replicação (DATASTAX, 2017).
Cada nó troca, frequentemente, informações do seu estado e do estado dos outros nós pertencentes ao cluster, utilizando o protocolo denominado “gossip”. Em decorrência desse protocolo o Cassandra implementa a propriedade da elasticidade.
Figura 6 – Topologia Cassandra – A) replicação sem fragmentação B) fragmentação com replicação
2.2 Testes de Usabilidade de Software
De acordo com Barbosa e Silva (2010), teste de usabilidade é um tipo de experimento que visa avaliar a facilidade de uso de um software a partir da experiência vivenciada pelos usuários-alvo do referido software. Essa avaliação pode ser de caráter exploratório, tendo como objetivo testar conceitos e mensurar o potencial ou a promessa do produto; como também pode ser de caráter avaliativo, cujo objetivo é testar funcionalidades durante a fase de implementação; de caráter comparativo, objetivando compará-lo com outro software; ou de caráter validativo, cujo objetivo é certificar que as características do produto em desenvolvimento cumpre certas normas e valores de referência estabelecidos ao final do processo de desenvolvimento (GOODMAN, KUNIAVSKY e MOED, 2012).
Na realização de um experimento normalmente não se utiliza apenas um método, uma técnica ou instrumento para alcançar os objetivos definidos, e sim combinações de duas ou mais delas, como aplicação de questionários ou entrevistas (MARCONI e LAKATOS, 2015). No entanto, a definição dos métodos e técnicas a serem utilizadas devem ser baseadas nos objetivos e metas a serem alcançadas com a realização do experimento (BARBOSA e SILVA, 2010).
Além disso, os participantes do experimento devem ser informados sobre os objetivos do teste, as condições nas quais serão realizados e como serão divulgados os dados coletados; bem como concordarem com as condições impostas. Isso deve ser feito por meio de um termo de consentimento. Os participantes também devem conhecer os roteiros com todos os passos que deverão ser seguidos durante a realização dos testes e preencher um questionário pré-teste, aplicado antes da realização do teste para mapeamento do perfil dos indivíduos participantes e, ao final, um novo questionário, denominado pós-teste, para aferição das percepções dos indivíduos sobre o software testado (BARBOSA e SILVA, 2010; GOODMAN, KUNIAVSKY e MOED, 2012).
Um instrumento que pode ser aplicado nos testes para coleta de dados é o questionário QUIS16 (Questionnaire for User Interaction Satisfaction ou questionário para a satisfação da interação do usuário). Esse questionário foi desenvolvido por uma equipe multidisciplinar de pesquisadores no Laboratório de Interação Humano-Computador (HCIL) da Universidade de Maryland no College Park. O QUIS tem como objetivo avaliar um software qualquer a partir
da coleta de dados que possam expressar a satisfação dos usuários que interagiram com o mesmo. As perguntas dos questionários são agrupadas por dimensões, cada dimensão avalia um determinado aspecto do usuário ou software. Ao todo são dez dimensões, as duas primeiras estão relacionadas, respectivamente, à experiência do usuário com o uso do software e experiência anterior com computadores. As dimensões seguintes compreendem perguntas que avaliam aspectos do software: As impressões gerais dos usuários; telas; termos utilizados e informações disponíveis, como uso adequado de palavras e expressões; facilidade de aprendizagem do software; capacidade de respostas às requisições enviadas pelo usuário; manuais técnicos e ajuda on-line; tutoriais disponíveis on-line; e aspectos de multimídia, como qualidade de figuras, brilho e cores utilizadas (UNIVERSITY OF MARYLAND, 2017).
Nas duas primeiras dimensões as respostas devem ser escolhidas a partir das opções objetivas disponíveis. Nas oito dimensões restantes, as respostas são colocadas de forma escalar, numeradas de um a nove, onde um representa uma percepção péssima do usuário e nove representa uma percepção ótima sobre o respectivo item questionado. Ao final de cada dimensão, optativamente, o usuário pode expressar de forma escrita e subjetiva sua opinião sobre a respectiva dimensão. O questionário QUIS é para ser utilizado como referência e pode ser adaptado conforme os objetivos definidos para serem alcançados pelo teste de usabilidade do software em questão (UNIVERSITY OF MARYLAND, 2017).
Um modelo de escala que pode ser utilizada como alternativa em um questionário para avaliação da satisfação do usuário é o modelo escalar de Likert. O modelo foi desenvolvido por Renis Likert (1932), nesta escala os respondentes se posicionam de acordo com uma medida de concordância atribuída à pergunta. A escala original tinha como proposta ser aplicada em cinco pontos, variando de discordância total até concordância total. No entanto, os pesquisadores podem adotar variações na pontuação, como 7 ou 9 pontos (SILVA JR. e COSTA, 2014).
Um experimento pode apresentar tanto resultados quantitativos, cujo valores resultantes são expressados em números; quanto qualitativos, cujo valores resultantes são baseados na presença ou ausência de alguma característica ou qualidade (MARCONI e LAKATOS, 2015). Na Seção 2.2.1 são descritas as etapas de um experimento por meio da aplicação de testes de usabilidade.
2.2.1 Etapas
A realização de um experimento, por meio da aplicação de testes de usabilidade, envolve as seguintes etapas: definição dos objetivos e metas que se pretende atingir com a aplicação do teste; definição do universo e da amostra populacional alvo da pesquisa; definição da infraestrutura de equipamentos, programas e documentos necessários; definição dos procedimentos para realização dos testes; aplicação dos testes; coleta e análise dos dados (BARBOSA e SILVA, 2010; MARCONI e LAKATOS, 2015). A seguir serão descritas as características de cada uma das etapas.
• Definição dos objetivos e metas da avaliação, determinam quais critérios de usabilidade devem ser medidos, como por exemplo as telas de uma ferramenta, e norteiam a definição dos demais passos a serem planejados e executados (BARBOSA e SILVA, 2010);
• Definição do universo e da amostra populacional alvo da pesquisa, segundo Marconi e Lakatos (2015), o universo populacional é um conjunto de seres animados ou inanimados que apresentam pelo menos uma característica em comum, sendo essa característica fator determinante para escolha do universo populacional. Já a amostra é uma parcela convenientemente selecionada do universo populacional, podendo ser probabilística (aleatória), ou não probabilística. A proporção de indivíduos a serem selecionados para compor uma amostra que represente o universo populacional depende da possibilidade de definir o quantitativo de indivíduos desse universo. Sendo assim, quando é possível definir a proporção de indivíduos desse universo, diz-se que a população é conhecida, caso contrário é desconhecida. Existem métodos para cálculo da amostra ideal para qualquer uma das duas situações. Em muitos casos não é possível estimar o universo populacional, para esses casos é necessário determinar o tamanho da amostra ideal. Para realização deste cálculo pode ser utilizado a fórmula do cálculo da amostra para uma população desconhecida exibida na Equação 1 (SILVA, SILVA, et al., 2011):
Equação 1– Fórmula para cálculo do tamanho da amostra de uma população desconhecida
Fonte: SILVA, SILVA, et al. (2011)
2 ^ ^ 2 2 e q p z n
Onde:
n tamanho da amostra
Representa o nível de certeza quanto à confiabilidade dos resultados . O resultado obtido por meio desse cálculo é a coordenada para consulta junto a tabela de distribuição normal “Tabela Z”, que deverá ser substituído na fórmula. A referida tabela pode ser consultada no Anexo A.
e erro padrão de estimativa.
^
p Proporção dos indivíduos que satisfazem a propriedade, na amostra.
^
q Proporção dos indivíduos que não satisfazem a propriedade, na amostra.
• Definição da infraestrutura de equipamentos, programas e documentos necessários, determina e organiza os equipamentos, software e documentos que serão utilizados em cada etapa de realização dos testes;
• Definição dos procedimentos para realização dos testes, nesta etapa são planejadas a forma de divulgação e a seleção dos indivíduos que participarão dos testes, bem como a sequência de ações a serem seguidas antes, durante e após a realização dos testes;
• Aplicação dos testes, execução dos testes, seguindo os procedimentos estabelecidos na etapa de definição dos procedimentos para realização dos testes, com a amostra de indivíduos selecionada; e
• Coleta e análise dos dados, a medida em que os testes são realizados, os dados são coletados para serem analisados estatisticamente ao final da execução de todo o experimento.
2.3 Considerações Finais do Capítulo
Neste capítulo foi apresentada a fundamentação teórica necessária ao entendimento desta dissertação. Assim, foram abordados conceitos relacionados a testes de usabilidade de software, bem como SGBD NoSQL e suas principais características como a escalabilidade e a disponibilidade. Com base nas características apresentadas sobre os SGBD NoSQL, é possível concluir que a distinções de topologia existente entre as soluções de SGBD NoSQL aumentam a complexidade para o desenvolvimento de uma ferramenta capaz de auxiliar na configuração, gerenciamento e monitoramento de múltiplas soluções de SGBD NoSQL, justificando a escassez de soluções de framework e ferramentas dessa natureza, como pode ser observado nos estudos apresentados no Capítulo 3 desta dissertação, o qual trata do estado da arte.
2
z
2
No capítulo seguinte, é apresentado o resultado de um levantamento bibliográfico descrevendo framework e ferramentas que auxiliam nas tarefas de configuração, gerenciamento e monitoramento de SGBD NoSQL fragmentados e replicados, bem como outras que realizam o provisionamento dinâmico de clusters NoSQL por meio da elasticidade. A partir desse levantamento, é feita uma análise sobre as funcionalidades disponíveis em cada uma, bem como, a abrangência das mesmas em relação à compatibilidade de uso para os vários SGBD NoSQL existentes.
