Usando Cassandra com Spring Data no Easy-Cassandra

O Spring é um framework open source cujo o objetivo sempre foi facilitar a vida do desenvolvedor Java, começou com os recursos para injeção de dependência e hoje atua em diversas atividades triviais para um programador. Entre elas podemos citar a parte social com o Spring social no twitter, facebook, segurança com o Spring security além do já inversão de controle e inversão de dependência. O foco desse pequeno post é falar sobre o Spring Data e seu trabalho com o banco não relacional Cassandra.

O Spring-data é um pequeno módulo ou plugin do Spring e tem como objetivo auxiliar nos processos triviais de persistência criando uma camada entre a base onde se encontra as informações e o seu código java. Dessa maneira é possível, efetuar ações na base, usando como estrutura para as informações, o POJO (simples e velho objetos em java). Dentro do Spring Data já existem diversos tipo de base de informações.

• Bancos Relacionais com JPA e JDBC
• BigData com Apache Hadoop
• Data-Grid com GermFire
• HTTP com Rest
• NOSQL com MongoDB, Neo4J, Redis e Hbase

Uma das grandes vantagem do Spring Data é ser filho do Spring. Ele não precisa de um servidor Java EE, ou seja, ele pode rodar em um simples contêiner como o tomcat ou mesmo rodar sem o auxílio do servidor. Sua injeção funciona com auxílio de um arquivo xml, mas não necessariamente toda configuração é feita por lá, existem várias anotações que podem ajudar o desenvolvedor, no entanto, cabe apenas ao mesmo saber em qual momento é mais adequado usar cada um deles.

Com esse foco o Spring Data Cassandra tem o foco de criar uma camada de alto nível para o nosql Cassandra, assim é possível com estruturas de POJOs estabelecer uma conexão no banco e realizar as operações CRUD, tudo isso sem abrir mão da estrutura de dados já conhecida pelo desenvolvedor Java. O Spring Data Cassandra ainda não foi fechada, mas o Easy-Cassandra já possui integração com Spring, agora é possível utilizá-lo com a injeção de dependências do framework Java mais famoso do mundo.

A aplicação será realmente bastante simples seu objetivo será apenas criar uma informação e armazenar no banco, em seguida recuperar pelo id. O primeiro passo será a criação da entidade pessoa, ela terá os campos id, nome e ano, conforme mostra a tabela número1.

@Entity(name = "person") 
public class Person implements Serializable { 

    @Id 
    private UUID id; 
     
    @Index 
    @Column(name = "name") 
    private String name; 
    
    @Column(name = "born") 
    private Integer year;
//getter and setter

}

Simples Pojo da Classe pessoa

Como pode ser visto os campos são anotados via JPA 2.0, o segundo passo é a criação do xml, é nele que conterá as configurações do banco de dados (host, porta, keyspace padrão, etc.). O próximo passo é a configuração e criação da fábrica de conexões para o Cassandra dentro do spring, isso é, o host, porta e o keyspace padrão, e as classes que serão mapeadas como mostra no arquivo xml abaixo.

 

 
 
 
  
   org.javabahia.cassandra.spring.entity.Person
  
 
 


 

Configuração do Spring-Data, informando as configurações do Banco (host, porta, nesse caso a padrão, e o keySpace) além de criar o Template Cassandra

Com a fábrica de conexões do cassandra é possível retornar uma sessão, a via de comunicação do Cassandra com a aplicação Java, além disso será criado o CassandraTemplate, uma api de alto nível que consegue realizar a comunicação Cassandra sua aplicação a partir de um simples POJO, desse modo é possível realizar a operação CRUD de uma maneira bastante simples, o código abaixo mostra a interface do Cassandra template.

public interface CassandraTemplate{ 
   
     <T> T save(T entity); 
     
     <T> Iterable<T> save(Iterable<T> entities); 
     
     <T> void delete(T entity); 
     
     <T> void delete(Iterable<T> entities); 
     
     <K> void delete(K key, Class<?> entity); 
     
     <K,T> void delete(Iterable<K>  keys, Class<T> entity); 

     <T> void deleteAll(Class<T> entity); 
     
     <T> T update(T entity); 
     
     <T> Iterable<T> update(Iterable<T> entities); 
     
     <T,K> T findOne(K key, Class<T> entity); 
     
     <T,K> List<T> findAll(Iterable<K> keys, Class<T> entity); 
     
     <T> List<T> findAll(Class<T> entity); 
     
     <T,I> List<T> findByIndex(String columnName,I index,Class<T> entity); 
     
     <K,T>boolean exist(K key, Class<T> entity); 

