Trabalhar com bancos de dados e desenvolvimento de software é, ao mesmo tempo, uma arte e uma habilidade. Como toda habilidade, pode ser treinada para chegarmos àquela sensação de recompensa quando as coisas funcionam. Assim, nada melhor do que utilizar as ferramentas certas – de acordo com cada necessidade – para facilitar nosso trabalho. Quando o assunto é NoSQL, um conjunto de ferramentas que funcionam muito bem juntas são python e mongoDB.

Por que mongoDB?

O MongoDB é um banco de dados de alta performance orientado a documentos e é open source. Por ser orientado a documentos (JSON) não possui transações nem joins. Resultado? Fazer consultas é algo muito simples – são mais fáceis de escrever e mais fáceis de ajustar. Outras características que o torna tão interessante:

  • Auto – Sharding – o conceito de sharding é simples: quanto você trabalha com uma grande quantidade de dados e está no limite de disco e/ou a falta de espaço, a solução para este problema é ter os seus dados divididos entre várias máquinas.
  • Indexes – fáceis de criar e excelentes otimizadores de consultas – falaremos no futuro sobre como criar e gerenciar seus indexes.
  • Caso seja necessária a inserção de novos atributos, é possível inseri-los apenas nos documentos necessários sem precisar criar uma nova coluna e atribuir um valor a todos os documentos (registros no sql) na tabela relacionada.

Mas por que Python?

Para quem ainda não conhece, python é uma linguagem orientada a objetos, open-source, desenvolvida no início dos anos 90. O que a torna tão especial é sua sintaxe extremamente simples aliada às suas poderosas funções e bibliotecas. Nos últimos anos, tem surgido como a linguagem utilizada para ensino de Machine Learning pois, com poucas linhas de código, é possível implementar inúmeros algoritmos.

Utilizando-se desta poderosa estrutura, vamos conectar o Python ao mongoDB utilizando a biblioteca pymongo, disponível na versão 2.5.1  em

https://pypi.python.org/pypi/pymongo/

Primeiros Passos

Vamos demonstrar abaixo o básico para se trabalhar em conjunto com estas duas ferramentas.

 

import pymongo

# Para conectar com o banco de dados
myConnection = pymongo.Connection("mongodb://localhost", safe=True)
## é uma boa prática usar safe=True, para garantir que o MongoDB verifique a existência de erros

# Para selecionar uma base de dados
myDB = myConnection['NFL']

# Para selecionar uma collection (análogo as tabelas nos bancos relacionais)
myCollection = myDB['NYGiants']

# Para fazer uma consulta de um único documento
myQuery = myCollection.find_one({'posicao':'qb'})

print myQuery

## Se o resultado da consulta for mais de um documento, para exibí-los use o código
         #for cada_doc in myQuery:
	       #print cada_doc

# Para inserir um novo documento
inserir = myCollection.insert({
			'nome':'Leandro',
			'posicao':'defender',
			'ultimaPartida' : True
			}
			)
## a variável 'inserir' armazenará o _id do novo documento

# Para contar o número de documentos
conta = myCollection.count()
print str(conta) + ' documentos'

# Por fim, para atualizar um documento
myCollection.update(
		{'_id': inserir
			#Equivalente à cláusula where do SQL
		},
		{'ultimaPartida' : False}
		)

# Para apagar um documento
myCollection.remove({
			'nome':'Leandro'
				},safe = True)

Até o próximo post!

default

1º passo – Faça o download no site da Fundação Apache da última versão -http://cassandra.apache.org/.
2º passo – Descompacte o arquivo na raiz do C:

3º passo – Você deverá configurar uma variável ambiente chamada CASSANDRA_HOME que aponte para o seu diretório de instalação do Cassandra. Para isso clique em Meu computador com o botão esquerdo do mouse e vá na opção Propriedades, clique em Configurações Avançadas do Sistema e em Variáveis de Ambiente, na opção Variáveis do Sistema clique em Novo e adicione a variável conforme a imagem.
 
4º passo – Execute o Cassandra, se aparecer a mensagem de erro como o da imagem abaixo é porque você não tem instalado no seu computador o Java.

