segunda-feira, 7 de abril de 2014

Dicas e considerações iniciais ao usar o Cassandra




    Ao se pensar em um banco de dados a primeira coisa que um desenvolvedor de software pensa é em realizar buscas, queries, realizar a normalização. Mesmo depois de tanto tempo com várias discussões com NOSQL, muitas pessoas ainda acreditam que o NOSQL, mas vale lembrar que muitas coisas mudaram no mundo do desenvolvimento de software e isso inclui os bancos de dados, existem muitas soluções além da convencional para armazenar informações. O objetivo desse artigo é discutir é ajudar aquelas pessoas que pretendem ao utilizam o Cassandra em pouco tempo fornecendo algumas dicas.


    Saber quando utilizar a tecnologia: Antes de escolher uma tecnologia é muito importante entender bem o seu problema e em seguida entender o motivo no qual a tecnologia escolhida será útil em seu projeto. Com o Cassandra não é diferente, ele é um banco NOSQL é interessante seu uso quando se precisa de uma alta disponibilidade e tolerância a falhas (seria o A e o P no teorema do CAP). Possui uma escalabilidade linear, ou seja, quanto mais nós em seu datacenter maior será o número de requisições por segundo.

    O Cassandra não é relacional: Uma coisa muito comum das pessoas ao aprender uma nova tecnologia é tentar realizar relações com a técnologia já conhecida, o problema é que em alguns casos os estudantes ultrapassam o estudo e tentam simular o SQL dentro do Cassandra. O Cassandra foi feito em cima de um outro “paradigma” de persistência o BASE é muito importante entender que ao tentar realizar emulações de ACID dentro de um BASE, não se conseguirá atingir nenhum dos objetivos (O erro ficará oculto com uma massa pequena, mas quando for para produção com uma grande massa o erro será desastroso).

    Não existe normalização no Cassandra: Um erro muito comum dentro do Cassandra é tentar realizar a normalização. Como já dito anteriormente o Cassandra foi feito em cima de outro paradigma. O fato é que a normalização se tornou muito popular em 1970, quando o armazenamento era muito caro, assim o desafio era conter a informação de forma econômica, dessa forma não repeti-la. Atualmente o armazenamento está ficando cada vez mais barato e o desafio mudou: É lidar, por exemplo, com um número de requisição cada vez maior (milhões, talvez bilhões).

    Hierarquia dentro do Cassandra: A hierarquia dos bancos relacionais segue o seguinte fluxo: banco, tabela e coluna. No Cassandra acontece de forma semelhante no topo temos o KeySpace, família de colunas, e a coluna, esse por sua vez é composto por um bloco com três informações: O nome do tampo, o valor do campo e o timestamp.

    No Cassandra não existe transação: O Cassandra foi feito para trabalhar com uma alta taxa de disponibilidade, desse modo, é inviável que exista transação, é possível enviar vários registros em uma mesma família de coluna ao mesmo tempo. Para saber qual versão é a mais recente ele utiliza o timestamp existente no campo, acontece que quando um campo é inserido, ele recebe o timestamp do momento que foi inserido.

    Nível de Consistência: O Cassandra trabalha em cima da replicação da informação para ter sua característica tolerante a falhas. Ao se criar um keyspace setta o fator de réplica, que define a quantidade de nós na qual a informação será duplicada. Após isso toda requisição, tanto escrita quanto leitura, é feita em cima do fator de réplica ao enviar uma informação para o Cassandra é importante entender a diferença entre disponibilidade e consistência. Se ao realizar uma requisição for definido uma consistência alta, por exemplo, o ALL que é o número de fator de réplica defina no momento da criação/alteração do keyspace, o processo só será finalizado quando enviar para todos os nós definido. Diferente de um nível baixo, como o ONE que enviará a solicitação para apenas um nó, deixando os outros nós prontos para trabalharem em outras requisições, realizando a réplica em background elevando assim o nível de disponibilidade.


    Não existe relacionamento: Uma boa prática de para usar o Cassandra é desnormalizando sua base, desse modo, não existem relacionamentos. Se, por exemplo, você tem duas tabelas, pessoa e endereço em uma relação um para um, no Cassandra o mais correto seria uma família de coluna contendo as duas tabelas, mesmo que existam duas possas que tenham o mesmo endereço, replicando o endereço.

    Busque informações pela chave: O uso de um campo auto-increment como chave no Banco de dados deve ser evitado. Dentro do Cassandra, por padrão, o único campo no qual se pode buscar informações é a chave, caso você queria adicionar mais campos “buscáveis” basta defini-lo como índice, mas se deve evitar por questão de performance. No caso de uma tabela pessoa a chave poderia ser o cpf ou o nickname.

    O único campo obrigatório é a chave: No Cassandra o único campo obrigatório é a chave, desse modo, podem existir registros com 10, 20, 100, ou nenhuma coluna, desde que o mesmo possua uma chave. Os campos são criados por demanda, se um registro não tiver o campo “telefone”, por exemplo, ele de fato não existirá, diferente do banco relacional em que a coluna existe para todos os registros com o valor null.

    Não existe Constraints: O constraints muito utilizado para regras dos seus dados não existem dentro do Cassandra, pode parecer estranho para alguns, mas atualmente tal recurso não se torna desnecessário. Não é muito comum, por exemplo, colocar para o usuário a mesma mensagem de erro que o banco retornou como o: “there is no unique constraint matching given keys for referenced table "tec_configurations"” ou “null value in column "pessoa_nome" violates not-null constraint” e sim “nickname já cadastrado” e “campo nome obrigatório”, ou seja, as regras já estão dentro do seu software. Outro exemplo, caso se insira, utilizando um insert, a mesma informação duas vezes, vai funcionar normalmente já que a informação é apenas colocada lá, caso ela já exista será sobrescrita.


    Views materializadas: Em alguns momentos precisamos realizar cálculos em uma aplicação (somatório, média, etc.). Imaginando um sistema que mede a temperatura de uma determinada cidade e os sensores enviam informação a cada milissegundo pode-se deixar essa informação preprocessada em uma família de colunas, muito semelhante as view materializadas nos bancos relacionais. Esse recurso é muito utilizado, é muito comum se ter várias famílias de colunas como estas, o ideal é que sua modelagem seja feita de acordo com sua busca. No caso do sistema de temperatura se pode ter uma família de colunas para média por dia, mês e ano, para acompanhar o histórico de temperatura de uma cidade.

    Sua aplicação também precisa escalar: Não adianta ter um banco escalável preparado para receber mil requisições por segundo, se sua aplicação envia apenas 1 requisição por segundo. Desse modo é importante entender que sua aplicação também precisa escalar.


    Cassandra Query Language: Para facilitar a vida do desenvolvedor existe o Cassandra Query Language, o CQL. Com ele é possível criar e modificar estruturas e realizar manipulações de dados de uma maneira mais tranquila e muito mais fácil. O interessante é que esse recurso possui uma sintaxe muito semelhante ao SQL. Para executar e verificar os CQLs se pode usar o DataStax DevCenter que possui sua interface baseada no eclipse.


    Coleções muitos grandes: Um recurso que entrou recentemente no banco é o uso de três coleções: o list (uma lista de informações), o set (uma lsita sem valor duplicado), e um map (um dicionário de dados, possui um valor para uma chave correspondente). Esse recurso é muito interessante e é importante utilizado, mas tome cuidado para que essas coleções não sejam muito grandes. O interessante é que ela no geral não ultrapassagem 260KB ou 75KB.

    Acompanhe seus nós: É interessante acompanhar a performance, topologia do seu datacenter. Na configuração o recomendado é que o commitlog e o sstable estejam em discos diferentes e que esses discos sejam SSDs. Outra dica importante é ter cuidado com o tamanho do heap na maioria dos casos o padrão resolverá (é feito um calculo de heap baseado em memória disponível), caso modifique o recomendado é que não ultrapasse os 8GB. Uma solução para acompanhar seus nós é o DataStax OpsCenter.


