PYTHON + MONGODB

pymongo
http://api.mongodb.org/python/current/tutorial.html

implementando mongodb 2

Implementação de banco NoSQL

http://zerotoprotraining.com/index.php?mode=video&id=1305

Pensei que o MongoDB seria um bom banco para implementar em nossa projeto em vez de outro banco por motivos como:
-Sua funcionalidade: "Dados estatísticos, frequentemente escritos mas raramente lidos (por exemplo, um contador de hits na web), devem usar um modelo chave/valor como o Redis, ou um modelo de documento como o MongoDB.". No nosso projeto a frequência em que os dados são escritos é extremamente maior do que a frequência em que esses dados são consultados. 
- Diversas fontes de consultas: Aparenta ser um banco de dados com muitas dicas na internet, fácil entendimento e muitos foruns para tirar dúvidas.

Entre outros motivos citados no post anterior.

>>> http://zerotoprotraining.com/ video 1: https://www.youtube.com/watch?v=liQzIsFnCr0 - What is MongoDB?

Muito explicativo. Introduz o conceito de Nosql, comparando com os bancos sql.
Depois começa a explicar sobre o conceito de banco orientado a documento.
No MongoDB, os documentos são da forma BSON, muito parecido com o JSON. Nesse banco, para cada objeto temos campos que são pares de chave-valor. Além disso, para cada instência existe um campo obrigatório que é a id do objeto (equivalente a um chave primaria nos bancos relacionais).
Aponta também a flexibilidade comparado ao sql. Nos bancos relacionais, as instâncias de um mesmo objeto deve ter os mesmos números de campos, mas já no MongoDB isso não é necessário. Enquanto um objeto tem 3 campos, o outro pode ter apenas 2 (não esquecendo da id obrigatória).
Também fala sobre os objetos com objetos dentro, nested structures, uma estrutura de dados bem prática.
Existe linguagem para consultas!! Pode ser usado não só em aplicações big data mas também em tradicionais.


vídeo 2: https://www.youtube.com/watch?v=QcP4XExUpfA - Installing MongoDB on windows
vídeo 3: https://www.youtube.com/watch?v=HYIuXB3zk3g - Creating Database Folder and Starting MongoDB service
vídeo 4:https://www.youtube.com/watch?v=Uvw_4HW89qo - Testing Connection to MongoDB database

Alguns bancos NoSQL

1) MongoDB:
orientado a documento.
Dados estatísticos, frequentemente escritos mas raramente lidos (por exemplo, um contador de hits na web), devem usar um modelo chave/valor como o Redis, ou um modelo de documento como o MongoDB.

vantagens:
- Facil instalação
- Open Source
- Atualizações Constantes
- Suporte enterprise
- Comunidade ativa
- Drivers e ODM ( object document mapper) para várias linguagens
- Sharding automático e de fácil configuração
- Replicação simples
- Schema free
- Operações de updates atômicas
entre outras..

desvantagens:
- alto uso de espaço em disco e de memória RAM
alternativa: SSD ou $$D (como brincam)
-manutenção e operação difícil
- não tem queries

2) CouchDB 
Se você precisa reproduzir o conjunto de dados em vários locais (como a sincronização de um banco de dados de música entre um aplicativo web e um dispositivo móvel), você vai querer os recursos de replicação do CouchDB.
No CouchDB os documentos são salvos na formato JSON
https://papodecorredor.wordpress.com/2010/01/27/couchdb-resolvendo-problemas-reais/

3)Cassandra

Aplicativos de alta disponibilidade, onde a minimização da inatividade é fundamental, você encontra uma grande utilidade nos datastores de configuração redundante e clusters automáticos como o Cassandra e o Riak.

Cassandra é uma implementação de família de colunas NoSQL que suporta o modelo de dados Big Table e usa aspectos de arquitetura introduzidos por Amazon Dynamo. Alguns dos pontos positivos do Cassandra são:

• Altas escalabilidade e disponibilidade, sem um ponto único de falha
• Implementação da família de colunas NoSQL
• Rendimento de gravação muito alto e bom rendimento de leitura
• Linguagem de consulta semelhante a SQL (desde 0.8) e suporte para procura por índices secundários
• 
  