5º passo – Faça o download no site da Oracle -http://www.oracle.com/technetwork/java/javase/downloads/jdk6-jsp-136632.html e instale em seu computador.
6º passo – Agora você precisará configurar uma variável ambiente chamada JAVA_HOME que aponte para o seu diretório de instalação do Java. Para isso clique em Meu computador com o botão esquerdo do mouse e vá na opção Propriedades, clique em Configurações Avançadas do Sistema e em Variáveis de Ambiente, na opção Variáveis do Sistema clique em Novo e adicione a variável conforme a imagem

7º passo – Execute novamente o Cassandra e se aparecer a mensagem: “Listening for thrift clients…” o Cassandra está funcionando corretamente. Agora é só se divertir.

 

 

Nesse tutorial vou falar como fazer uma replicação utilizando o CouchDB. Para isso vamos usar o Couch na nuvem e uma versão local. Existem algumas nuvens que oferecem esse serviço na web. Nesse tutorial eu vou usar o Iris Couch http://www.iriscouch.com/ . Bastar criar uma conta simples lá que eles já te dão acesso ao couchDB na nuvem. Para nosso tutorial ele vai funcionar muito bem.

Inicialmente vamos abrir o Futon localmente, que é a interface para trabalhar com couchDB:

 

Iniciamos fazendo o login na parte inferior direto da tela. Caso seja a primeira vez com o login, você irá criar um usuário e senha.

Agora vamos criar um banco chamado teste_replicacao. Para criar o banco basta clicar no link “Create Database” que fica quase no topo dessa tela. Após o click irá aparecer um pop-up para digitar o nome do banco. Então basta digitar: teste_replicacao e aperte no botão “Create” que se encontra nesse pop-up.

Pronto, seu banco está criado e irá aparecer nessa tela:

Image Hosted by ImageShack.us

Agora vamos criar um documento para ser o nosso teste. Nessa mesma tela tem um link chamado “New Document”. Basta clicar nele.

Image Hosted by ImageShack.us

Após cadastrar algumas informações nesse documento basta salvar ele no link “Save Document”. O meu documento de teste ficou assim:

Image Hosted by ImageShack.us

Após salvar o documento, ele cria automaticamente o atributo _rev que o Couch usa para fazer a revisão do documento.

Após a criação desse documento vamos criar o documento de replicação. Esse documento vai mandar esse documento que criamos como teste para o couch que está hospedado lá na nuvem(Iris).

Lá na tela inicial onde listas todos os bancos que você criou, tem uma linha chamada “_replicator”. Quando você clicar nesse link você será redirecionado para todos os documentos de replicação que você já criou.

Nessa tela tem também tem o link para criar um novo documento. Vamos clicar nesse link e criar nosso arquivo de replicação:

{

“_id”: “local_para_iris”,

“source”: “http://admin:admin@127.0.0.1:5984/teste_replicacao”,

“target”: “http://admin:admin@minhaNuvem.iriscouch.com/teste_replicacao”,

“continuous”: true

}

Source: A base de dados original a ser replicada.

Target: A base de dados criada para receber os dados replicados.

Continous: Tenta realizar a replicação em um loop (caso ocorra algum erro). O tempo para a replicação é exponêncial em relação á primeira tentativa.

Os dados que o Source e o Target receberão são compostos por:

  • admin:admin o usuário e senha das bases (a ser replicada)
  • @ local onde se encontra a base de dados / o nome da base de dados.

Salve o documento e pronto. Sua replicação está feita. Lembrando que você tem que tem que criar o mesmo banco lá na sua nuvem. Não precisa criar o documento, só o banco.

Para você vê o andamento da sua replicação, basta você ir no menu Status que fica a direita no Futon.

Nesse menu você consegue vê sua replicação funcionando.

Então é isso.

Autoras: Eliane Mara Casagrande e Jésika Pellegrini.

Histórico

Cassandra foi desenvolvido pelo Facebook para ajudar no funcionamento da caixa de busca do Facebook e armazenar/vasculhar todas as mensagens das caixas de entrada dos usuários. Foi liberado sob licença Open Source em julho de 2008. Cassandra começou como um projeto de incubação da Fundação Apache em janeiro de 2009. A primeira versão a ser lançada foi a 0.3 em março de 2010, encontrando-se atualmente na versão 1.1.6. Implementado em Java ele foi fortemente influenciado pelo Dynamo, da Amazon, pioneiro na criação de um banco de dados do tipo chave/valor. Cassandra implementa um modelo de replicação de dados parecido com o Dynamo – sem nenhum ponto único de falha. Porém a forma de armazenar os dados é mais semelhante ao Google Bigtable (orientado a colunas).