     void executeUpdate(String query); 

Operações que podem ser realizadas com o seu Objeto

Além do CassandraTemplate existe o CassandraRepository, essa classe abstrata implementa o CrudRepository do SpringData, com ela é necessário apenas implementar o método que retornará o CassandraTemplate, conforme mostra a tabela abaixo.

@Repository("personRepository")
public class PersonRepository extends CassandraRepository<Person, UUID>{

 
 @Autowired
 private CassandraTemplate cassandraTemplate;
 
 @Override
 protected CassandraTemplate getCassandraTemplate() {
  return cassandraTemplate;
 }

}

Criando o repositório para a classe Person

Como o CassandraReporitory implementa a classe base de operações do Spring todas as suas operações estarão disponíveis para serem utilizadas com o Cassandra.

public interface CrudRepository<T, ID extends Serializable> extends Repository<T, ID> { 
 <S extends T> S save(S entity); 

 <S extends T> Iterable<S> save(Iterable<S> entities); 

 T findOne(ID id); 

 boolean exists(ID id); 

 Iterable<T> findAll(); 

 Iterable<T> findAll(Iterable<ID> ids); 

 long count(); 

 void delete(ID id); 

 void delete(T entity); 
 void delete(Iterable<? extends T> entities); 

 void deleteAll(); 
}

Interface CrudRepository do Spring Data que é implementada pela classe abstrata CassandraRepository

Realizado as configurações o próximo passo é executar o projeto como mostra o código a seguir:

public class App 
{
    public static void main( String[] args )
    {
     @SuppressWarnings("resource")
  ApplicationContext ctx = new GenericXmlApplicationContext("SpringConfig.xml");
     
     PersonRepository personService=ctx.getBean(PersonRepository.class);
     
     UUID uuid=UUID.randomUUID();
     Person person=new Person();
     person.setId(uuid);
     person.setName("Otávio Santana");
     person.setYear(25);
     
     personService.save(person);
     
     
     Person otavio=personService.findOne(uuid);
     System.out.println(otavio.getName());
     
     
    }
}

Rodando o Simples Projeto, salvando e recuperando a informação

Com isso foi demonstrado o conceito do Spring Data e o seu funcionamento com o Cassandra utilizando o Easy-Cassandra, o intuito criar uma interface padrão para que todos os modelos de persistência a utilizem dentro do Spring é um grande e importante passo para utilizar uma nova base ou modelo de dados não haja impacto dentro do Spring, mas é muito importante salientar que mesmo que vários bancos utilizem essa interface é importante considerar uma nova modelagem, já que diferente dos bancos relacionais, a mudança de um banco NOSQL pode significar a mudança estrutura de armazenamento.

Links:

Spring Data: http://www.springsource.org/spring-data

Easy-Cassandra: http://otaviojava.github.io/Easy-Cassandra/

Exemplo: https://github.com/otaviojava/Easy-Cassandra-samples

Cassandra Trip Brasil

O Cassandra é um banco de dados NOSQL orientado à família de coluna que nasceu para resolver problemas com aplicações que precisam operar com gigantescas cargas de dados além de poder escalar com grande facilidade. Ele nasceu no facebook e hoje vem sendo usado com muita frequência pelas redes sociais como Twitter, Instagram, um fator importante que vale ser citado é a sua adoção crescente inclusive em mercados mais conversadores tais como, instituições financeiras e agências governamentais.

Com o intuito de evangelizar essa ideia aqui no Brasil foi criado o Cassandra Trip Brasil, o evento terá duração de uma semana, entre os dias 2 até 6 de setembro, sendo que cada dia será apresentado em uma cidade diferente. As cidades que sediarão esse evento serão:

• 2 de setembro, segunda-feira: Campinas
• 3 de setembro, terça-feira: São Paulo
• 4 de setembro, quarta-feira: Florianópolis
• 5 de setembro, quinta-feira: Brasília
• 6 de setembro, sexta-feira: Salvador

Sendo que no dia 3 de setembro o evento será transmitido para todo o Brasil a partir do link:

LINK : https://globalcode.webex.com/globalcode/onstage/g.php?t=p&d=662489296

PASS : cassandra

O evento começará a partir das 18:30 e contará com duas palestras e uma mesa redonda.

Palestra: Visão do NOSQL introdução do Cassandra

Tópicos:

1. O que é NOSQL?
2. Tipos de bancos NOSQL?
3. O que é Cassandra? Quem usa, quando usar e como?
4. Comunidade
5. Como fazer parte da comunidade

Palestra: Cassandra

Tópicos: Integração entre as linguagens de programação como python, Java, etc.

1. O que é CQL novidades na versão 3.0
2. Ferramentas para administrar  Cassandra
3. DataStax Enterprise
4. Demonstrações

No Fishbowl será um local aberto para trocar experiências, esclarecer dúvidas, dicas de como começar. O grande legal dessa palestra é que quem define o andamento será o público.

Entrada: Gratuíta

Inscrições: http://goo.gl/hzijyz

Endereços:

Cidade: Campinas

Data: 2 de setembro, segunda-feira

Horário: 18:30

Local: Global Code

Endereço: Av. Bernardino de Campos, 327, São Paulo, 04004-050

Cidade: São Paulo

Data: 3 de setembro, terça-feira

Horário: 18:30

Local: Global Code

Endereço: R. José Paulino, 2236, Campinas, 13023-102

Cidade: Online

Data: 3 de setembro, terça-feira

Horário: 18:30

Local: Online

Endereço: https://globalcode.webex.com/globalcode/onstage/g.php?t=p&d=662489296

PASS : cassandra

Cidade: Florianópolis

Data: 4 de setembro, quarta-feira

Horário: 18:30

Local: ACATE (Associação Catarinense de Empresas de Tecnologia)

Endereço: R. Lauro Linhares, 589 - 3º andar - Trindade - Florianópolis, SC - 88036-001‎

Cidade: Brasília

Data: 5 de setembro, quinta-feira

Horário: 15:00

Local: Instituto Federal de Educação, Ciência e Tecnologia de Brasília

Endereço: SGAN 610, Módulos D, E, F e G, Brasília/DF, CEP 70860-100. Auditório 111 BC (120 pessoas) - Campus Brasília

Cidade: Brasília

Data: 5 de setembro, quinta-feira

Horário: 19:00

Local: Instituto Federal de Brasília (Asa Norte)

Endereço: Auditório do Bloco 2 (subsolo do bloco da Biblioteca). Uniceub SEPN 707/907 - Asa Norte CEP 70790-075

Cidade: Salvador

Local: Estácio/FIB

Endereço: Rua Xingu, nº 179-Jardim Atalaia/STIEPCEP: 41770-130

Mais informações sobe o casandra: http://cassandra.apache.org/

http://www.planetcassandra.org/

Palestrantes:

Ben Covertson

Director of Operations, DataStax

Coverston is Director of Operations at DataStax, a provider of software, support, services, training, resources and help for Cassandra. He has been involved in enterprise software his entire career. Working in the airline industry, he helped to build some of the highest volume online booking sites in the world, and saw first-hand the consequences of trying to solve real-world scalability problems at the limit of what traditional relational databases are capable of. @bcoverston

Otávio Santana

SouJava, JavaBahia

Desenvolvedor entusiasta do mundo Open-Source. Praticante da filosofia ágil e do desenvolvimento
poliglota na Bahia, JUG Leader do JavaBahia, membro do SouJava, um dos fomentadores do grupo
LinguÁgil. Presente nos maiores eventos Java e ágil em nível nacional, contribui para o projeto 
openjdk e a plataforma JSE, criador do Apache Easy-Cassandra, presente na comunidade Java 
mundial além de escrever artigos para DevMedia, revista espírito livre e java.net

Edward Ribeiro

SERPRO

Universidade de Brasília (UnB). Lecionou em faculdades particulares do DF entre 2002 e 2008 e como professor substituto na UnB nas áreas de bancos de dados, sistemas distribuídos e sistemas operacionais. Trabalhou como servidor concursado no SERPRO, Superior Tribunal Militar (STM), TSE (eleições 2008), Câmara Legislativa do DF (CL-DF). Atualmente é servidor concursado do Senado Federal onde desenvolve sistemas web em Java.

Introdução ao BigData

