Criando um KeySpace no Cassandra

   Neste post iremos falar de como criar um keyspace em um cluster cassandra.

   Essa criação pode ser feita por linha de comando ou por meio de interface gráfica. Para o exemplo utilizei a interface gráfica, mas também descreverei os comandos que devem ser utilizados caso queria usar linha de comando.

   O exemplo que será utilizado já foi comentado em outro post desse blog (leia) e pode ser encontrado também em http://www.datastax.com/.

Modelo de Base de Dados Relacional
Fonte: http://www.datastax.com/docs/_images/relational_model.png

   Se você instalou o seu banco de dados Apache Cassandra, como indicado em post anterior, você pode acessar o módulo de interface gráfica através do link http://localhost:8888/, em seguida selecione a opção Data < KeySpaces < Add, informe o nome do keyspace, as três opções seguintes foram deixadas seus valores padrões.

Adicionando um novo keyspace

   Com o keyspace adicionado é a hora de adicionar as columns families, a primeira inserção é sugerida ao se criar o keyspace, as demais podem ser acessadas através do caminho Column Family < Add. Adicionamos cinco columns families, que são elas: usuários, postagens, subescreve_de, subescreve_para, tempo_ordenacao_por_usuario, e todas tiveram a opção column_type alteradas de standard para Super.

Tela de adição de Column Family

   Feitas as devidas adições, ficamos com um modelo de keyspace abaixo:

Keyspace blog_cassandra

   Para fazer o mesmo que foi dito acima em linha de comando é necessário primeiramente abrir o arquivo cassandra-cli.bat, localizado na pasta bin no diretório do apache-cassandra.

   Com o terminal aberto, basta digitar create keyspace nome_do_keyspace. Em seguida é preciso acessar o keyspace para criar as columns families, o comando para acessar é use nome_do_keyspace; já para criar a column family o comando é create column family nome_da_column with column_type = 'Super' and comparator = 'BytesType' and caching = 'ALL';.

   Em um post futuro iremos tratar efetivamente de como popular a base de dados a partir de uma aplicação java.


Referências: HEWITT, EBEN. Cassandra: The Definitive Guide. Primera Edição, Editora: O'Reilly Media Novembro de 2010.
Igoreliasm, Disponível em <http://igoreliasm.wordpress.com/2012/12/20/nosql-banco-de-dados-apache-cassandra-instalacao/>, acessado em 15 de dezembro de 2014 às 14:33.

Tipos de dados no Redis - Continuação

      Dando continuidade à apresentação dos tipos de dados do Redis, vamos nesse post falar sobre: SET, HASH e ZSET.

• SET → São coleções não ordenadas de Strings que possuem um grande diferencial, não admitem guardar membros repetidos. Isso torna desnecessário checar se um determinado elemento já existe na coleção antes de inserir, mesmo que forem inseridas várias vezes um mesmo elemento, apenas uma cópia será guardada.

      Suportam operações rápidas de união, interseção e também de diferença entre coleções. O número máximo de membros num SET é 2³² - 1 (4294967295, mais do que 4 bilhões de membros por SET).

Ambiente de testes do MVJ-UFS

      A figura abaixo ilustra a não repetição de elementos reinseridos e a união entre duas listas. Uma lista completa de comandos para SET está disponível aqui.

• HASH → Hashes no Redis são mapas entre campos e valores de Strings. São o tipo de dado perfeito para armazenar objetos, como o objeto "aluno" com campos como: nome, telefone, idade, matrícula, etc. 

      Um hash com poucos campos (de um a cem por exemplo) é guardado de maneira a ocupar pouco espaço, o que torna possível guardar milhões de objetos numa simples instância. Cada hash pode guardar até 2³² - 1 pares campo-valor (mais do que 4 bilhões).