Cassandra se tornou tão popular por causa de suas excelentes características técnicas. É durável, facilmente escalável, eventualmente consistente e tolerante a falhas. Pode armazenar centenas de terabytes de dados com suporte para replicação em vários datacenters, é descentralizado e sem nenhum ponto único de falha, cada nó do cluster é idêntico. É altamente disponível e oferece um esquema livre de modelo de dados. Além de a administração do banco ser mínima.

Modelo de dados

O modelo de dados do Cassandra é projetado para dados distribuídos em uma escala muito grande, ou seja, milhares de dados distribuídos e replicados ao longo de várias máquinas (nós) que operam em conjunto de maneira a aparecem como uma única instância para o utilizador final. Desta forma Cassandra provavelmente não é a melhor escolha se você só precisa executar um único nó.

Cluster

A estrutura mais externa do Cassandra é o cluster, às vezes chamado de anel e é um recipiente para os keyspaces. Um cluster pode e geralmente tem mais de uma máquina ou nó que mantém uma réplica para diferentes faixas de dados. Se o primeiro nó para de funcionar, uma réplica pode responder a consultas. O protocolo peer-to-peer permite que os dados sejam replicados entre os nós de uma forma transparente para o usuário, e o fator de replicação é o número de máquinas do cluster que irá receber cópias dos mesmos dados.

Keyspace

Um keyspace é o contêiner mais alto para dados no Cassandra. O keyspace corresponde a um banco de dados no mundo relacional e assim como no mundo relacional os keyspaces possuem nomes e atributos que definem o seu comportamento. O Cassandra permite a criação de vários keyspaces por cluster ou aplicação, uma prática que não é muito recomendada. Por exemplo, se seu aplicativo é chamado Twitter, você provavelmente teria um cluster chamado Twitter-Cluster e um keyspace chamado Twitter.

Em Cassandra, os atributos básicos que podem ser definidas por keyspace são:

Replication factor: O fator de replicação refere-se ao número de nós que atuarão como cópias (réplicas) de cada linha de dados inseridos . Se o seu fator de replicação é 3, então, três nós no anel terão cópias de cada linha inserida, e essa replicação é transparente aos clientes. O fator de replicação essencialmente permite você decidir o quanto você quer pagar em desempenho para ganhar mais consistência. Ou seja, o seu nível de consistência para a leitura e escrita de dados baseia-se no fator de replicação.

Replica placement strategy: refere-se a forma como as réplicas serão colocados no anel. Existem diferentes estratégias para determinar quais nós vão receber as cópias de que chaves (keys), que podem ser:

 SimpleStrategy – usada por padrão esta estratégia replica os dados em único data center, de uma forma que o usuário não tem noção da sua colocação no rack de dados.

OldNetworkTopologyStrategy  - utilizado para distribuir os dados em diferentes racks no mesmo data center. Indicado para quando quiser assegurar alta disponibilidade no acesso aos dados.

NetworkTopologyStrategy  - possibilita especificar como as réplicas dos dados serão colocados nos data centers.

Column Family: da mesma forma que uma base de dados relacional é um recipiente para tabelas, um keyspace é um recipiente para obter uma lista de uma ou mais famílias de coluna. Cada keyspace tem pelo menos uma e frequentemente muitas famílias de coluna.

Column Family

Uma família de coluna é aproximadamente análogo a uma tabela no modelo relacional, e é um recipiente para uma coleção de linhas. Cada linha contém colunas ordenadas. Column family representam a estrutura de seus dados.

No mundo relacional, quando você cria fisicamente seu banco de dados a partir de um modelo, especificando o nome do banco de dados (keyspace), os nomes das tabelas, e em seguida, defini os nomes das colunas que estarão em cada tabela.

Mas as semelhanças param por aí, Cassandra é considerado livre de esquema porque, embora as column family são definidas, as colunas não são. Você pode adicionar livremente qualquer coluna para qualquer column family a qualquer momento. Uma column family possui dois atributos: um nome e um comparador (indicada como as colunas serão organizadas quando retornadas por uma query). As colunas estão armazenadas em arquivos separados no disco, é importante manter colunas relacionadas definidos em conjunto na mesma coluna família.