Concluindo, nesse pequeno artigo foi demonstrado algumas dicas inicias para os usuários do Cassandra, demonstrando que é muito comum tentar simular o SQL dentro do Cassandra, tenderá a ter consequências desastrosas.

Links: 

quinta-feira, 13 de fevereiro de 2014

Easy-Cassandra, a versão 2.0.1

Lançada a nova versão do Easy-Cassandra, a versão 2.0.1, dentre as novidades podemos citar;
  • Refatoração nos contrutores das fábricas de sessão
  • QueryBuilder (InsertBuilder, UpdateBuilder, DeleteBuilder, SelectBuilder e BatchBuilder)
  • Maior velocidade na leitura e escrita
  • Suporte nos processos assíncronos
  • Maior suporte ao Cassandra com Spring-Data
Um ponto importante é que para facilitar a configuração foi criada uma classe que é passada no parâmetro, a classe ClusterInformation, dessa maneira fica mais simples (além do código mais limpo, afinal sobrecarga de construtores não é uma boa prática) de se criar simples configurações para a fábrica. Como, por exemplo:

ClusterInformation clusterInformation = ClusterInformation.create()
                .addHost(HOST)
                .withDefaultKeySpace(KEY_SPACE).withUser(USER).withPassword(PASS);
        easyCassandraManager = new EasyCassandraManager(clusterInformation);

