ESTUDO SOBRE A TECNOLOGIA DE BANCO DE DADOS NoSQL

Transcrição

1 ESTUDO SOBRE A TECNOLOGIA DE BANCO DE DADOS NoSQL Autores: Nicolas Ignácio RYBERG 1,2 ;; Angelo Augusto FROZZA 3 Identificação autores: 1 Bolsista PIBIC-EM/CNPq;; 2 Aluno do curso Técnico em Informática do IFC-Camboriú;; 3 Professor do IFC-Camboriú. Introdução Durante décadas, foram utilizadas bases de dados relacionais para armazenar dados estruturados, organizados em grupos denominados de tabelas. Nessas tabelas, os dados são agrupados por linhas e colunas. Porém, com o avanço da Internet, tem-se lidado com quantidades de dados nunca antes trabalhadas (Big Data), além destes estarem cada vez menos estruturados. São exemplos, os dados contidos em sites como Facebook, Google e Amazon. Desta forma, estes sites tiveram que desenvolver meios eficientes e baratos para processar seus dados. Uma solução encontrada foi a escalabilidade horizontal, que significa aumentar o número de máquinas, ao invés de aumentar o poder de processamento e armazenamento de uma só máquina (escalabilidade vertical). Os bancos de dados NoSQL chegaram como outra solução para este problema, já que permitem o gerenciamento em larga escala de dados distribuídos. Entre suas características, destacam-se: não-relacional, distribuído, de código aberto, escalável horizontalmente, ausência de esquema ou esquema flexível, suporte à replicação nativo e acesso via APIs simples [NOSQL 2010]. Material e Métodos Este projeto tem caráter bibliográfico e exploratório, pelo qual se propõe fazer um estudo aprofundado sobre essa a nova tecnologia de banco de dados, chamada NoSQL. O objetivo é fornecer o conteúdo pesquisado à comunidade do Campus Camboriú através de materiais de apoio, bem como, identificar linhas de pesquisa ligadas aos bancos de dados NoSQL. Conforme Malheiros (2010), uma pesquisa bibliográfica busca pelo conhecimento disponível na área, possibilitando que o pesquisador conheça as teorias até então produzidas, analisando-as e avaliando sua contribuição para compreender ou explicar o seu problema objeto de investigação. Para Gil (2008), a pesquisa exploratória visa familiarizar sobre um assunto ainda pouco conhecido e pouco explorado. Para atingir os objetivos propostos, primeiro foram feitas pesquisas para entender os conceitos relacionados aos BDs NoSQL, seus diferentes paradigmas e que dados são tratados em cada paradigma. Identificar em que caso um BD NoSQL é melhor que um BD relacional, apresentar os principais produtos (nomes) de banco de dados NoSQL existentes, classificando-os de acordo com o paradigma suportado e apresentar as características de cada BD NoSQL identificado durante a pesquisa. Como trabalhos futuros, serão escolhidos dois ou três produtos para estudar de forma prática e desenvolver materiais de apoio à aprendizagem dos mesmos. Entre os produtos a serem disponibilizados ao final desta pesquisa, destaca-se a criação de uma página web para registrar todo o conhecimento adquirido, bem como, publicar os materiais produzidos no decorrer da pesquisa.