Super Column Family

É um conjunto de colunas, ou seja, para cada linha da ColumnFamily, podemos ter SuperColumns que possuam várias colunas. Por padrão column families são configuradas com o tipo Standart, para uma super column Family você configura seu padrão para o tipo super.

Column

Situada dentro de uma column family ou super column Family, a coluna é a unidade mais básica da estrutura de dados no modelo de dados Cassandra. Uma coluna é composta de um nome, um valor e um timestamp. Os tipos de dados para o nome e valor são matrizes de bytes Java, frequentemente fornecidos como strings. Uma vez que o nome e o valor são tipos binários, que podem ser de qualquer comprimento. O campo timestamp funciona como uma bússola verificando o campo mais atual entre as replicas.

Exemplo modelo de dados do Cassandra:

Fonte: Adaptado de Demoiselle Cassandra

Na imagem acima tem-se um exemplo simplificado do banco de dados do Twitter, onde:

O Twitter Cluster é a estrutura mais externa, e possui duas máquinas (nós) conectados (nó 01 e nó 02), todos os dados salvos ou alterações feitas no nó 01 são replicados no nó 02, assim se uma das máquinas parar de funcionar, o sistema não cairá e o usuário conseguirá acessar normalmente sua conta e suas informações. O keyspace Twitter possui 3 columns families – users, following e followers. Na column Family Users existem 3 usuários cadastrados, a usuária Iara não informou sua idade e nem seu peso ao criar sua conta, desta forma, estas duas colunas não existem, o que economiza espaço na memória e é uma das grandes vantagens do Cassandra, no momento em que ela cadastrar estas informações no sistema, o Cassandra automaticamente criará a coluna para salvar estes dados. Quando a usuária Iara passou a seguir a usuária Nice, criou-se uma nova coluna para salvar o nome do usuário que ela passou a seguir (column family Following), ao mesmo tempo em que adicionou-se uma nova coluna na usuária Nice para que ela possa saber quem começou a segui-la (column family Followers).

Mais informações em : http://cadmintool.blogspot.com.br/

Referências:

Apache Cassandra: The Definitive Guide – http://bigdata.googlecode.com

The Apache Software Foundantion – http://cassandra.apache.org

Demoiselle Cassandra –

http://demoiselle.sourceforge.net/docs/guide-cassandra/1.0-v1/html_single/

DATASTAX – http://datastax.com

Primeiramente antes de tudo, o trabalho de conclusão de curso é uma espécie de pesadelo que atormenta várias pessoas, que pretendem se graduar em um determinado curso superior. E como é de se esperar, escolher um campo de estudo e elaborar um tema é uma tarefa difícil.

Comigo não foi diferente, pois decidi fazer meu trabalho abordando os novos tipos de bancos de dados, que solucionasse algo para tal situação. Mas antes de tudo, pensar em um tema que fosse abordar um problema e uma possível solução estava difícil. E assim várias possibilidades
de tema foram surgindo com os novos bancos de dados (BD), que foram especialmente criados para soluções distribuídas : os bancos de dados Not Only SQL (NoSQL).

Os BD NoSQL surgiram para solucionar os problemas dos BD relacionais, tais como problemas de escalabilidade e desempenho. Há também o custo computacional que é necessário para alcançar solucionar estes principais problemas. Em ambientes distribuídos por exemplo a  Internet, utilizando um BD relacional como meio de armazenamento de dados de uma aplicação Web, por exemplo uma rede social,  conseguimos facilmente chegar a estes dois problemas, o qual gera lentidões no tráfego de dados pela Internet.

Assim, analisando este caso tenho dois problemas e uma possível solução, onde para escalar uma aplicação na Web devemos ter meios e/ou mecanismos de armazenamento de dados, que possibilitem de forma simples e fácil, chegar a escalabilidade e conseguir um bom desempenho.
Portanto escalar é incorporar os limites físicos à questão do desempenho.