Criando configuração para a fábrica de conexão
Dessa forma a configuração para usar o Spring no Cassandra também mudou para:





 
 
  
   localhost
  
 



 
 
  
   org.easycassandra.persistence.cassandra.spring.entity.Contact
            org.easycassandra.bean.model.Step
            org.easycassandra.bean.model.Weight
  
 



 



Nova configuração do Spring no Easy-Cassandra
Talvez a melhoria mais marcante nessa versão são os recursos dos QueryBuilders, os queryBuilders são maneiras muito mais fácil de fazer interações com o Cassandra com configurações adversas de uma maneira mais simples, com ele é possível definir o nível de consistência, definir o timeStamp, quais campos serão manipulados.

 SimpleID id = new SimpleID();
    id.setIndex(ONE_HUNDRED_THIRTY);
    id.setKey(ONE_HUNDRED_THIRTY);
    UpdateBuilder update = template.updateBuilder(SimpleQueryBuilder.class, key);
    update.put("map", "name", "otavioMap").value("value", TEN_DOUBLE).execute();

Simples exemplo inserindo valores a partir da chave
UpdateBuilder update = persistence.updateBuilder(SimpleQueryBuilder.class);
 update.whereEq(Constant.KEY, Constant.ONE).whereEq(Constant.INDEX, Constant.ONE).addList("list", "otavioList").execute();

criando toda a query de atualização
 UpdateBuilder update = persistence.updateBuilder(SimpleQueryBuilder.class);
 update.whereEq(Constant.KEY, Constant.ONE).whereEq(Constant.INDEX, Constant.ONE).value("value", 12D).executeAsync(new ResultAsyncCallBack() {
    @Override
    public void result(Boolean bean) {
        // do some action
    }
});
executando uma atualização assincronamente
InsertBuilder insert= persistence.updateBuilder(SimpleQueryBuilder.class);
Set set = new HashSet<>();
set.add("Linda");
Map map = new HashMap<>();
map.put("love", "Otavio and Poliana");
insert.value(Constant.KEY, Constant.ONE_HUNDRED).value(Constant.INDEX,
            Constant.ONE_HUNDRED).value(Constant.LIST_COLUMN, Arrays.asList("Poliana", "Otavio", "Love")).value(Constant.SET_COLUMN, set).value("map", map).execute();