    Demorou, mas finalmente conseguir um tempo para falar um pouco da minha apresentação no JavaOne 2012 que foi BigData. Com a evolução das aplicações e a necessidade do ser humano pela informações, mais e mais aplicações vem surgindo, deixando o homem cada vez mais refém da informação. Para isso basta lembra-nos da evolução do homem em que num passado existia muitas pessoas para uma máquina ( como o mainframe), em seguida uma pessoa por máquina ( o caso do computador pessoal) e nos tempos atuais em que para cada pessoa possue várias máquinas ( notebook, ultrabook, PC, tablet, smartphone, no futuro óculos, geladores, etc.). Com tantos aplicativos surgindo as informações são geradas exponencialmente, com isso a capacidade de gerenciar tantas informações se torna primordial para as aplicações atuais. Esse mesmo crescimento de dados acontece nos aplicativos empresariais com crescimento anual de 60%, se estima que uma empresa com mil funcionários gera anualmente 1000 terabytes sem falar que essa quantidade tende a aumentar cinquenta vezes até 2020.

    Com o recém surgimento do bigdata, a primeira dificuldade é encontrar o seu conceito, é possível vê-los de maneiras totalmente divergentes em cada blog que se lê, ou seja, se você ler 10 materiais sobre bigdata, provavelmente cada um trará conceitos diferentes. Dentre as matérias ao se tirar um mínimo comum se verá que o bigdata na sua raiz se fala em tratar um grande volume de dados com grande velocidade. No entanto se repara que essa definição é bastante abstrata pelo simples fato de que para uma pessoa A, por exemplo, um grande volume seja um gigabyte e para uma pessoa B um grande volume seja um terabyte e o mesmo pode acontecer ao se referenciar a velocidade e o tempo de resposta de uma requisição.