Então várias ideias foram surgindo conforme analisava este caso. Pode-se citar alguns  possíveis trabalhos utilizando BD NoSQL, onde o foco é conseguir um bom desempenho em aplicações Web no qual há um acesso aos dados, de forma concorrente e massiva:

  • replicação de BD relacional para BD NoSQL;
  • estudo de replicação de um determinado BD NoSQL;
  • comparativo entre BD relacional e BD NoSQL, mostrando as suas diferenças e casos de usos em situações reais;
  • estudo comparativo com uso de Benchmark; e
  • outros inúmeros possíveis temas abordando os BD NoSQL.

Podemos ver que há um grande campo a se explorar nesta área, onde o mais interessante dos BD NoSQL tem de vantagem : a liberdade de modelagem dos dados, sem a necessidade de um padrão, o que rompe o império de mais 30 anos dos BD relacionais, bem conhecidos por grande parte dos desenvolvedores de aplicações Web e Desktop.

Portanto, a princípio tomei a decisão de  efetuar um comparativo entre um BD NoSQL e um BD relacional, no qual resultou em um pequeno projeto de Benchmark entre o MongoDB e MySQL.

Porém, meu orientador pediu para restringir o comparativo apenas para BD NoSQL, o qual iria estudar apenas os dois bancos de dados mais utilizados. Mas como há vários tipos de BD NoSQL, escolhi um BD orientado à documentos (MongoDB) e um orientado à colunas
(Cassandra).

Encontrar materiais sobre ambos os BD NoSQL, encontrei nos sites de cada um destes BD,  o qual todo estava em inglês. Basicamente é uma selva a desbravar, pois foi um desafio conseguir referências sobre o assunto geral, sendo o NoSQL uma tecnologia nova, no qual a maioria dos
materiais referentes ao assunto estão em inglês, porém graças ao grupo NoSQL Brasil no Facebook, encontrei muitas referências interessantes.

Portanto, o meu trabalho resulta a um estudo comparativo, baseado em um Benchmark baseado no OSDB – Open Source Databases Benchmark, o qual é apenas utilizado em BD relacionais, adaptando-o para BD NoSQL.

Então, a ideia geral do meu trabalho é fazer um Benchmark entre dois BD NoSQL (MongoDB e Cassandra), como mencionado é baseado no  OSDB. Assim, o OSDB é composto por 3 módulos:

  • módulo de estrutura e carga;
  • módulo mono-usuário; e
  • módulo multi-usuário.

Sendo estes três módulos que ajudarão na obtenção dos resultados, no qual estou fazendo os  testes de desempenho, onde coleto o tempo de resposta de cada BD. Logo mais terei o resultado final do Benchmark entre os dois BD NoSQL, onde cada um destes possuí uma característica própria, por exemplo o modelo de dados de ambos são diferentes porém poderosos, capazes de armazenar informações  diversas e de forma rápida, o que impressiona a forma como estes trabalham.

Bom é isso galera, espero ter ajudado a vocês que talvez estejam em dúvida do que estudar, que tema abordar, qual BD NoSQL estudar.

No post passado o Douglas mostrou alguns problemas que ele estava tendo e como resolveu, nesse caso ele esta usando DBRef e algumas pessoas já vieram me perguntar se é aconselhável usar, então vou falar algo que sempre falo nas minhas palestras: depende.

Ta mas por que depende?

Depende da modelagem do seu objeto, pois quando você referencia um objeto com DBRef você sempre irá consultá-lo quando o seu objeto “pai” for consultado, ou seja, se você estiver referenciando um objeto que vai crescer bastante isso irá onerar bastante sua consulta, logo nesses caso é melhor você criar a referencia manualmente com _id.

Fora que você só irá conseguir utilizar seu objeto referenciado após um fetch(), o qual te limita a manipulação desse objeto.
The drivers [1] do not automatically resolve DBRefs into documents

Mas se ele me limita tanto por que usá-lo?

Bom eu aconselho a usar o DBRef quando seu objeto referenciado for pequeno e não for aumentar ou caso sua collection possa mudar de nome, pois nesse caso fica mais fácil para atualizar os valores. Também é aconselhável para objetos que você sempre quer pegar seus valores. Por exemplo uma listagem de pacientes em que o meu sistema sempre vai querer saber quais são seus remédios, nesse caso o uso do DBRef é muito aconselhável. Exemplo de estrutura: https://gist.github.com/3858732

Espero ter dado uma clareada em seus pensamentos e qualquer dúvida é só comentar aqui.

