Vamos falar de Padrões NoSQL [Q&A]

duke-diana-min

Com a evolução da tecnologia da persistência, termo como “persistência poliglota” vem se tornando cada vez mais comum para o vocábulo do desenvolvedor. Atualmente, não basta utilizar a linguagem de programação mais apropriada para o problema, mas também utilizar o melhor banco e a melhor forma de persistir tais informações. Uma boa escolha trará certamente uma facilidade na leitura, elasticidade além de performance tanto na leitura quanto na escrita, isso variará de acordo com o objetivo e interesse de cada programa. Com isso, nem todas as aplicações utilizam ou utilizarão as soluções clássicas para persistência, os bancos relacionais. Os bancos NoSQL se tornaram uma solução muito comum para isso. O objetivo desse artigo é esclarecer algumas sobre o mais recente projeto criado, o JNoSQL, dúvidas com relação aos próximos passos dos bancos NoSQL focando na linguagem mais utilizada no mundo, Java, no formato de perguntas e respostas.

Para os detalhes iniciais como definição, já realizei um post sobre isso:

https://otaviojava.wordpress.com/2016/09/10/nosql-java/

O que é o JNoSQL?

O projeto JNoSQL é um projeto que visa a criação de ferramentas para o desenvolvimento de bancos não relacionais, os NoSQL, seu foco será padronizar os bancos NoSQL olhando para sua diversidade, ou seja, criando mecanismo para que o mesmo seja extensivo. Para facilitar o desenvolvimento dessa ferramenta foram criadas duas camadas abaixo do JNoSQL:

A camada de comunicação (aka Diana): Essa camada é responsável por realizar a comunicação entre a aplicação Java e o banco de dados. Essa API será dividida em quatro partes, uma para cada tipo de banco NoSQL. Ele será semelhante ao JDBC do mundo relacional.

A camada de abstração (aka Artemis): semelhante ao ORM ele é responsável por facilitar a abstração para o desenvolvedor Java, ela será orientada a anotações e realizará integrações com outras tecnologias como, por exemplo, o bean validation. O seu coração será o CDI.

Essa divisão tem algumas vantagens:

  • Divisão de problemas (Assim, os bancos de dados darão atenção apenas a camada de comunicação enquanto desenvolvedores de framework darão atenção numa camada superior.
  • Facilidade na implementação, uma vez um novo banco de dados interessado em implementar a API do JNoSQL será necessário apenas implementar a API de comunicação não se preocupando com as outras camadas.
  • Facilidade em componentização, com essa estratégia será possível trocar um dos dois componentes sem que necessariamente exista impacto no outro lado.

Vamos padronizar?

Sim, a ideia é que o resultado do trabalho dentro do JNoSQL seja o foco de padronização. Inicialmente, apenas a camada de comunicação será levada como uma JSR. Esse é um dos motivos que esse projeto tem como parcerias diversos provedores de banco de dados, por exemplo, Cassandra, Hazelcast, OrientDB, couchbase, ArangoDB, MongoDB, HBase além da participação da comunidade (SouJava, LondoJC, ThinkerPOP, dentre outros).

É possível padronizar 100%?

Mesmo os bancos relacionais que já estão a décadas no mercado, não é possível padronizar todo o processo. O mesmo acontece com os bancos NoSQL, inicialmente serão padronizadas as entidades, as hierarquias e algumas ações. Existirão quatro tipos de API, detalhado anteriormente. Mesmo com bancos de dados do mesmo tipo, por exemplo família de coluna com Cassandra e o hbase, existem comportamentos diferentes, por exemplo o nível de consistência e o Cassandra Query Language que existem apenas no Cassandra, para isso a API deverá fornecer a extensibilidade para que seja possível realizar tal operação, no entanto, mesmo com esses comportamentos diferentes o Cassandra continuará lidando as mesmas entidades que o Hbase (Família de Colunas, Colunas, chave da família de coluna, etc.). Por exemplo:

//both implementations (Hbase and Cassandra)
ColumnFamilyEntity entity = …/
entityManager.save(entity);
//just on Cassandra
cassandraEntityManager.save(entity, ConsistencyLevel.ALL);
List entities = entityManager.cql(¨select * from entity¨);

Existirão casos também na qual a API retornará uma exceção de operação não suportada, caso o banco de dados não suporte algumas operações.

Quais métodos serão padronizados?

Nessa primeira versão o foco será padronizar apenas os modelos além de métodos de operação básicas, são eles:

  • Inserir de maneira síncrona, assíncrona, assíncrona com calback além do uso de TTL
  • Atualizar de maneira síncrona, assíncrona, assíncrona com calback além do uso de TTL
  • Deletar de maneira síncrona, assíncrona, assíncrona com calback além do uso de TTL
  • Realizar queries de maneira síncrona e assíncrona

Ou seja, inicialmente as APIs conseguirão realizar as operações de CRUD.

A única exceção será a API de grafos, na verdade, o modelo de grafos já existe uma padronização já conhecida: o ThinkerPOP. A ideia é que a API contenha as partes mais estáveis desse projeto e sua implementação de referência seja uma simples adapter entre os projetos, em outras palavras, todos os bancos que suportam o ThinkerPOP, automaticamente suportarão o Diana.

Mesmo sem padronizar tudo ainda vale a pena?

Nós acreditamos, que sim! Será necessário realizar o primeiro passo e o JNoSQL realizará esse passo. Utilizaremos a estratégia incremental, ou seja, serão dados pequenos passos e pequenos releases para que recebemos rápidos feedbacks sobre a API.

O que acontece com um banco de dados que suporta dois tipos de bancos de dados?

Ele terá que implementar uma API para cada banco de dados que ele suporte. A ideia também é que existe um TCK, que terá como objetivo verificar se a banco de dados suporta ou não corretamente essa API.

Qual é o seu atual status?

O projeto foi recentemente aceito para Eclipse Foundation e estamos recebendo alguns feedbacks sobre a API. Também foi realizada uma apresentação do projeto para o JCP no F2F em Londres: https://goo.gl/2pKwrd

Como faço para ajudar?

Atualmente existem diversas maneiras de ajudar o projeto:

  • Documentação
  • Revisar a documentação já existente
  • Feedback na API
  • Encontrar bugs na implementação
  • Implementar novos drivers
  • Criar exemplos
  • Ajudar na tradução do material para o seu idioma
  • Realizar a palestra sobre esse projeto no seu JUG.

Quais referências estou utilizando?

Estamos utilizando como base diversos projetos existentes, inclusive, além da nomeclatura. Sempre que possível utilizaremos a mesma nomenclatura já existente em outras especificações para facilitar o aprendizado dos desenvolvedores Java.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s