    Assim o grande desafio do bigData é estar administrando um grande volume de dados e minerando informações em um menor tempo de requisição. Com o grande volume de dados fazer com que a aplicação cresça a medida que é necessário é uma ótima estratégia assim uma escalabilidade vertical ( em que se aumenta o poder do hardware como aumento de memória e de processamento de uma única máquina) ou horizontal ( em que se aumenta a quantidade de máquina) deve ser analisada. Apesar de ser mais complexa a escalabilidade horizontal acaba sendo muito barata sem falar de ser mais fácil de crescer ou diminuir os recursos por demanda.

    Para armazenar as informações com a escalabilidade horizontal os bancos NOSQL são uma ótima estratégia, vale lembrar que o banco NOSQL significa não apenas, not only, e não sql, no sql. Uma diferença entre os bancos NOSQL e o SQL é que o primeiro possui uma grande variedade de bancos e cada um com características diferentes. Em termo de arquitetura os bancos NOSQL podem ser distribuídos ou não, embora sejam mais populares do tipo distribuído. Sua forma de armazenamento pode ser apenas memória ou apenas disco rígido ou configurável( vale apena lembrar que banco apenas na memória são muito rápidos, no entanto são volúveis, já os somente no HD tem informações permanentes, porém o I/O é muito alto). Outra características divergentes entre os bancos NOSQL está na forma do armazenamento que são: chave-valor, documento, família de coluna e grafos. Os bancos         NOSQL costumam ser muito rápido na leitura e na escrita, no entanto, possui uma grande deficiência por parte das buscas, normalmente são dadas apenas pela chave, para isso usar um serviço para terceirizar o serviço pode ser uma boa ideia, como o framework Lucene.

    Mesmo realizando estratégias de buscas terceirizadas ou buscando pelo id, se a informação não estiver na memória principal pode haver uma demora para recuperar essa informação, assim, ter um dispositivos de acesso rápido pode ser uma melhor opção, com isso o uso do cache. Ao se optar pelo cache deve-se levar em conta os dois maiores desafios:

• Ter informação: O ato de esquentar a informação é extremamente importante para esse mecanismos, já que não adianta existir um cache se o mesmo não tenha nenhuma informação. Para isso ele pode ser esquentado de várias formas (ao iniciar uma aplicação, por demanda, por sessão do usuário) que desse ser definido com o aplicativo em questão não existindo uma bala de prata.
• Matar o cache: Para o cache é necessário que exista apenas informações atuais, assim é importante que os dados atuais sejam mortos e trocado por informações mais atuais.

    Um outro aspecto no bigdata, que não é muito tratado, está relacionado na velocidade da modelagem além da velocidade no desenvolvimento de software. Um exemplo muito interessante é o twitter que viu muito usuários usando a hashtag ( o '#' adicionado com uma palavra) e em pouco tempo teve que realizar pesquisas através dos mesmos.

    Assim podemos verificar que o bigdata não apenas está relacionado apenas na velocidade de requisição, mas também em desenvolvimento, assim conhecer bem o negócio além de várias ferramentas poderá ser extremamente importante. Na linguagem Java conhecer o Java EE 6, muito em breve o java 7, além do JDK 7 trará velocidade de desenvolvimento, produtividade e um melhor gerenciamento de memória.

    Assim pode-se concluir que o conceito do BigData é relativamente muito fácil, mesmo sendo divergente em várias fontes, que é gerenciar um grande volume de memória em alta velocidade. O mais difícil certamente é chegar nesse objetivo já que para isso é necessário conhecer uma gama de ferramentas, frameworks, metologias, tipos de bancos como NOSQL, SQL e NewSQL, cache, serviço de indexação de buscas, tipos de escalabilidades, etc. Apesar de ainda ser muito discutida nas universidades a normalização foi desenvolvida em 1970 ( vale lembrar que os servidores da época possuíam 16kb de memória principal e 800kb de armazenamento e os celulares são muitas vezes mais rápido que estes servidores) ou seja não é certo afirmar que os aplicativos, os hardwares, as necessidades de hoje são os mesmos daquela época, assim é entender que esse padrão nem sempre é válido.

Bigdata from Otávio Gonçalves de Santana




Código: https://github.com/otaviojava/introBigData