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.

Projeto Apache Cassandra

   O cassandra é um projeto de banco de dados distribuído, que se enquadra no tipo tabular do NoSQL, reunindo a arquitetura do Dynamo, da Amazon e possui modelo de dados baseado no BigTable, do Google.
   Ele possui escalabilidade linear e alta disponibilidade, sem perda de desempenho, possui também tolerância a falhas em hardware ou infraestrutura de nuvem, sendo a plataforma ideal para dados em missão crítica. Da suporte, best-in-class, a replicações em vários data centers, tendo uma menor latência para usuários.

Fonte: http://upload.wikimedia.org/wikipedia/commons/thumb/5/5e/Cassandra_logo.svg/2000px-Cassandra_logo.svg.png

Visão Geral

Utilização
    O cassandra está sendo utilizado por mais de mil e quinhentas empresas que possuem grande volume de dados ativos, entre elas está GitHub, eBay, GoDaddty, Instagram, Netflix.
    Entre as maiores implementações em produção está a da Apple, com mais de 75000 nós de armazenamento, ultrapassando os 10 Pb (dez petabytes) de dados. Temos também a Netflix com 2500 nós, 420 Tb (quatrocentos e vinte terabytes) e uma requisição diária superior a 1 trilhão de dólares, além da eBay com mais de 100 nós e 250 Tb (duzentos e cinquenta terabytes) de dados.

Tolerante a Falhas
   Possui uma replicação de dados automática entre nós, além de dar suporte a replicação entre vários data centers.

Performance
    Supera de forma consistente alternativas populares do NoSQL em referência e aplicações reais, graças as escolhas arquitetônicas fundamentais.

Descentralizado
    Não há pontos únicos de falha, nem gargalos da rede, já que cada nó no cluster é idêntico.

Controle
    Replicações síncronas ou assíncronas para cada atualizações.As operações assíncronas de alta disponibilidade são otimizados com recursos.

Elástico
    O rendimento de leitura e escrita aumenta linearmente a cada nova máquina adicionada, sem tempo de inatividade ou interrupção.

Referência:
http://cassandra.apache.org/

Exemplo de Banco NoSQL: Amazon Dynamo DB

É hora de dar início à exemplos práticos e atuais de bancos de dados NoSQL, alguns exemplos de ferramentas serão apresentadas nos próximos posts sobre os diferentes tipos de bancos NoSQL , aqueles previamente citados na postagem sobre tipos de arquitetura: Document, Key/Value, tabular e graph.

Um dos bancos escolhidos a serem aqui apresentados é o Amazon DynamoDB, desenvolvido e mantido pela Amazon Web Services, do grupo de empresas Amazon.

Fonte: http://cloudacademy.com/blog/wp-content/uploads/2014/07/amazon_dynamodb.png

O DynamoDB é destinado à aplicativos de mobilidade, web, jogos, tecnologia de anúncios, IoT (internet das coisas) e vários outros tipos. É compatível com os modelos de dados de documento e de chave-valor e promete latência consistente abaixo de 10 milissegundos, para os aplicativos que assim necessitem.

Uma versão gratuita para execução do DynamoDB no cliente pode ser baixada aqui, trata-se de um arquivo ".jar" executável e compatível com diversos sistemas operacionais, tais como Linux, Mac OSX e Windows. Entretanto, para poder utilizar o mesmo depois de instalado, é necessário que o usuário tenha uma conta na AWS (Amazon Web Services), onde o usuário deve informar o número de seu cartão de crédito para poder ser cobrado automaticamente e em seguida continuar a utilizar os serviços da Amazon.

O DynamoDB seria utilizado por este blog, entretanto suas políticas a quesito de licenças de uso impossibilitaram que isso ocorresse. O DynamoDB é um serviço pago, a versão gratuita promete 25 GB de armazenamento e disponibilidade de até 12 meses de testes, mas alguns pontos não muito claros em seu contrato de uso fez com que os escritores deste blog desistissem de testá-lo.

Referências:

Amazon DynamoDB. Disponível em <http://aws.amazon.com/pt/dynamodb/>. Acesso em 28/11/2014.
DynamoDB Local. Disponível em <http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Tools.DynamoDBLocal.html>. Acesso em 28/11/2014.

Evolução dos Bancos de Dados

    Toda mudança gera incomodo e resistência, afinal algo que já está em vigor vai perder sua estabilidade, sua comodidade será desfeita, mesmo que isso tenha demandado bastante tempo e investimento.

    As primeiras bases de dados foram as hierárquicas IMS (Sistemas de Gerenciamento de Informação). Eram bem aceitas no mercado, muitos programas e empresas faziam uso dessas ferramentas por disporem de uma solução prática. A IBM tinha uma ferramenta já difundida para garantir isso, o DB2, até que, poucos anos depois, um outro cientista da própria IBM, Dr. Edgar F. Codd, elaborou um novo trabalho fundamentado na teoria relacional (Veja aqui). Era o início dos bancos de dados relacionais, tais como são conhecidos hoje.