Realizando inserção
  SimpleID id = new SimpleID();
    id.setIndex(ONE_HUNDRED_TWO);
    id.setKey(ONE_HUNDRED_TWO);
    SimpleBean simpleBean = new SimpleBean();
    simpleBean.setId(id);
    simpleBean.setValue(VALUE);
    InsertBuilder insert2 = persistence.updateBuilder(simpleBean);
    insert2.executeAsync((new ResultAsyncCallBack() {
    @Override
    public void result(Boolean bean) {
        // do some action
    }
    });
realizando inserção de modo assíncrono
  DeleteBuilder delete = persistence.deleteBuilder(SimpleQueryBuilder.class); 
    delete.whereEq(Constant.INDEX, ONE_HUNDRED_TWO).whereEq(Constant.KEY, ONE_HUNDRED_TWO).execute();

    DeleteBuilder delete2 = persistence.deleteBuilder(SimpleQueryBuilder.class,"map", "list", "set"); //Delete specific columns
    delete2 .whereEq(Constant.INDEX, ONE_HUNDRED_TWO).whereEq(Constant.KEY, ONE_HUNDRED_TWO).execute();

primeira query remove todas as colunas a partir da chave, na segunda query remove apenas os campos map, list e set.
 SimpleID id = new SimpleID();
    id.setIndex(ONE_HUNDRED_TWO);
    id.setKey(ONE_HUNDRED_TWO);

    DeleteBuilder delete2 = persistence.deleteBuilder(SimpleQueryBuilder.class, id);
    delete2.executeAsync((new ResultAsyncCallBack() {
    @Override
    public void result(Boolean bean) {
        // do some action
    }
    });
remoção assíncrona
  SelectBuilder select = persistence.selectBuilder(SimpleQueryBuilder.class);
  select.eq("name", "name");
  select.in("index", ONE, TWO, THREE);
  List result = select.execute();

Realizando o select em que o campo nome é igual a nome e o indice está em um, dois e três.
SelectBuilder select = persistence.selectBuilder(SimpleQueryBuilder.class);
select.eq(NAME, NAME).gt("index", THREE).asc(INDEX).executeAsync(new ResultAsyncCallBack>() {

        @Override
        public void result(List beans) {
          // do some thing
        }
    });
Executando query assincronamente em que o indece seja mais que três e seja ordenado de forma descendente no índice.
O Batch é um recurso no cassandra que permite que se execute alterações no banco (inserção, atualização e remoção) de forma atômica, desse forma se pode enviar insert, updates e deletes como se fosse apenas uma requisição.

DeleteBuilder delete = dao.deleteBuilder();
    delete.whereEq(Constant.INDEX, Constant.ONE_HUNDRED_TWO)
            .whereEq(Constant.KEY, Constant.ONE_HUNDRED_TWO);

    InsertBuilder insert = dao.insertBuilder();
    insert.value(Constant.KEY, Constant.ONE_HUNDRED).value(Constant.INDEX,
            Constant.ONE_HUNDRED);
    insert.value(Constant.LIST_COLUMN,
            Arrays.asList("Poliana", "Otavio", "Love"));

    UpdateBuilder update = dao.update();
    update.whereEq(Constant.KEY, Constant.ONE).whereEq(Constant.INDEX, Constant.ONE);
    update.addList("list", "otavioList");

    BatchBuilder batchBuilder = dao.batchBuilder();

    batchBuilder.addOperations(delete, insert, update);
    batchBuilder.executeAsync(new ResultAsyncCallBack() {
        @Override
        public void result(Boolean bean) {
            // do some action
        }
    });
Executando processo de inserção, remoção e atualização de forma atômica com o BatchBuilder.
Vale lembrar que recurso do Batch deve ser usados em casos específicos, já que distribuir as requisições entre os nós, no cassandra, sempre será sua melhor amiga.
Esse artigo tem como objetivo ilustrar as mudanças dentro do Easy-Cassandra, se demonstrou dos recursos e da sua melhoria na velocidade a expectativa é que muitos mais recursos estejam por vir.
  1. https://github.com/otaviojava/Easy-Cassandra/wiki/Builders
  2. https://github.com/otaviojava/Easy-Cassandra/wiki
  3. https://github.com/otaviojava/Easy-Cassandra/
  4. https://github.com/otaviojava/Easy-Cassandra-samples

quarta-feira, 29 de janeiro de 2014

Como compilar código Java dinâmicamente

O Java é uma plataforma que se multiplicou exponencialmente, uma de sua grande vantagem é o fato de que você consegue com o mesmo código executar em diferentes plataformas, com isso se pode programar para servidor, dispositivos embarcados, desktop, etc. com a mesma linguagem. Além disso a JVM possui suporte para diversas linguagens, das quais possuem, diversas características e recursos interessantes. Um mito que existe é que o Java não compila em tempo de execução, o que faz muitas pessoas utilizem uma linguagem dinâmica, apenas por esse objetivo, mas será que isso é verdade?

Possuir uma linguagem dinâmica é muito interessante para alguns projetos específicos, por exemplo, quando se faz um projeto que realiza calculo tributário, como essa fórmula mudam muito ao ano e variam de município para município, nesse caso é melhor que o código fonte esteja em um banco de dados, por exemplo, para quando for necessário modificar o calculo não seja necessário compilar todo o código fonte e fazer o deploy, correndo o risco do sistema ficar fora do ar mesmo que por alguns instantes.

Sim é possível em Java compilar códigos dinamicamente. Na verdade isso é muito comum do que imaginamos! Por exemplo, o Hibernate para gerenciar das entidades, para facilitar ainda o seu uso a partir da versão 1.6 com a JSR 199 foi criada um API com essa finalidade.

Para demonstrar essa funcionalidade será usado a solução para o problema acima, fazer com que haja troca de fórmula, para facilitar a demonstração e focar na solução serão as 4 operações básicas, sendo que esse código fonte estará no banco de dados, no caso será simulado com arquivos dentro de um txt. Como não podemos referenciar uma classe não compilada, criaremos uma interface Operação, ela será implementada por nossas classes que estarão em nosso “banco de dados”.

public interface Calculo { 

 Double calcular(Number valorA, Number valorB);  
  
} 

Interface na qual será utilizada como referencias as classes compiladas dinamicamente.

Explicando o processo de compilação passo a passo: A classe JavaCompiler, que tem a responsabilidade de fazer a compilação do código-fonte. A chamada ToolProvider.getSystemJavaCompiler() retorna este objeto. Se um compilador Java não estiver disponível, o retorno será null. Ele conta com o método getTask(), que retorna um objeto CompilationTask. De posse desse objeto, a chamada call() efetua a compilação do código e retorna um booleano indicando se ela foi feita com sucesso (true) ou se houve falha (false).

public class JavaDinamicoCompilador { 
 
  private JavaCompiler compiler; 

  private JavaDinamicoManager javaDinamicoManager; 

  private JavaDinamicoClassLoader classLoader; 

  private DiagnosticCollector diagnostics; 

  public JavaDinamicoCompilador() throws JavaDinamicoException { 
    compiler = ToolProvider.getSystemJavaCompiler(); 
    if (compiler == null) { 
     throw new JavaDinamicoException("Compilador não encontrado"); 
    } 

    classLoader = new JavaDinamicoClassLoader(getClass().getClassLoader()); 
    diagnostics = new DiagnosticCollector(); 

    StandardJavaFileManager standardFileManager = compiler 
        .getStandardFileManager(diagnostics, null, null); 
    javaDinamicoManager = new JavaDinamicoManager(standardFileManager, classLoader); 
  } 

  @SuppressWarnings("unchecked") 
  public synchronized Class compile(String packageName, String className, 
      String javaSource) throws JavaDinamicoException 
  { 
    try { 
      String qualifiedClassName = JavaDinamicoUtils.INSTANCE.getQualifiedClassName( 
          packageName, className); 
      JavaDinamicoBean sourceObj = new JavaDinamicoBean(className, javaSource); 
      JavaDinamicoBean compiledObj = new JavaDinamicoBean(qualifiedClassName); 
      javaDinamicoManager.setSources(sourceObj, compiledObj); 

      CompilationTask task = compiler.getTask(null, javaDinamicoManager, diagnostics, 
          null, null, Arrays.asList(sourceObj)); 
      boolean result = task.call(); 

      if (!result) { 
       throw new JavaDinamicoException("A compilação falhou", diagnostics); 
    } 

      Class newClass = (Class) classLoader.loadClass(qualifiedClassName); 
      return newClass; 

    } 
    catch (Exception exception) { 
      throw new JavaDinamicoException(exception, diagnostics); 
    } 
  } 
}
Classe responsável pela compilação

O processo de compilação envolve dois tipos de arquivos: os códigos-fonte escritos em Java e os arquivos compilados (bytecodes). Na Compiler API estes arquivos são representados por objetos de uma única interface, chamada JavaFileObject. Felizmente a API disponibiliza uma classe que implementa esta interface, chamada SimpleJavaFileObject e, na escrita de código de compilação dinâmica, deve-se criar uma subclasse de SimpleJavaFileObject e sobrescrever os métodos necessários.
public class JavaDinamicoBean extends SimpleJavaFileObject { 

  private String source; 

  private ByteArrayOutputStream byteCode = new ByteArrayOutputStream(); 

 
  public JavaDinamicoBean(String baseName, String source) { 
    super(JavaDinamicoUtils.INSTANCE.createURI(JavaDinamicoUtils.INSTANCE.getClassNameWithExt(baseName)), 
        Kind.SOURCE); 
    this.source = source; 
  } 
  
  public JavaDinamicoBean(String name) { 
    super(JavaDinamicoUtils.INSTANCE.createURI(name), Kind.CLASS); 
  } 

  @Override 
  public String getCharContent(boolean ignoreEncodingErrors) { 
    return source; 
  } 

  @Override 
  public OutputStream openOutputStream() { 
    return byteCode; 
  } 

  public byte[] getBytes() { 
    return byteCode.toByteArray(); 
  } 
}
Estrutura de dados que contem o codigo fonte e a classe compilada

Para representar os arquivos envolvidos será utilizado o ForwardingJavaFileManager que implementa a interface JavaFileManager.

public class JavaDinamicoManager extends ForwardingJavaFileManager { 
  private JavaDinamicoClassLoader classLoader; 
  
 
  private JavaDinamicoBean codigoFonte; 
 
  private JavaDinamicoBean arquivoCompilado; 
  
  public JavaDinamicoManager(JavaFileManager fileManager, JavaDinamicoClassLoader classLoader) 
  { 
    super(fileManager); 
    this.classLoader = classLoader; 
  } 

  public void setSources(JavaDinamicoBean sourceObject, JavaDinamicoBean compiledObject) { 
    this.codigoFonte = sourceObject; 
    this.arquivoCompilado = compiledObject; 
    this.classLoader.addClass(compiledObject); 
  } 

  @Override 
  public FileObject getFileForInput(Location location, String packageName, 
      String relativeName) throws IOException 
  { 
    return codigoFonte; 
  } 

  @Override 
  public JavaFileObject getJavaFileForOutput(Location location, 
      String qualifiedName, Kind kind, FileObject outputFile) 
      throws IOException 
  { 
    return arquivoCompilado; 
  } 

  @Override 
  public ClassLoader getClassLoader(Location location) { 
    return classLoader; 
  } 
}
Classe responsável por gerenciar as classes compiladas e não compiladas

Para que ela possa ser utilizada, a JVM deve ser capaz de reconhecê-la como uma classe da aplicação, a fim de que possa carregá-la quando chegar o momento. O componente responsável pelo carregamento das classes das aplicações Java durante a execução é o Class Loader.
Portanto, para que a JVM saiba da existência das novas classes compiladas, é necessário implementar um class loader customizado, que fica atrelado ao gerenciador de arquivos.
Ele deve estender a classe ClassLoader (do pacote java.lang) e tem a responsabilidade de carregar as classes recém-criadas.
Com isso foi discutido um pouco sobre a compilação dinâmica do Java no Java, objetivo aqui foi apenas de demonstrar o seu funcionamento básico além de uma pequena explicação do uso da API. Pela sua complexidade o ideal é que ela esteja encapsulado a ponto de ser utilizadas várias vezes em diversos projetos. O objetivo aqui não foi desmerecer em nenhum momento as outras linguagens de programação rodando ou não em cima da JVM, afinal todas elas têm sua importância. O objetivo foi demonstrar que não existe a necessidade de mudar de linguagem caso seu problema seja ter um código que seja compilado dinamicamente.


Referências:

quarta-feira, 2 de outubro de 2013

Cassandra Trip Brasil [Agradecimentos]

O evento Cassandra aconteceu entre os dias 2 e 6 de setembro com o objetivo de falar dos conceitos de nosql, bigdata, do cassandra e da sua arquitetura além das novidades com a nova versão, o Cassandra 2.0. O evento foi um sucesso, com isso, gostaríamos de agradecer todos que participaram e ajudaram o evento de alguma forma.
Para saber mais sobre o Cassandra, trocar experiência e tirar dúvidas técnicas ou conceituais foi criado o grupo Cassandra Trip Brasil, para mais informações aqui.
Slides utilizados no evento:
http://www.slideshare.net/bcoverston/tutorial-session
http://www.slideshare.net/edwardribeiro/cassandra-tripbrasil
http://www.slideshare.net/otagonsan/cassandra-trip
Fotos da Trip: http://goo.gl/mFVDsl
Existirá uma próxima atividade para o Cassandra que é o um mini-curso gratuito de Cassandra. No dia 10 de outubro, quinta-feira, na Global Code.
Título: Primeiros passos com o Cassandra
Descrição: 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 intensamente por empresas dos mais variados portes, tais como Netflix, Twitter, Instagram, HP, IBM, dentre muitas outras. 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 como a NASA.
Público alvo: Desenvolvedores, DBAs,  entusiastas com curiosidade de conhecer mais sobre bancos de dados nosql e o banco Cassandra.
  Ementa:
  • Conceito Data Science
  • Conceito BigData
  • NOSQL
  • Histórico
  • Tipos de Bancos
  • Comparação com o Modelo relacional
  • Cassandra
  • Arquitetura Cassandra
  • Configurações Básica do Cassandra
  • Configuração de multi-nodes no Cassandra
  • Conhecendo o DevOpsCenter
  • Instalando os Agentes

Para aqueles que não são de São Paulo:
Link : https://globalcode.webex.com/globalcode/onstage/g.php?t=a&d=662489296
Pass: cassandra
Mais informações: http://goo.gl/S3LQBm

sábado, 31 de agosto de 2013

JavaBahia e Linguágil no 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 intensamente por empresas dos mais variados portes, tais como Netflix, Twitter, Instagram, HP, IBM, dentre muitas outras. 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 como a NASA.
Com o intuito de divulgar essa idéia aqui no Brasil foi criado o Cassandra Trip Brasil, um evento com 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
  • 3 de setembro, terça-feira, Online para todo o Brasil
  • 4 de setembro, quarta-feira, Florianópolis
  • 5 de setembro, quinta-feira, Brasília
  • 6 de setembro, sexta-feira, Salvador
O evento contará com o palestrante internacional Ben Covertson que hoje faz parte do time da DataStax, empresa que mantém o banco de dados Cassandra.
O JavaBahia e o Linguágil farão parte desse evento aqui no Brasil, fazendo o encontro técnico dos grupos como parte do circuito. O encontro acontecerá na Estácio/FIB.
  • Data: 6 de setembro, Serça-Feira
  • Horário: 18:30
  • Cidade: Salvador
  • Local: Estácio/FIB Auditório do Andar G1
  • Endereço: Rua Xingu, nº 179 - Jardim Atalaia/STIEP CEP: 41770-130
Para saber mais do evento e os endereços das outras cidades que também farão parte do Trip e inscrições: http://otaviojava.github.io/cassandra-trip-brasil/

Apoio:

Estácio FIB

domingo, 25 de agosto de 2013

Usando Cassandra com Spring Data no Easy-Cassandra

Spring Data no Cassandra com 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

terça-feira, 13 de agosto de 2013

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 intensamente por empresas dos mais variados portes, tais como Netflix, Twitter, Instagram, HP, IBM, dentre muitas outras. 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 como a NASA.


    Com o intuito de divulgar essa idéia aqui no Brasil foi criado o Cassandra Trip Brasil, um evento com 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
  • 3 de setembro, terça-feira, Online para todo o Brasil
  • 4 de setembro, quarta-feira, Florianópolis
  • 5 de setembro, quinta-feira, Brasília
  • 6 de setembro, sexta-feira, Salvador

   Na terça-feira também acontecerá o web-cast aberto para todo o Brasil.

    O evento contará com o palestrante internacional Ben Covertson que hoje faz parte do time da DataStax, empresa que mantém o banco de dados Cassandra.



    Com o intuito de compartilhar experiência, tirar dúvidas, ajudar a divulgação do banco Cassandra aqui no Brasil, foi criado o Grupo Cassandra Brasil via Google Groups.