DevMedia
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da Java Magazine DIGITAL
ou para quem possui Créditos DevMedia.

Clique aqui para saber como acessar este post

1) Torne-se um assinante MVP e por apenas R$ 69,90 por mês você terá acesso completo a todos os posts. Assinar MVP

2) Adquira Créditos: comprando R$ 180,00 em créditos esse post custará R$ 1,20. Comprar Créditos

Java Magazine 103 - Índice

JPA/Hibernate ou NoSQL, qual utilizar? - Revista Java Magazine 103

O artigo traz uma análise entre as vantagens e desvantagens da utilização da especificação ORM com JPA e Hibernate e o uso de bancos de dados não relacionais (NoSQL) para o desenvolvimento de aplicações Java.

[fechar]

Você não gostou da qualidade deste conteúdo?

(opcional) Você poderia comentar o que não lhe agradou?

Confirmo meu voto negativo
Por; EVERTON COIMBRA DE ARAÚJO / GIOVANI GUIZZO

Em sistemas orientados a objetos, um grande impedimento é encontrado quando se diz respeito à persistência. Pode não parecer tão problemático assim, mas a transformação de objetos em dados persistentes no espaço relacional pode ser um trabalho árduo. O grande problema nessa situação são as duas estruturas totalmente diferentes que são empregadas em cada camada do sistema. No mundo relacional são criadas tabelas e colunas para armazenar informações, enquanto no modelo orientado a objetos, classes e objetos são prevalecentes.
Para solucionar esse problema, há alguns anos era preciso criar instruções SQL para transformar objetos em tuplas do banco de dados, porém muito tempo era perdido com essa prática, tanto no momento do desenvolvimento, quanto no de testes. Além de o desenvolvedor precisar implementar o código para a criação do banco de dados totalmente compatível com o modelo orientado a objetos, a cada nova operação de inserção, alteração, exclusão ou pesquisa, uma quantidade imensa de código no sistema era gerada a fim de tratar essa incompatibilidade de estruturas. Em longo prazo, isso tudo se tornava um trabalho exaustivo, não reutilizável e, muitas vezes, falho.

Surge então o conceito de ORM (Object-Relational Mapping ou Mapeamento Objeto-Relacional). Ele propõe a transformação de classes e objetos em tabelas e tuplas de maneira invisível, fácil e reutilizável ao programador. Ao invés do programador ter que criar todas as instruções SQL para as operações no banco de dados, ele pode utilizar um framework capaz de fazer essas operações sem sair do paradigma de orientação a objetos, de maneira transparente. Assim, todo aquele trabalho árduo de codificação e testes se resume a algumas configurações e um mínimo de código, sem manter um contato direto com o banco de dados.

Até então o ORM era só um conceito para qualquer linguagem orientada a objetos e para que esse conceito saísse do papel, em 2006 a Sun lançou a JSR 220 especificando os Enterprise JavaBeans (EJB) 3.0 (ver Links). Juntamente com o EJB 3.0, a Java Persistence API 1.0 foi disponibilizada ao público desenvolvedor. Mais posteriormente, em 2009, a JSR 317 foi divulgada, dessa vez contendo apenas a especificação JPA 2.0 (ver Links). Em suma, essa API apresenta anotações e interfaces, para que os frameworks que forem desenvolvidos sigam um padrão de funcionamento. A JPA não possui grande quantidade de código. De fato ela não faz o papel de um framework ORM. Ela apenas dita como eles deverão funcionar na plataforma Java.

É nesse contexto que o Hibernate entra. O Hibernate faz o papel de um provedor de persistência. Um provedor de persistência geralmente é um framework ORM que implementa as especificações JPA e disponibiliza toda a programação necessária para o efetivo Mapeamento Objeto-Relacional e a persistência de dados. Mesmo o Hibernate tendo um papel tão fundamental na persistência de dados e no Mapeamento Objeto-Relacional, todo o acesso às suas funcionalidades acontece de uma maneira quase que transparente, uma vez que o programador utiliza na maior parte do tempo apenas as anotações e interfaces disponibilizadas pela JPA.

O Hibernate surgiu antes da especificação JPA e foi ele quem motivou a criação dessa especificação. Quando o Hibernate ganhou popularidade, a Sun previu que muitos outros frameworks seriam desenvolvidos e se uma maneira padronizada de mapeamento objeto-relacional não fosse criada, os desenvolvedores desses outros frameworks sairiam prejudicados caso optassem por uma migração da ferramenta. Prejudicados pelo fato de não poderem reutilizar código para persistência, configurações e mapeamentos.
É importante lembrar que existem outros provedores ORM e não apenas o Hibernate. Alguns exemplos são o EclipseLink, OJB, OpenJPA e DataNucleus. Desses exemplos, o mais notável é o EclipseLink. Ele foi o RI (Reference Implementation) do JPA 2 e hoje é um dos mais utilizados.

