MVC 3 e RavenDB - Revista .net Magazine 92

Não é de hoje que o mercado percebe que muitas coisas precisam mudar. Tecnologias tornam-se ineficazes, dando lugar a outras tecnologias novas e mais poderosas, além do surgimento de novos padrões, algo comum neste tão dinâmico mundo de construção de sistemas. Atualmente vê-se na comunidade mundial um grande esforço em fazer com que as empresas (inclusive grande corporações) entendam que boas práticas são necessárias quando se quer construir um software consistente, de qualidade e que venha realmente atender as necessidades do usuário final. Padrões, princípios e boas práticas de desenvolvimento, vêm ganhando cada vez mais força neste cenário. Outro exemplo é relacionado à infraestrutura sistêmica e alta disponibilidade com o cloud computing que vêm trazendo uma nova filosofia de como escalar a infra e até hospedagem de uma aplicação, enfim, percebe-se que mudanças importantes estão acontecendo. E a forma que estes dados estão sendo armazenados? Os SGDB atuais suportam a abordagem atual de construção orientada a objetos? É, eles também não poderiam escapar desta avalanche de mudanças,  mesmo com todo seu avanço nestes últimos 30 anos.

 Relacional x Orientado a objetos

Dois paradigmas, duas abordagens diferentes, em cada uma delas existe uma particularidade. Devido a estes fatores, sempre houve a necessidade de se criar mecanismos para que os dois mundos se “falassem”. Surgiram então os famosos mapeadores objeto relacional, que permitem que suas aplicações fossem desenvolvidas orientadas a objetos, e os mesmos fossem armazenados em uma tabela através de um mapeador que realizava o “meio-campo” com um banco de dados relacional. Muito embora esta abordagem de desenvolvimento ainda seja bastante utilizada, até hoje em larga escala, há muitos problemas em se utilizar esta abordagem ou até mesmo utilizar um armazenamento relacional. Esta discussão é antiga e concentra-se justamente no esforço que é feito para fazer estes dois mundos se falarem sem problemas, sem que os “efeitos colaterais” aconteçam e tenhamos um sistema robusto e escalável. O esforço que é feito para “traduzir” um objeto, para uma tabela do banco de dados, acaba por tornar mais caro o processo de persistência das informações, o que inviabiliza a utilização desta abordagem em sistemas que trabalhem com volumes grande de dados. O tempo para consultar uma informação poderia ser extremamente maior, mesmo que os ORM´S modernos trabalhem com cache de dados. Por terem arquiteturas diferentes em certos cenários, torna-se melhor utilizar um banco de dados que entenda o “termo” objeto, que é o caso dos bancos de dados NoSQL.

 Não sou relacional – NoSQL!

Termos de negação podem dizer muitas coisas, mas o que é realmente um banco de dados não relacional? O que é o movimento NoSQL? O que ele propõe? Quais benefícios em utilizá-lo? Quais benefícios ele traz?  O termo NoSQL foi utilizado pela primeira vez em 1998, era na verdade o nome de um banco de dados que não fazia uso de uma interface SQL. Após quase 10 anos, em 2009 volta-se a ouvir o termo NoSQL, fazendo alusão a esta nova categoria de bancos de dados não relacionais e com uma abordagem completamente diferente da relacional e que não eram focados em garantir os valores da tão famosa sigla ACID.

O NoSQL é muito mais do que uma nova categoria de banco de dados, é muito mais do que uma nova maneira de armazenar dados, ou simplesmente a capacidade de armazenar meus objetos exatamente com suas estruturas orientadas a objetos. NoSQL é uma nova escola de pensamento em termos de armazenamento de dados, completamente diferente da abordagem relacional que vigorava a mais de 30 anos, e que era na verdade como um verdadeiro império tecnológico. A proposta do NoSQL é resolver exatamente os problemas centrais em se utilizar bancos de dados relacionais, que é o problema da escalabilidade dos bancos de dados relacionais. Escalar um banco de dados relacional pode em muitos casos, dependendo do tamanho do sistema e o volume de dados com o quais ele trabalha ser extremamente caro e complexo. Seja do ponto de vista técnico ou financeiro, escalar um banco de dados relacional não é uma tarefa fácil, e se já não bastassem todos estes fatores, o ponto forte do NoSQL é justamente o ponto mais fraco dos que seguem a abordagem relacional, a escalabilidade.