Ambiente de testes do MVJ-UFS

      A figura acima mostra o uso dos comandos: HEXISTS (verifica a existência de um atributo), HLEN (verifica o tamanho de uma HASH), HMSET (guarda uma HASH com vários atributos), HKEY (mostra todos os campos de uma HASH), HGETALL (lista campos e vlaores) e HMGET (seleciona campos para retornar o valor). Outros comandos podem ser encontrados aqui.

• ZSET → São bastante similares ao tipo SET, a diferença é que cada membro da coleção recebe um "score" que ajuda a ordenar a coleção do menor ao maior "score". São o tipo de dado mais avançado no Redis, proporciona grande velocidade de retorno de buscas e atualização de banco. Uma lista completa de ações que podem ser realizadas com ZSET está disponível aqui. A figura abaixo ilustra alguns desses comandos: ZADD para adicionar score+membros numa lista ordenada, SRANK para retornar a posição de um membro (maior RANK = maior score) e ZSCORE retorna um score de um membro.

Ambiente de testes do MVJ-UFS

Configurando uma conexão Cassandra em Java

   Nesse post iremos falar como é feito a conexão de uma base de dados Cassandra em um projeto Java.

   Utilizaremos nessa implementação a IDE Eclipse, o Apache Cassandra e o Maven 2 Eclipse plug-in.

Para instalarmos o Apache Cassandra no windows foi necessário efetuar o download aqui, neste mesmo site é possível encontrar drives e documentações para diversas linguagens.

*Primeiro Passo -
       Com o Maven instalado no seu Eclipse, crie um projeto Maven, selecione a opção "Create a simple project";

Seleção para criar um projeto Maven simples

       Em seguida informe o groupid, o artifactid e selecione o botão 'finish';
             Groupid: com.blog.cassandra
             Artifactid: cliente-cassandra

*Segundo Passo -
     Depois de criado o projeto é hora de adicionar as dependências, são os .Jar que serão utilizados pelo código-fonte. Para isso, basta clicar com o botão direito do mouse no projeto cliente-cassandra (Project Explorer), ir no menu Maven > Add Dependency e, então, a seguinte tela irá aparecer:

Tela para adicionar uma dependência Maven

     Informe os valores e em seguida selecione 'OK':
         groupid: com.datastax.cassandra
         artifactid: cassandra-driver-core
         version: 2.1.3

     Repita o segundo passo para incluir as demais dependências:
         groupid: org.slf4j
         artifactid: slf4j-api
         version: 1.7.7

         groupid: org.slf4j
         artifactid: slf4j-log4j12
         version: 1.7.5

         groupid: com.google.guava
         artifactid: guava
         version: 18.0

*Terceiro Passo -
   Crie uma nova classe no projeto e inclua um atributo cluster e dois métodos, um para conectar e outro para encerrar a conexão, como no código abaixo.

Classe conexão com métodos connect e close

   Após ter concluído essas etapas, criamos uma classe para testar a implementação: uma classe simples que cria um objeto da classe conexão. Em seguida chamamos o método connect e em seguida o método close. Obtemos então a saída abaixo:

Console da execução do código

   A saída exibe em tela o log de inicializações e em seguida o nome do cluster, nome do data center, host e rack.

  O código-fonte da solução apresentada neste post pode ser encontrada aqui.

  Nos próximos posts sobre Cassandra explicaremos como são feitas inserções e buscas em uma aplicação Java.

Referências:
    Datastax, disponível em <http://www.datastax.com/documentation/developer/java-driver/1.0/java-driver/quick_start/qsSimpleClientCreate_t.html>, Acessado em 7 de dezembro de 2014;
   Planeta Cassandra, disponível em <http://planetcassandra.org/cassandra/>, Acessado em 7 de dezembro de 2014.

Tipos de dados no Redis

       Nesse post será discutido um pouco mais sobre o Redis, mais precisamente à respeito de como ele trata alguns tipos de valores. A tabela abaixo traz um resumo dos tipos de dados do Redis.

Fonte: http://mariuszprzydatek.files.wordpress.com/2013/08/redis-data-types.png