Muitas corporações mundiais já adotaram o Hibernate como sua ferramenta de desenvolvimento. Alguns exemplos são: Sony, AT&T, PwC e Cisco. Para mais informações sobre ORM e Hibernate, veja a seção Links.


Os bancos de dados NoSQL
NoSQL (Not only SQL) é muito mais do que apenas um tipo de banco de dados. Esse termo é bem abrangente, envolvendo vários conceitos, tecnologias e estruturas. Ele foi criado em 1998 por Carlo Strozzi e teve como objetivo substituir bancos de dados relacionais, a fim de prover uma maneira mais leve e dinâmica de armazenamento de dados sem expor a utilização da linguagem SQL.


Outro aspecto importante no qual os bancos de dados NoSQL se diferenciam, é a maneira como operam. Enquanto os bancos de dados relacionais se baseiam no conceito ACID (Atomicidade, Consistência, Isolamento e Durabilidade), bancos de dados NoSQL utilizam o conceito BASE (Basically Available, Soft state, Eventually consistent).

No modelo ACID, a Atomicidade refere-se à transação. Isso quer dizer que, se a transação do banco de dados falhar, se ocorrer um mínimo erro em qualquer parte da instrução SQL ou em qualquer parte do meio físico, nada é persistido. Uma informação só é persistida caso todas as outras da mesma transação estejam regularizadas e prontas para serem persistidas. Assim, SGBDs (Sistemas Gerenciadores de Banco de Dados) que possuem essa função bem definida, ao sofrerem desligamentos inesperados ou pequenas falhas de hardware por parte de seus servidores, não perderão quantidades significativas de dados ou não terão apenas parte das informações de uma transação gravadas no disco rígido. Geralmente, a atomicidade vem acompanhada da instrução commit. Commit significa “efetuar”, “cometer” e é essa instrução que fecha a transação e permite que a consolidação dos dados seja feita. Bancos de dados NoSQL não garantem essa segurança, uma vez que não possuem transações. Sendo assim, ao executar uma instrução NoSQL, as informações serão persistidas no decorrer da execução e não como ocorre em bancos de dados relacionais (somente após o commit).

Nesse contexto entra a Consistência. Para que um banco de dados mantenha sua consistência, ele deve, sempre que uma transação for finalizada, além de garantir a atomicidade, transitar de um estado válido para outro. Para um banco de dados possuir um estado válido, todos os seus dados devem ser íntegros, implicando que esses dados, de modo algum, podem ferir as regras do SGBD. Essas regras incluem: constraints, chaves estrangeiras, chaves primárias e outros fatores que alteram diretamente a integridade dos dados. No geral, bancos de dados NoSQL não apresentam chaves estrangeiras ou constraints, o que diminui a integridade dos dados e consequentemente fere o princípio da consistência.

A terceira característica do modelo ACID é o Isolamento. Essa é uma característica que provê segurança na persistência de dados concorrentes e é fundamental em todos os bancos de dados relacionais. Ao dizer que um SGBD mantém suas transações isoladas, significa que, se duas transações tentarem alterar as mesmas informações ao mesmo tempo, elas formarão uma fila de processos e serão executadas em ordem, sem que uma interfira no funcionamento da outra. Bancos de dados NoSQL não garantem total isolamento na alteração de informações, pois não possuem transações.

O “D” do ACID significa Durabilidade. A partir do momento em que uma transação é finalizada, sendo o commit realizado, os dados da transação devem ser gravados no disco rígido e devem permanecer disponíveis até serem excluídos. Essa situação pode não ocorrer quando utilizado NoSQL. Isto não é bem uma falha no banco de dados, mas sim um conceito presente no modelo BASE: Eventually Consistent (Eventualmente Consistente). Esse termo refere-se a como serão persistidos os dados. A maioria das soluções NoSQL armazena uma grande quantidade de informações na memória RAM e deixam-nas lá para que sejam rapidamente recuperadas. O estado do banco é eventualmente alterado e de forma gradativa; normalmente por meio de uma execução paralela da própria aplicação do banco de dados, em que as informações são transitadas da memória RAM para o disco rígido. O problema aqui é se ocorrer alguma queda de energia no servidor. Nesse caso, somente os dados já transitados ficarão intactos, enquanto os da memória serão perdidos. Todavia, esse é um problema não muito comum, uma vez que a maioria dos servidores “na nuvem” garante um uptime de 99,99%.
"

A exibição deste artigo foi interrompida

Este post está disponível para assinantes MVP.



A DevMedia é um portal para analistas, desenvolvedores de sistemas, gerentes e DBAs com milhares de artigos, dicas, cursos e videoaulas gratuitos e exclusivos para assinantes.

O que você achou deste post?
Serviços

Mais posts