• Consistência ajustável e suporte para replicação
• Esquema flexível

Esses pontos positivos tornam fácil recomendar o Cassandra, mas é fundamental para um desenvolvedor observar os detalhes e pontos difíceis da solução para conhecer os detalhes desse programa.

Cassandra armazena dados de acordo com o modelo de dados de família de colunas, demonstrado na Figura

mais explicações: http://www.ibm.com/developerworks/br/library/os-apache-cassandra/

4)Memcached

Dados transientes (como sessões web, bloqueios, ou estatísticas de curto prazo) devem ser mantidos em um armazenamento de dados transitórios como Memcache.

http://www.ibm.com/developerworks/br/opensource/library/os-memcached/

http://www.objectzilla.com.br/2009/05/02/ja-usou-memcached.html

Próximo passo: escolher 1 para implementar

FONTES:
http://forum.imasters.com.br/topic/406606-qual-o-melhor-banco-de-dados-nosql/
http://pt.slideshare.net/fabioperrella56/no-sql-e-as-vantagens-na-utilizao-do-mongodb

NoSQL - teorema CAP

Claro que todos os benefícios não vem sem custo, comparado com os bancos de dados tradicionais vamos perder alguma funcionalidade/garantia para ganhar outra. O tradeoff arquitetural é descritono bem conhecido CAP theorem.

é preciso escolher entre consistência forte (C – Consistency), alta disponibilidade (A – availability) e tolerância a particionamento dos dados na rede(P – Network Partition Tolerance). Segundo o teorema CAP, entre as três propriedades, somente duas podem ser garantidas ao mesmo tempo.

Assim temos vários tipos diferentes de Nosql, combinando 2 das 3 características.

NoSQL Sistemas CP -> Consistência + Tolerância a particionamento de dados: é necessário abrir um pouco a mão da disponibilidade. Pode acontecer caso haja um particionamento e o sistema não entre em consenso que uma escrita seja retirada. Claro que os sistemas tentam evitar ao máximo que isso ocorra minimizando os problemas.

Exemplos: MongoDB, HBase, BigTable

NoSQL Sistemas AP -> Disponibilidade + Tolerância a particionamento: Existem sistemas que jamais podem ficar offline porém não desejam sacrificar a disponibilidade. Assim, para ter alta disponibilidade com tolerância a particionamento é necessário é preciso sacrificar sua consistência.  A ideia aqui é que os sistemas aceitam escritas sempre e tentam sincronizar os dados em algum momento depois (read-consistency). Então pode ter uma janela de inconsistência. Exemplos aqui são Amazon Dynamo, Cassandra ou Riak.

Sistemas CA (Bancos Tradicionais) -> Consistência + disponibilidade: Os sistemas com consistência forte e alta disponibilidade (CA) (alta disponibilidade de um nó apenas) não sabem lidar com a possível falha de uma partição. Caso ocorra, sistema inteiro pode ficar indisponível até o membro do cluster voltar. Exemplos disso são algumas configurações clássicas de bancos relacionais.

Diferença entre CA e CP:

Vimos brevemente o teorema CAP e a escolha que os sistemas NoSQL fazem (CP ou AP) comparado com os bancos tradicionais (CA). É importante mencionar que para o desenvolvedor não haverá tantas diferenças entre CA ou CP. SEMPRE teremos consistência forte, no entanto, um sistema fica indisponível (CA) quando há particionamento – pois tem apenas alta disponibilidade por nó – e o outro sistema (CP) tente chegar a um consenso se aceita uma escrita ou não, que no pior dos casos também pode significar a indisponibilidade para uma parte dos dados. Seguindo desse raciocínio podemos perceber que a consistência e disponibilidade são extremos quando há particionamento.

“… se há particionamento (P), o sistema pode valorizar a disponibilidade (A) ou a consistência (C), senão, quando o sistema roda sem partições, o sistema pode favorecer o tempo da resposta/latência (L) ou a consistência (C).”

FONTE:

http://blog.caelum.com.br/nosql-do-teorema-cap-para-paccl/