Repositório de Dados Relacional ou NoSQL?

Durante os últimos anos, o formato de armazenamento de informações manteve-se estável e aderente às necessidades expostas pela sociedade. Neste período ocorreram evoluções tecnológicas, porém, conforme apresentado na Figura 1, o ritmo destas evoluções não refletiu as necessidades de um ambiente altamente conectado formado por uma grande e crescente massa de informação.

O acesso à internet e aos seus recursos relacionados, como sistemas de software destinados ao mercado corporativo ou de entretenimento, fizeram com que o volume de informações se multiplicasse de forma exponencial, trazendo consigo os benefícios associados com a inovação tecnológica. Por outro lado surgiram os imprevistos, representados por situações não vivenciadas anteriormente, interpretadas como falhas sistêmicas e responsáveis pela motivação de novas soluções.

A necessidade de se manter a continuidade funcional e segura de um sistema de software é vital para o bom andamento dos negócios, e em casos de problemas é fundamental ter sempre um bom plano de ação. Este deve ser elaborado e aplicado para que o cenário ou resultado desejado, composto por um conjunto de atributos de qualidade, possa ser reestabelecido e volte a operar normalmente.

Os atributos de qualidade de um sistema de software podem ser classificados e apresentados por meio de diversas categorias, que podem estar relacionadas com segurança, performance, facilidade de manutenção, usabilidade, tolerância a falhas, entre outros itens. A boa qualidade de um sistema de software é reconhecida como estímulo para evolução do mesmo ou elaboração de um novo produto.

Para saber mais sobre atributos de qualidade e requisitos não funcionais de um sistema de software, recomenda-se uma breve consulta à norma ISO-9126.

Portanto, o tema deste artigo está relacionado com performance e escalabilidade, tendo como proposta apresentar um novo formato de armazenamento de dados não relacional, utilizando como solução a base de dados Neo4j. Será apresentado ainda um caso prático que estabelece um comparativo entre as duas abordagens, relacional e NoSQL.

Bases de Dados Relacionais

Após realizar o levantamento e o desenvolvimento dos requisitos de um sistema de software, caminhamos para a etapa de análise e design, onde serão concebidos os modelos do sistema, definindo sua estrutura e seu respectivo comportamento.

O comportamento de um software é representado por suas funções, enquanto que sua estrutura é representada pelo conjunto de informações que o mesmo vai receber, persistir e manipular. Para realizar a persistência, no mundo relacional, é necessário planejar e projetar um modelo normalizado e consistente, capaz de armazenar tais informações.

Ao planejar e projetar um modelo normalizado, o Modelo de Entidades e Relacionamentos (MER), primeiramente é necessário elencar as possíveis informações existentes no domínio do problema para posteriormente abstraí-las e classificá-las como entidades. As relações estabelecidas entre as entidades são materializadas por meio de relacionamentos, responsáveis por realizar a ligação consistente das informações.

O processo mencionado no parágrafo anterior tem como característica a criação de um MER para posterior utilização, ou seja, primeiramente deve-se criar a estrutura de tabelas e seus relacionamentos, para depois iniciar o processo de inserção das informações. As soluções NoSQL trabalham de forma diferenciada. Ao invés de realizar o processo de definição da estrutura para em seguida promover a inserção das informações, estas são inseridas no repositório e, aos poucos, de acordo com suas respectivas associações, são responsáveis por compor e modificar o modelo de dados.

O modelo relacional, baseado em entidades e relacionamentos, foi criado em 1976 por Peter Chen,

Quais são as deficiências do Modelo Relacional?

Para melhor compreensão e contextualização das exigências comerciais e tecnológicas envolvidas com o processo de armazenamento de informações, serão elencados e apresentados a seguir os principais fatores presentes em um ambiente relacional, responsáveis por motivar a elaboração de uma nova proposta de trabalho:

• Solicitação de Mudança: Modelos de dados relacionais, independente de sua maturidade e consistência, não estão totalmente aderentes às novas metodologias e processos de desenvolvimento de software, as quais estão inseridas em um contexto de evolução constante e condicionadas a acomodar mudanças durante o ciclo de desenvolvimento de um novo produto ou manutenção evolutiva;
• Custo de Escalabilidade: A escalabilidade em um banco de dados relacional pode ocorrer de duas formas: horizontal e vertical. A forma horizontal ocorre pela utilização de mais equipamentos e particiona a estrutura de dados de acordo com critérios estabelecidos. A forma vertical ocorre pelo aumento da capacidade do equipamento em que o sistema gerenciador de banco de dados está instalado. Bases de dados NoSQL têm como um de seus motivadores o baixo custo para realizar uma escalabilidade horizontal, o que torna possível o uso de equipamentos mais acessíveis. Além disso, proporciona um modelo de particionamento nativo (Sharding);
• O paradigma OO, a Fragmentação e o Alto Custo do Join: Ao longo de toda a história, desde a sua concepção, os modelos relacionais sofreram mudanças relativamente pequenas para acomodar exigências oriundas de requisitos de negócio. Paralelamente, a programação sofreu grandes mudanças, desde a programação estruturada, a programação orientada a objetos e a programação orientada a aspectos.

Esta grande lacuna formada entre os dois mundos, os quais precisam trabalhar em conjunto, torna-se responsável por gerar modelos de dados não aderentes à estrutura flexível do software. Por exemplo: a programação orientada a objetos utiliza conceitos de generalização e especialização, representadas por recursos de herança para definir entidades específicas, as quais compartilham atributos genéricos também presentes em outras entidades, conforme apresentado na Figura 2. Esta mesma abordagem, quando aplicada em um modelo de dados relacional, pode ser feita de duas formas: ou uma tabela de dados é criada, contendo todos os atributos e, para alguns registros, algumas informações não são preenchidas (causando a fragmentação em partes da tabela de dados), ou então, uma tabela adicional é criada para acomodar as informações específicas, relacionadas por uma chave estrangeira. No caso da criação da tabela adicional, evitamos a fragmentação, porém, ao ser criada, as consultas realizadas deverão utilizá-la, gerando um custo adicional para um novo Join. Como se sabe, a junção de duas tabelas (Join) em um banco de dados relacional representa um alto custo de processamento.

O banco de dados relacional utilizado no projeto apresentado neste artigo é o MySQL, versão 5.5. A escolha desta solução foi realizada com base em sua maturidade e grande aceitação no mercado corporativo."

[...] continue lendo...