Antes de falar um pouco da minha experiência com o MongoDB, gostaria de agradecer a oportunidade disponibilizada pelo Suissa para compartilhar essa informação no NoSQLBr. Muito obrigado!!

Há meses estou submerso em um projeto que utiliza o MongoDB, foi escolhido depois de uma longa discussão com a equipe, sua eficiência e agilidade de processamento, quando bem configurado a coisa fica monstra. Porem me deparei com um problema que deve afetar todos ao trabalhar com um banco de dados NoSQL a FORMA DE SE PENSAR E PROJETAR o banco. Como sempre trabalhei com banco de dados relacionais, projetei o MongoDB de forma idêntica a um banco de dados relacional e ai começou a minha dor de cabeça. Estava tendo que tirar leite de pedra para alimentar um monstrinho com muita fome, ou seja, tinha que ter um esforço fora do comum para alimentar um aplicativo que exigia informações relacionadas e simples ao usuário final. Por exemplo:

[Usuários] -> Onde são cadastrados todos os usuários.
[Amigos] -> Onde são cadastradas os relacionamentos dos amigos de cada usuário.

Sendo assim em um banco relacional teríamos isso:

[Usuário] 1 -> N [Amigo]

Foi ai que deu inicio ao caos (rssss). Na hora de resgatar algumas informações tinha um trabalho imenso e neste caso estava tendo que executar dois processos.

1 – Listar os ID’s que estavam na tabela de Amigos
2 – Verificar os ID’s encontrados no passo 1 e verificar suas informações

Em PHP seria algo assim:

 

<?php
…
$collection = new MongoCollection($db, 'amigo');
$query = array('idUsuario' => new MongoId(123));

$list = $collection->find($query);
foreach ($list as $value) {
$temp[] = new MongoId($value->idAmigo);
}
…

$collection = new MongoCollection($db, 'usuario');

$queryAmigo = array('_id' => array('$in' => $temp));
$listAmigo = $collection->find($queryAmigo);



 

// Executaria dois processos… para algo relativamente simples, agora

// imagine um relacionamento envolvendo mais tabelas…

?>

Solução do problema:

<?php

$conexao = new Mongo(); // Iniciando uma conexão com o MongoDB

$db = $conexao->testandoomongo; // Criando uma base de dados

// Usuarios inseridos.

$db->usuarios->insert(array("_id"=>1,"name"=>"User01"));

$db->usuarios->insert(array("_id"=>2,"name"=>"User02"));

$db->usuarios->insert(array("_id"=>3,"name"=>"User03"));

// Criando referencia de um usuario.

$infoUser = $db->usuarios->findOne(array('_id' => 2));

$refUser = $db->usuarios->createDBRef($infoUser);

// Adiciona a referencia

$db->usuarios->update(array('_id'=>1),array('$push'=>array('amigos'=> $refUser)));

// Consulta o usuario 1

$consulta = $db->usuarios->findOne(array("_id"=>1));

foreach ($consulta["amigos"] as $con) {

// pega a referencia do usuario

$ref = $db->usuarios->getDBRef($con);

print_r($ref);

}

?>

Então comecei a perceber que estava na hora de mudar a forma de pensar e de utilizar o MongoDB. Quando pensar em MongoDB pense como se fosse um grande objeto. Abaixo listei 3 dicas que não esquecerei jamais:

1 – Não utilize técnicas de banco relacional no MongoDB;
2 – Pense que as tabelas do MongoDB são grandes objetos que a qualquer momento podem mudar sua forma “física”;
3 – Quando for programar tente ao máximo utilizar o raciocínio lógico, explorando ao máximo seu objeto evitando o excesso de processamento do MongoDB.

Grande abraço a todos e fica a dica, qualquer coisa manda a dúvida que agente discute e tentar encontrar a melhor solução. Valeuuu!!

“Imagine uma aplicação que deve manter as informações relativas a viagens e locais onde pessoas moraram. Com isso, deve ser possível saber quando uma pessoa viajou ou qual o período em que ela viveu em determinada cidade.”

Nesse artigo da Caelum podemos perceber como a modelagem em grafos é mais simplista que a relacional e como devemos trabalhar com eles.

artigo: http://blog.caelum.com.br/trabalhando-com-relacionamentos-bancos-de-dados-baseados-em-grafos-e-o-neo4j