2 Resultados e discussão Através da pesquisa bibliográfica, foram identificadas as cinco características principais do modelo NoSQL: Escalabilidade horizontal (Scale Out): A escalabilidade horizontal tende a ser a opção mais viável para o problema da escalabilidade. Porém, requer que diversos processos de uma única tarefa sejam criados e distribuídos. Isto torna inviável a utilização de um banco de dados relacional, uma vez que todos estes processos conectados geram grande concorrência, aumentando consequentemente o tempo de acesso às tabelas desejadas. A escalabilidade horizontal somente é permitida nos BDs NoSQL por causa da ausência de bloqueios. Uma alternativa muito usada para alcançar esta escalabilidade é o Sharding, que consiste em dividir os dados em várias tabelas, que são armazenadas ao longo de múltiplos nós de uma rede. A aplicação desta técnica traz o grande problema de quebrar a lógica de relacionamentos, que é o grande forte dos bancos relacionais. Neste caso, as aplicações têm que resolver a complexidade gerada pela partição de informações, como, por exemplo, a execução de joins e outros comandos (LÓSCIO, RODRIGUES e PONTES, 2011). Ausência de esquema ou esquema flexível: O esquema flexível define a estrutura dos dados modelados ou a ausência deste, facilita a escalabilidade, além de aumentar a disponibilidade. Porém, não há garantia da integridade dos dados (LÓSCIO, RODRIGUES e PONTES, 2011). Suporte nativo à replicação: O suporte nativo à replicação diminui o tempo gasto para recuperar informações, além da replicação ser um dos meios de prover escalabilidade. Existem duas abordagens principais para replicação: Master-Slave (Mestre-Escravo) e Multi-Master (LÓSCIO, RODRIGUES e PONTES, 2011). API simples para acesso aos dados: Para atingir o objetivo da solução NoSQL (alta disponibilidade e escalabilidade), APIs foram desenvolvidas para facilitar o acesso aos dados, de modo que qualquer aplicação possa utilizar o banco de forma rápida e eficiente (LÓSCIO, RODRIGUES e PONTES, 2011). Consistência eventual: O teorema CAP (Consistency, Availability e Partition tolerence) diz que, em determinado momento, apenas são garantidas duas das três propriedades: Consistência, Disponibilidade ou Tolerância à partição. No contexto da Web, por exemplo, geralmente são privilegiadas a disponibilidade e a tolerância à partição (LÓSCIO, RODRIGUES e PONTES, 2011). Portanto, a consistência dos dados nem sempre é mantida entre os diversos pontos de uma distribuição. Paradigmas de Bancos de Dados NoSQL A seguir são descritos os paradigmas de BD NoSQL e o Quadro 1 relaciona cada paradigma e os principais BD NoSQL disponíveis no mercado. Orientado a documentos (BDOD)

3 Os documentos de BDODs são coleções de atributos e valores, nas quais um atributo pode ser multivalorado (DIANA e GEROSA, 2012) (Figura 1). Segundo Anderson et al. (2009), BDODs utilizam o conceito de dados e documentos autocontidos e autodescritivos. Logo, o próprio documento já implica em como ele está estruturado e deve ser apresentado. O que faz com que estes bancos de dados não precisem de uma estrutura comum, tornando-os altamente eficientes para o armazenamento de dados semiestruturados. Este paradigma de organização dos dados usa um formato que permite que um documento seja embutido em outro, como o JSON, que é um padrão leve de intercambio de dados, baseado em especificações do JavaScript. Ele visa facilitar a leitura e a escrita, sendo de fácil interpretação para as máquinas. Embutir um documento em outro, geralmente leva à duplicação de dados que, eventualmente, gera inconsistência, causada por anomalias de atualização e deleção. Porém, como em todos os BDs NoSQL, esta duplicação não é um problema, mas sim, facilita a leitura, pois a quantidade de nós consultados é muito menor. Os principais bancos de dados nessa categoria são o MongoDB e o CouchDB. Armazém Chave-Valor (key-value) FIGURA 1 - Exemplo de documento. O modelo Chave-Valor é considerado bastante simples (Figura 2) e permite a visualização do banco de dados em uma grande tabela hash (LÓSCIO, RODRIGUES e PONTES, 2011). O banco tem várias chaves, para cada qual é atribuída apenas um valor, este podendo ser uma string ou um binário. Por esta simplicidade, permite que dados sejam acessados rapidamente pela chave, através de consultas simples como get() e set(), que permitem retornar e capturar valores, respectivamente. Uma desvantagem deste modelo, é que não permite recuperar objetos através de consultas mais complexas. Os principais bancos de dados nessa categoria são o Dynamo, RYAK, Redis, MemCacheDB e o GeniaDB. Orientado a colunas FIGURA 2 - Exemplo de uma hash. Em um BD relacional, os dados de um registro são armazenados contiguamente no disco. Por exemplo, caso se queira guardar id, nome e telefone de usuários, em um sistema de agenda telefônica, os registros seriam: id1, nome1, telefone1;; id2, nome2, telefone2. Essa estrutura torna a escrita muito rápida, já que todos os dados de um registro são colocados em apenas um bloco do disco. Essa