Fonte: http://upload.wikimedia.org/wikipedia/en/5/58/Edgar_F_Codd.jpg

    Essa mudança gerou uma enorme resistência, agora os desenvolvedores teriam que aprender uma nova linguagem, uma linguagem específica, o SQL. Era preciso mudar a maneira como se pensavam as soluções, além de contabilizar todo o desperdício do que foi investido nas soluções já existentes. Mas todos os esforços se justificavam, ele tinha elaborado o aplicativo mais bem sucedido da história.

    Na atualidade essa solução já não resolve mais totalmente os problemas do mundo. Com o aumento das informações geradas diariamente as bases de dados vem crescendo muito. Essas bases de dados fazem uso dos Join's, que é um recurso de uso comum e por isso pode tornar as consultas lentas. Já os SGBDs fazem uso de bloqueios (Locks) para manter sua característica ACID (Atomicidade, Consistência, Isolamento e Durabilidade) e permitir o uso concorrente, deixando-o indisponível por um momento, com isso, cargas pesadas, como as que temos hoje em dia, deixam os locks insustentáveis, por gerarem filas para leitura e escrita em uma base de dados.

    Uma solução para este problema seria em primeiro momento melhorar o hardware, mas com o passar do tempo o mesmo problema voltaria, então, mais que mudar o hardware seria necessário rever a solução de banco de dados para diminuir o uso de join's e remover qualquer processamento de XML e estruturas semelhantes, nas Stored Procedures. Com o resultado pouco expressivo, como uma última tentativa poderia ser feito uma desnormalização e violação dos 12 mandamentos de Codd para dados relacionas, numa esperança de se conseguir níveis toleráveis de desempenho, mesmo tendo uma solução não "pura".

    Assim sendo, fez-se necessário uma nova solução, não mais apenas uma base de dados relacional, e sim uma base de dados com facilidade para alcançar tolerância a falhas, com disponibilidade em vários data-centers, consistente e escalável, mesmo para centenas de terabytes. Foram essas características que fizeram surgir um novo conceito, o NoSQL, um conceito que não menosprezou as soluções existentes, mas sim ajudou a solucionar falhas que elas tinham.

   É importante salientar que os três modelos - hierárquico, relacional e não relacional - coexistem na atualidade, podendo derivar soluções a partir dos três.

"Se eu perguntasse a meus compradores o que eles queriam, teriam dito que era um cavalo mais rápido" (Henry Ford)

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

NoSQL na Gestão da Informação

    A gestão da informação tem como atividades: busca, identificação, classificação, processamento e disseminação da informação. Atividades encontram suporte, de maneira direta, nas bases de dados não estruturadas, tão quanto nas estruturadas.

Fonte: http://stefanini.com/br/wp-content/uploads/2013/09/PDTI-plano-diretor-de-TI.jpg

    Busca - As buscas podem ser feitas em bases de dados maiores e em tipos de dados diferentes, com um desempenho, muitas vezes, superior aos bancos relacionais.

  Identificação - A identificação é feita com base no critério de busca e fica disponível ao interessado a confirmação e análise do que foi retornado.

  Classificação - As classificações, feitas em tempo de consulta, dão uma flexibilidade maior ao critério desejado. Podem ser feitas também no momento de uma inserção, quando é escolhido o local lógico de armazenamento.

     Processamento - Por termos um ambiente distribuído, o processamento é feito em nós distintos, tendo assim um poder de processamento maior.

   Disseminação - Como em qualquer base de dados, a disseminação é feita, muitas vezes, a partir das informações armazenadas nestas bases de dados de grande desempenho, tornando assim o processo muito eficaz.

    Esse suporte é necessário para auxiliar no processo de tomada de decisão, fator crucial e determinante para o crescimento e sucesso de uma organização.

NoSQL - Tipos de Arquitetura

Saudações,

       Dando continuidade aos posts sobre o NoSQL, vamos agora deixar o histórico de lado e começar a falar do NoSQL em si. Primeiramente é observado que o NoSL pode ser trabalhado em diversos tipos de arquitetura, a figura abaixo ilustra uma divisão em quatro tipos primordiais:

Fonte: http://image.slidesharecdn.com/ravendb-130924150155-phpapp01/95/nosql-ravendb-with-net-4-638.jpg?cb=1385088848

        Vamos agora a alguns detalhes específicos de cada um desses tipos:

• Chave/Valor (Key/Value) - As soluções NoSQL menos complexas se enquadram aqui. O nome chave valor define o comportamento deste tipo, pois toda a base de dados está indexada de modo que, para todo valor armazenado há uma chave específica para ele.

•  Tabular (Armazenamento em Colunas) - Em vez de armazenar os dados em fileiras, armazenam tabelas de dados como seções de colunas de dados. Essa descrição pode levar o leitor a crer que o tipo Tabular trata-se apenas do inverso de uma base de dados convencional, entretanto ele é muito mais poderoso do que parece. Armazenamentos em colunas oferecem excelente desempenho e caracterizam-se por ser uma base de dados altamente escalável.

 

• Documento - Podem ser descritos como uma forma mais desenvolvida do tipo Chave/Valor. As chaves aqui não se associam a um único valor, mas sim a um documento inteiro.

 

• Grafos - Esse tipo baseia-se na teoria dos grafos. São destinados para dados cujas relações possam ser bem representadas por grafos e que possuam elementos que estejam interconectados, sem que se determine um valor para essas interconexões.

Isso é tudo por hoje, nas próximas postagens iremos cada vez mais a fundo na busca do conhecimento acerca do NoSQL e suas particularidades.

Referências:

GANDLA, Phani Krishna Kollapur. Migration of Relational Data structure to Cassandra (No SQL) Data structure. Disponível em <http://www.codeproject.com/Articles/279947/Migration-of-Relational-Data-structure-to-Cassandr>. Acesso em 19/11/2014.

MATHUR, Ankit. Up Close and Personal With NoSQL. Disponível em <http://www.opensourceforu.com/2011/02/up-close-and-personal-with-nosql/>. Acesso em 20/11/2014.

What Is NoSQL. Disponível em <http://planetcassandra.org/what-is-nosql/>. Acesso em 20/11/2014.

Por que o NoSQL é usado em grandes Sistemas de Informação?

Em junho de 1970, Edgar Codd publicou um artigo na Revista ACM com o título "Relatinal Model of Data for Large Shared Data Banks" (Modelo de Dados Relacional para Grandes Banco de Dados Compartilhados). Ele demostrou os fundamentos do banco de dados relacional, usando tabelas ("linhas" e "colunas") e operações matemáticas para manipular dados (SELECT, SUM, UNION, etc).

Na década de 90, após a criação de hardwares de computadores mais eficientes, o Modelo Relacional foi usado em larga escala e passou a ser o principal método de armazenamento de dados nos SGBD (Sistema de Gerenciamento de Banco de Dados).

Nos dias atuais, começamos a ver aplicações cada vez mais produzindo grande variedades de dados. E esta grande variedade de dados originou uma preocupação na estrutura do banco de dados, nos níveis de escabilidade e disponibilidade dos dados. Daí surge o termo NoSQL.

Os Banco de Dados NoSQL (not only SQL) não suportam o modelo relacional e não usam o SQL para consulta. Eles possuem uma grande facilidade na distribuição horizontal dos dados, ou seja, mais dados, mais servidores, não necessariamente de alta performance. Um exemplo é a Google, que utiliza computadores de pequeno e médio porte, que passa a ser uma forma eficiente e econômica. Sem contar que os banco de dados NoSQL são mais tolerantes a erros que os relacionais.

Nos banco de dados NoSQL, toda a informação estará agrupada no mesmo registro, em vez de ter a informação através do relacionamento entre várias tabelas para formar esta.

Vantagens dos banco de dados NoSQL

• É possível fazer coisas que não eram possíveis com o poder de processamendo e consulta dos banco de dados relacionais tradicionais.
• Dados são flexíveis e escaláveis.
• Existe um novo modelo de dados a ser considerado. Você não precisa forçar os dados para serem apenas relacionais.
• A escrita no banco de dados é muito rápida.

Desvantagens dos banco de dados NoSQL

• Não existe um padrão comum. Cada banco de dados faz diferentes coisas.
• Consultar dados não envolve uma familiar consulta SQL.
• Banco de dados NoSQL são relativamente imaturos e de constante evolução, porque tentam evitar problemas com a ACID (Atomicidade, Consistência, Isolamento, Durabilidade) nos dados.

REFERÊNCIAS:

Why NoSQL database is used by Facebook, Google and LinkedIn Applications? Disponível em <http://blog.outsourcing-partners.com/2012/10/why-nosql-database-is-used-by-facebook-google-and-linkedin-applications/>. Acesso em 13/11/2014.

NoSQL - você realmente sabe do que estamos falando? Disponível em <http://imasters.com.br/artigo/17043/banco-de-dados/nosql-voce-realmente-sabe-do-que-estamos-falando/>. Acesso em 13/11/2014. 

