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.