Os bancos de dados NoSQL estão divididos em algumas categorias, estas, serão discutidas posteriormente. O que faz um determinado banco de dados NoSQL se encaixar em uma destas categorias é justamente a maneira como cada um deles armazenam os dados, ou seja, o modelo de dados adotado para trabalhar. Quando se fala que os bancos NoSQL seguem uma nova escola de pensamento, é justamente porque eles não seguem a convenção tradicional que os relacionais seguem, que é armazenar dados em tabelas e colunas; os bancos de dados relacionais tem uma estrutura rígida de armazenamento de dados e relacionamentos, o que muitas vezes o torna lento durante seus processos, por ter que verificar a estrutura, ou seja, o schema das tabelas para realizar alguma operação, o que não é o caso dos bancos de dados NoSQL, pois eles são schema-less, ou seja, não fazem a exigência de um schema pré-determinado. Na Tabela 1, você confere a lista de categorias do NoSQL.

 NoSQL e o JSON

Os bancos de dados NoSQL da categoria orientados a documento como o RavenDB, armazenam seus documentos, ou seja, os seus objetos no formato JSON. Um objeto JSON é formatado seguindo o padrão JSON, que é o acrônimo de Java Script Object Notation. Este padrão que vem sendo utilizado em larga escala, por sua simplicidade e vem sendo adotado como uma opção ao XML, principalmente quando se deseja uma melhor performance por parte do software cliente, e não se deseja ter uma queda nesta performance por parte do processamento de um documento XML. O JSON surgiu com a mesma finalidade do XML: permitir o fácil intercâmbio de informações, e também permitir a interoperabilidade entre sistemas. Além de todas as definições anteriores, o JSON é uma notação baseada em JavaScript, embora tenha o mesmo no nome não requer necessariamente o JavaScript para funcionar; o JSON é fácil de ler, escrever e realizar o parse do mesmo, além de ser um formato de texto completamente independente de linguagem de programação, muito semelhante ao XML.

RavenDB

RavenDB é um banco de dados NoSQL orientado a documentos criado por Ayende Haien, um dos colaboradores do mapeador objeto relacional mais famoso e utilizado na atualidade, o NHibernate. RavenDB além de ser NoSQL, é também open source, tendo seu código fonte publicado no Github (veja na sessão Links, no final do artigo), mas também existe uma licença comercial . Como um banco de dados da categoria orientado a documentos, o RavenDB armazena seus dados sem schema, ou no termo em inglês schemaless; isto quer dizer que os objetos são armazenados como documentos independentes, ou seja, não tem relação uns com os outros, como mostra a Figura 1. O documento que representa o objeto persistido, nada mais é do que o JSON gerado a partir do objeto, sem ter sido aplicado nenhuma formatação, como mostra a Figura 2.  Isto gera ao desenvolvedor a flexibilidade de trabalhar com um modelo de domínio POCO e armazena-los exatamente em seu estado original, sem a necessidade de aplicar o conceito de ORM, ou seja, o desenvolvedor tem a possiblidade de trabalhar com a orientação a objetos de ponta-a-ponta, com isto garantindo a latência e alta performance."

A exibição deste artigo foi interrompida.

  Este é um post disponível para assinantes MVP

Este post também está disponível para assinantes da .net Magazine DIGITAL
ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!

Saiba como acessar este post através de Créditos DevMedia:

Assinatura de Créditos – Aqui este post custa R$ 1,50
Com esse plano você compra R$ 180,00 em créditos e ganha, em média, 80% de desconto no preço do post.  
Assine agora

Plano ocasional - Aqui este post custa: R$ 2,00 (assinante) ou R$ 2,50 (não-assinante)
Você compra um mínimo de R$ 60,00 em créditos e ganha, em média, 50% de desconto no preço do post.  
Compre agora

Plano conveniência – Neste plano este post custa R$ 5,00
Neste plano você compra somente um post, pagando seu preço sem desconto.  
Compre agora