• Strings:

      São o tipo mais básico de valor no Redis. Uma String no Redis pode conter qualquer tipo de dado, desde uma imagem JPEG até um objeto Ruby serializado por exemplo, pode ter até 512MB de tamanho em comprimento. Assim como em linguagens de programação como JAVA ou C++, há no Redis diversas funções para o manejo de Strings, como:

      - APPEND -> Usado para concatenar Strings;

      - GET -> Obtém o valor da chave.

      - MGET -> Obtém uma lista de valores a partir de uma lista de chaves.

      Uma lista completa de comandos para manejar Strings pode ser encontrado aqui. Segue imagem ilustrativa para os exemplos citados:

Ambiente de testes do blog mvjufs

• Lists:

      São apenas listas de Strings. É possível adicionar elementos tanto no início (head) quanto no final (tail) da lista. O tamanho máximo de uma lista é de 2³² - 1 elementos (4294967295, mais do que 4 bilhões de elementos por lista). A figura abaixo ilustra como adicionar elementos ao início da lista com LPUSH, obter o tamanho com LLEN, buscar um item com LINDEX e listar uma range de valores com LRANGE, outros comandos para manejar listas podem ser encontrados aqui.

Ambiente de testes do blog mvjufs

      Por enquanto é só, num próximo post traremos mais postagens acerca dos demais tipos de dados do Redis.

Referências:

Redis Data Types. Disponível em <http://redis.io/topics/data-types>. Acesso em 10/12/2014.

Importância do NoSQL nas Organizações

    Iremos abordar nesse post a relevância do NoSQL nas organizações, quando é válido o seu uso e quando não é aconselhável.

    A maioria das soluções de sistemas de informação fazem uso de um banco de dados para gerenciamento de informação, mas como saber quando é indicado o uso de um banco de dados relacional ou um banco de dados NoSQL?

Fonte: http://blog.izenda.com/wp-content/uploads/2013/05/SQL-600x309.png

    Com o aumento do fluxo de dados e necessidade do uso de dados mais complexos em aplicações atuais, que não poderiam ser tratados de forma nativa por bancos relacionais, surgiu O NoSQL  para tratar de problemas desse tipo.

    Por exemplo, em sistemas de informações comuns, que não operam em grandes volumes de dados não é indicado o uso do NoSQL. O uso de NoSQL não traria ganhos significativos em aplicações como: RP's, controle de estoque, fluxo de caixa, entre muitas outras soluções.

     Em contrapartida, há casos em que aplicar a tecnologia não-relacional melhora eficiência e performance de determinadas aplicações. Soluções que geram número elevado de dados, ou ainda, usam tipos de dados incomuns, terão uma fluidez maior.

    Como exemplo de organizações que fazem uso de projetos não-relacionais temos o Facebook, o eBay, Google, Netflix, entre muitas outra organizações de nível e uso mundiais.

Banco de dados NoSQL Orientado a Grafos

Representação de um banco de dados orientado a grafos