4 estrutura também é eficiente quando deseja-se ler registros por inteiro. Porém, caso queira-se ler poucas colunas de muitos registros, este modelo torna-se lento, já que vários blocos do disco têm que ser acessados. Para os casos em que se pretende otimizar a leitura de um banco, a orientação a colunas tende a ser mais interessante. Seguindo a ideia do exemplo anterior, fica: id1, id2;; nome1, nome2;; telefone1, telefone2. Uma das dificuldades deste modelo é a escrita de um novo registro. Assim, em um primeiro momento, os bancos tradicionais são mais adequados a processamento de transações on-line (OLTP), enquanto os bancos de dados de colunas são mais interessantes para processamento analítico on-line (OLAP) (DIANA e GEROSA, 2012). Os principais bancos de dados nessa categoria são o Cassandra, HBase e Hypertable. Orientado a grafos O banco de dados orientado a grafos (Figura 3) está diretamente relacionado a um modelo de dados já existente, o modelo de grafos. Este possui nós relacionados por arestas, em que cada um destes elementos possui um atributo. A ideia deste modelo é representar os dados e o esquema como grafos dirigidos, ou estruturas que generalizam a noção dos grafos. Assim, cada operação sobre os dados são transformações no grafo e fazem uso de conceitos de grafos, como caminhos, vizinhos e sub-grafos. Como exemplo de uso tem-se o Twitter, que tem relações entre pessoas (como seguir), ou entre pessoas e tweets (como retweetar, favoritar, entre outros). O modelo de grafos torna-se interessante quando não apenas o atributo em si é importante, mas, também, deve-se considerar as relações deste. Alguns bancos de dados nessa categoria são o Neo4j, InfoGrid, AllegroGraph e Oracle Spatial. QUADRO 1 - Paradigmas X BD NoSQL PARADIGMA Orientado a Documentos PRODUTO Armazéns Chave-Valor Orientado a Colunas Orientado a Grafos

5 Considerações finais FIGURA 3 - Exemplo de modelo de grafo. Várias empresas que trabalham com grandes quantidades de dados compartilhados em tempo real já aderiram aos BDs NoSQL, como Facebook, Google e Amazon. Porém, é importante ressaltar que a solução NoSQL não veio com intuito de substituir o modelo relacional e, sim, ser uma opção em casos que se necessite alta disponibilidade, escalabilidade e um sistema flexível e mais eficiente, o que não seria possível com o modelo relacional. Logo, conclui-se que existem diversas situações em que cada modelo se destaca, tendo seus pós e contras. Referências bibliográficas DIANA, M. de;; GEROSA, M. A. NOSQL na Web 2.0: Um estudo comparativo de bancos não-relacionais para armazenamento de dados web 2.0. In: Workshop de Teses e Dissertações em BD - WTDB, 9., 2010, Belo Horizonte. Anais... Belo Horizonte: SBC, LI, Y.;; MANOHARAN, S. A performance comparison of SQL and NoSQL databases. In: IEEE Pacific Rim Conference on Communications, Computers and Signal Processing - PACRIM, 14., 2013, Victoria, B.C., Canadá. Proceedings... IEEE, LÓSCIO, B. F.;; OLIVEIRA, H. R. de;; PONTES, J. C. de S. NoSQL no desenvolvimento de aplicações web colaborativas. In: Simpósio Brasileiro de Sistemas Colaborativos SBSC, 8., 2011, Paraty (RJ). Anais... Paraty: SBC, MARTINS, A.;; SOUZA, L. de. NoSQL Orientado a documento. Disponível em: < Acesso em: 14 set VIEIRA, M. R. et al. Bancos de Dados NoSQL: conceitos, ferramentas, linguagens e estudos de casos no contexto de Big Data. In: Simpósio Brasileiro de Bancos de Dados, 27., 2012, São Paulo. Anais... São Paulo: SBC, 2012.