NoSQL - Breve Histórico

O termo NoSQL foi trazido à  público na década de 90, quando um homem chamado Carlo Strozzi, criou um banco de dados open source, que não possuía uma interface SQL. O banco de Strozzi guardava todos os dados em arquivos ASCII e fazia uso de shell scripts em lugar de SQL para acessar os dados. Entretanto esse banco de dados em nada se relaciona com como é conhecido atualmente o NoSQL e Strozzi não fazia a menor idéia que o nome exposto por ele se tornaria importante e popularizado pouco mais de uma década

Carlo Strozzi

O termo NoSQL, como apresentado e a ser estudado mais a fundo neste blog, foi debatido pela primeira vez em 2009. Trazido à pauta por um funcionário da empresa Rackspace, Eric Evans, durante uma reunião promovida por Johan Oskarsson, que na ocasião trabalhava como desenvolvedor na Last.fm, que visava discutir as então novas tecnologias no mercado de TI.

Apesar de não ter sido nenhuma tentativa de rotulação ou imposição, o termo NoSQL usado na reunião serviu muito bem para caracterizar um grande número de bancos de dados que vinham sendo criados sem ter a menor preocupação com as famosas garantias ACID (Atomicidade, Consistência, Isolamento e Durabilidade). O nome também pode ser visto como uma brincadeira com nomes de famosos e amplamente utilizados bancos de dados, como MySQL, MS SQL, PostgreSQL etc.

Logo não oficial

Atualmente existem 150 bancos de dados oficialmente reconhecidos como sendo do padrão NoSQL, a lista encontra-se disponível no site http://nosql-database.org/. Lá é possível acessar a página de cada uma dessas 150 base de dados e obter diversas informações a seu respeito.

Uma boa fonte de informação sobre as principais novidades no mundo NoSQL encontra-se no blog NoSQL Databases, mantido por um alemão, o professor Dr. Stefan Edlich, cujo perfil no blogger pode ser acessado aqui.

Este blog buscará manter os leitores sempre atualizados com as novidades sobre NoSQL, bem como proporcionar a oportunidade de o leitor conhecer mais a fundo aspectos técnicos a respeito da tecnologia não relacional.

REFERÊNCIAS:

A BRIEF HISTORY OF NoSQL. Disponível em <http://blog.knuthaugen.no/2010/03/a-brief-history-of-nosql.html>. Acesso em 13/11/2014.

NoSQL. Disponível em <http://www.w3resource.com/mongodb/nosql.php>. Acesso em 13/11/2014.

BLOG: NoSQL DataBases. Disponível em <http://nosql-databases.blogspot.com.br/>. Acesso em 13/11/2014.

World of the NoSQL databases. Disponível em <http://leopard.in.ua/2013/11/08/nosql-world/>. Acesso em 13/11/2014.

Piloto

    Bem vindos ao blog MVJ. Este blog é destinado aos acadêmicos e profissionais da área de TI que tem interesse em conhecer, ou que já conhece, o NoSQL.

    Teremos como colaboradores das postagens os alunos da Universidade Federal de Sergipe, do curso de Sistemas de Informação, João Geraldo de Santana Oliveira, Matheus Mendonça Menezes e Vanderson Santana de Oliveira Leite Sampaio. Além da supervisão do professor doutor Douglas Dyllon Jerônimo de Macêdo.

    Nessa primeira postagem iremos explicar o que é NoSQL. Espero que seja de valia à todos os leitores.

   O que é NoSQL?

    NoSQL é uma alternativa aos bancos de dados relacionais por possuir alta escalabilidade e desempenho. Os bancos de dados que se enquadram nesse novo conceito não exigem o uso de tabelas fixas e muitas vezes não dão suporte às instruções e operações de junção da linguagem SQL.

    Essa tecnologia visa solucionar problemas encontrados para o armazenamento de dados não relacionais, buscando apresentar ferramentas, de forma particular e específica, para grandes volumes de dados, armazenamento de documentos do tipo XML ou JSON (modelos de dados flexíveis), entre muitos outros casos.

   É possível perceber que o NoSQL não tem a finalidade de substituir os bancos de dados relacionais, mas sim encontrar soluções para casos que esse modelo não oferece um resultado efetivo. Sendo assim, é viável trabalhar tanto com tecnologias NoSQL quanto com bancos de dados relacionais em uma mesma aplicação.

Referências:

DevMedia, http://www.devmedia.com.br/websys.5/webreader.asp?cat=6&artigo=3180&revista=javamagazine_87#a-3180 , acessado 11 de novembro de 2014;

Wikipedia, http://pt.wikipedia.org/wiki/NoSQL, acessado 11 de novembro de 2014.