(Fonte: http://www.computerweekly.com/feature/Whiteboard-it-the-power-of-graph-databases)

      Neste post iremos apresentar mais um tipo de modelo de dados NoSQL, que são os banco de dados orientado a grafos.

      Os banco de dados orientado a grafos foram desenvolvidos a partir do ramo da matemática conhecido como teoria dos grafos, que se originou no século XVIII pelo matemático Leonhard Euler.

      Assim como a teoria dos grafos, os bancos orientado a grafos usam conceitos como nós, arestas e propriedades para representar e armazenar os dados. E cada elemento no banco possui um ponteiro direto para seu elemento adjacente.

      Se você trabalhou com modelo de objetos ou diagramas de entidade-relacionamento, o modelo orientado a grafos vai parecer familiar. O modelo orientado a grafos contém entidades conectadas (nós) que podem conter tipos e propriedades (pares de chave-valor) arbitrários. Os nós podem ser marcados com diferentes rótulos para representar suas diferentes regras de domínio. Além de contextualizar nós e propriedades de relacionamento, os rótulos dados servem também para anexar metadados ou informações de restrição, por exemplo, para nós.

Exemplo da construção modelo orientado a grafos

(Fonte: http://neo4j.com/developer/graph-database/)

      Os relacionamentos possuem direção, fazendo uma uma conexão semântica entre os nós. Uma relação tem sempre um sentido, um tipo, um nó de início, e um nó final. Assim como os nós, os relacionamentos podem ter propriedades arbitrárias. Na maioria dos casos, as relações têm propriedades quantitativas, como pesos, distâncias, classificações, intervalo de tempo ou pontos fortes. Como os relacionamentos são armazenados de forma eficiente, dois nós podem ter qualquer número ou tipo de relações entre eles sem secraficar o desempenho. E, embora os relacionamentos são direcionados, eles podem sempre ser navegados em ambos os sentidos.

Representação da estrutura dos dados orientado a grafos.

(Fonte: http://dev.assets.neo4j.com.s3.amazonaws.com/wp-content/uploads/2010/03/shop-categories-erd.png?_ga=1.52640488.1517740388.1415768885)

      Os principais banco de dados orientado a grafos atualmente, são: Neo4J, Horton, HyperGraphDB, AllegroGraph e Oracle Spatial and Graph.

Referências:

Graph database

Disponível em <http://en.wikipedia.org/wiki/Graph_database>. Acessado em 05/12/2014.

What is Graph database

Disponível em <http://neo4j.com/developer/graph-database/>. Acessado em 05/12/2014.

Whiteboard it - the power of graph databases

Disponível em <http://www.computerweekly.com/feature/Whiteboard-it-the-power-of-graph-databases>. Acessado em 05/12/2014.

Banco de dados MongoDB

(Fonte: http://www.mongodb.com/)

      Neste post iremos conhecer um pouco sobre o banco de dados NoSQL orientado a documentos mais popular no mercado, o MongoDB.

      O MongoDB foi projetado inicialmente pela empresa 10gen com o intuito ser um banco de dados orientado a documentos de sua plataforma de nuvem.  Após perceber o potencial do software, a 10gen decidiu cancelar sua plataforma de nuvem e se concentrar em manter o MongoDB. Em 2009, a 10gen converteu o MongoDB para um projeto de código aberto.

      Fazendo uma analogia com os banco de dados relacionais, a estrutura do MongoDB pode ser entendida da seguinte forma:

Comparação SQL e NoSQL

(Fonte: http://krishnasblog.com/2012/06/02/understanding-document-based-mongodb-nosql/)

      No MongoDB cada registro é realmente um documento. Os documentos são armazenados em um formato BSON (Binary Serializable JSON objects). E o MongoDB suporta consultas em JavaScript para recuperar os objetos BSON.  Os documentos BSON são objetos que contém uma lista ordenada de elementos salvos. E cada elemento é constituído por o nome do campo e um tipo específico de valor.

Exemplo de objeto no MongoDB

(Fonte: http://docs.mongodb.org/manual/core/data-model-design/)

      Algumas características positivas no MongoDB, são:

• Consultas elabordas: Além de poder acessar os dados por meio de chaves, é possível fazer uma consulta em relação a campos especificados e variações dinamicamente na consulta, e também é possível consultar com expressões regulares.
• Índice Secundário: Assim como pode-se fazer consultas em relação a campos especificados, pode também definir estes campos como índices secundários, para aumentar a performance de acesso ao dado.
• Replicação Mestre-Escravo: Controla as operações de leitura e escrita para separar servidores, executando um servidor escravo como um servidor mestre quando o servidor mestre estiver inacessível.
• Sharding: Possibilita o processo de armazenamento de registros de dados em vários servidores para atender as demandas de crescimento de dados.
• MapReduce: Processa grandes volumes de dados em paralelo, dividindo o trabalho em um conjunto de tarefas independentes.
• Suporte de drivers para várias linguagens de programação.

Referências:

Understanding document based MongoDB NoSQL

Disponível em <http://krishnasblog.com/2012/06/02/understanding-document-based-mongodb-nosql/>. Acessado em 04/12/2014.

NoSQL Concept and MongoDB

Disponível em <https://www.ma-no.org/en/content/index_nosql-concept-and-mongodb_1736.php>. Acessado em 04/12/2014.

What is MongoDB

Disponível em <http://www.mongodb.com/what-is-mongodb>. Acessado em 04/12/2014.

Redis, Um banco NoSQL Key/Value

Redis significa Remote Dictionary Server, é um banco NoSql do tipo Key/Value, tem licença BSD, sendo completamente livre de custos. Pode conter dados de diversos tipos como: strings, hashes, listas, conjuntos, bitmaps entre outros. Ou seja, apesar de ser do tipo Key/Value, o Redis destaca-se de outros por poder trata de valores mais complexos.

É escrito em ANSI C e funciona com a grande maioria dos sistemas POSIX, tais como Linux, BSD e OSX sem que seja necessária a instalação de quaisquer dependências externas. Não há suporte oficial para Windows, entretanto a Microsoft mantém um port para WIN-64 que pode ser encontrado aqui.

Fonte: http://blog.concretesolutions.com.br/wp-content/uploads/2013/01/redis-300dpi.png

Quanto ao uso de memória, seguem alguns números do Redis, por exemplo, uma instância vazia usa em torno de 1 MB, um milhão de pequenas chaves que guardem pares de strings, ocupará cerca de 100 MB, um milhão de chaves hash que representem um objeto com cinco campos, utilizará algo em torno de 200 MB.

Quanto aos limites, pode manejar até 2³² chaves e já foi testado na prática com até 250 milhões de chaves, sem comprometimento de desempenho. É um banco de dados "in-memory", possui portanto alta velocidade de leitura e escrita, pode trabalhar em conjunto com outras bases de dados de armazenamento em disco, inclusive bases SQL.

O processo de salvar em disco ocorre em background, sempre que não houver comandos em execução no banco.


Referências:
redis.io - Acessado em 4/12/2014.

Banco de Dados NoSQL Orientado a Documentos

(Fonte: http://www.infoq.com/articles/Transition-RDBMS-NoSQL/)

      Como já vimos em posts anteriores, existem quatro tipos principais de modelo de dados NoSQL. São eles: Chave-Valor, Orientado a Documentos, Orientado a Colunas  e Orientado a Grafos.

      Neste post iremos nos focar nos banco de dados orientado a documentos.

      Um Banco de dados orientado a documentos é um projeto para armazenamento, recuperação e gerenciamento orientado a documentos ou semi-estruturas de dados.

      Os Banco de dados orientado a documentos são uma das principais categorias de banco de dados NoSQL. Um exemplo é o banco de dados MongoDB que é orientado a documentos e está em 5º lugar no ranking dos banco de dados mais populares segundo a DB-Engine.

(Fonte: http://www.bestonlinecourses.info/intro-to-nosql-and-mongodb/)

      Este modelo armazena uma coleção de documentos. No caso, um documento é representado como um objeto, que possui um código único e um conjunto de campos, que podem ser strings, listas ou outros objetos aninhados. 

Exemplo de uma tabela no modelo orientado a documentos

(Fonte: http://docs.couchbase.com/couchbase-devguide-2.0/)

      As estruturas desses campos se parecem com a estrutura dos campos no modelo Chave-valor (Key-value). No modelo Chave-valor, uma única tabela hash é criada para todo o banco de dados. Já no modelo orientado a documentos, temos um conjunto de documentos (objetos) e em cada documento temos um conjunto de chaves (campos) cada um com sua chave (key).

Modelo Chave-valor

(http://labs.sogeti.com/nosql-whats-in-it-for-me/)

Modelo Orientado a Documento

(Fonte: http://labs.sogeti.com/nosql-whats-in-it-for-me/)

      Uma característica importante deste modelo é que ele não depende de um esquema rígido, ou seja, não há obrigação de uma estrutura fixa. Sendo assim, pode-se fazer uma atualização na estrutura do documento sem causar nenhum problema com ao banco de dados. Por exemplo, a adição de novos campos ao documento não causará nenhum problema no banco. Essa facilidade e flexibilidade em atualizar a estrutura dos documentos é uma das grandes e principais vantagens do modelo orientado a documentos.

      Por mais que existam diferentes implementações de banco de dados orientado a documentos, em geral, todos assumem a função de encapsular documentos e codificar dados (ou informações) em algum formato padrão (ou codificação). As codificações em uso incluem XML, YAML, JSON e BSON, assim como formas binárias, como imagens, PDF, documentos do Microsoft Office (MS Word, Excel) e assim por diante.

Referências:

11 Open Document-Oriented Databases Wich comes under NoSQL DB Category!

Disponível em <http://orangeslate.com/2011/12/06/11-open-document-oriented-databases-which-comes-under-nosql-db-category/>. Acessado em 03/12/2014

DB Engines Ranking

Disponível em <http://db-engines.com/en/ranking>. Acessado em 03/12/2014.

NOSQL BASE X ACID TEOREMA CAP

Disponível em <http://pt.slideshare.net/Celio12/trabalho-no-sql-aricelio-de-souza?next_slideshow=3>. Acessado em 03/12/2014.

Cassandra - Modelo de Dados

    Já apresentamos uma visão geral do Projeto Apache Cassandra e agora iremos ver como é composto o modelo de dados para esses bancos. Iniciaremos esse post falando dos conceitos utilizados para isso.

    O modelo de dados faz uso de Column (coluna), SuperColumn (super coluna), ColumnFamily (família de colunas) e KeySpace (espaço chave), mas o que vem a ser cada item?

Column - unidade mais básica do modelo de dados, é composta por um trio de atributos: um nome, um valor e um relógio (clock). Diferente do modelo relacional não existe uma pré-definição, o nome e o valor são do tipo vetor de bytes, podendo variar em tempo de execução, já o relógio é do tipo timestamp.

SuperColumn - tipo especial de coluna que armazena um nome e um valor, sendo o valor um mapa de sub-colunas. Dessa maneira uma super coluna pode ter um número ilimitado de colunas, mas não pode armazenar outra super coluna.

ColumnFamily - espaço que contém uma coleção ordenada de linhas, onde para cada linha existe uma coleção ordenada de colunas. Eles são semelhantes as tabelas nos bancos de dados relacionais, mas sem ficar preso a uma estrutura pré definida.

KeySpce - recipiente mais externo aos dados, podendo ser associado a um banco de dados relacional, contendo um nome e um conjunto de atributos que definem seu comportamento. Uma aplicação pode conter mais de uma keyspace, mas é comum existir apenas uma por solução.

Fonte: http://www.datastax.com/docs/_images/cassandra_model.png

    Na figura temos o exemplo de um blog, por isso o keyspace dele é chamado de blog. As columnFamily são users, blog entries, subscribes_to, subscribers_of e time_ordered_blogs_by_user.

    Na columnFamily users temos a superColumn jbells, que possui uma column chamada name com valor jonathan e outra column chamada state com valor TX, o mesmo vale para dhutch (super coluna), já para egilmore vemos que só existe a coluna name, não havendo necessidade de outras colunas.

    Em um post futuro veremos como é feito a criação de um keyspace, bem como o preenchimento e as buscas.

Fonte: HEWITT, EBEN Título: Cassandra: The Definitive Guide, Primera Edição, Editora: O'Reilly Media Novembro de 2010.

      http://www.datastax.com/docs/1.0/ddl/about-data-model, acessado em 1 de dezembro de 2014;

      http://nivaldomjunior.blogspot.com.br/2010/07/entendendo-o-banco-de-dados-nosql.html, acessado em 1 de dezembro de 2014.