De fato o post tem umas caneladas em relação ao Redis

Quanto ao armazenamento, a classificação dele seria “Configurável”. Por padrão, o Redis faz um snaspshot do que está armazenado em memória e salva isso no disco a cada X minutos ou X modificações. Como o dirs falou, pode-se usar também persistência via append only, que funciona de forma semelhante a um transaction log de um rdbms, e é configurável em relação a quando é feito o fsync com o disco. E se vc quiser, pode desabilitar tudo isso e usar como um cache em memória apenas.

Quanto ao modelo de dados, ele é mais do que só chave/valor. Acho que o redis teria uma categoria própria, algo do tipo “Banco distribuído de estruturas de dados básicas”, já que nele vc pode armazenar os dados em listas, sets, tabelas hashs.. ou seja, as estruturas de dados que os tios da computação ensinam nos primeiros períodos da faculdade

Oi Felipe,

Interessante o seu questionamento. Você vai notar em muitas descrições de bancos NoSQL como o Cassandra esta característica de ser um bando distribuído. Quando estamos falando de banco de dados o termo não se refere diretamente a “Sistemas Distribuídos” que muitos aprendem na faculdade e sim a um conceito especifico.
O fato de um banco ser ou não distribuído não está de modo algum relacionado diretamente ao aumento proporcional do poder de processamento. O conceito se refere a um banco de dados que funciona de maneira distribuída ou seja é como se você tivesse uma única instancia de banco que funciona ao longo de varias maquinas
sendo que isto é na maior parte dos casos completamente invisível ao desenvolvedor. Perceba que isto é diferente de simplesmente replicar um banco em esquemas Master/Slave como é feito com o Redis nestes casos o que você tem são instâncias diferentes de banco que se comunicam. Nos bancos distribuídos como é o caso do HBase que funciona sobre o HFS ( equivalente open source ao GFS, Google File System ) você tem o processo de replicação e acesso as várias máquinas feito pelo próprio gerenciador automaticamente.

Caso você queira se aprofundar mais no assunto veja as seguintes páginas da documentação do CouchDB :

Na introdução do CouchDB ( http://couchdb.apache.org/docs/intro.html)

What CouchDB is
…
Distributed, featuring robust, incremental replication with bi-directional conflict detection and management.
…

No Technical Overview ( http://couchdb.apache.org/docs/overview.html )

CouchDB is a peer-based distributed database system, it allows for users and servers to access and update the same shared data while disconnected and then bi-directionally replicate those changes later.

Outro ponto..

“Quando estamos falando de banco de dados o termo não se refere diretamente a “Sistemas Distribuídos” que muitos aprendem na faculdade e sim a um conceito especifico. “

Não quero ser rude, mas “quanto estamos falando”.. quem?

Eu entendo um banco distribuido como um sistema distribuido de banco de dados. Oracle, cassandra, etc..

Existe uma diferença conceitual entre banco de dados e sistemas de gerenciamento de banco de dados.

O couchdb tem seu banco de dados distribuidos. OK. Os dados realmente estão distribuidos.

O sistema de gerenciamento de banco de dados do couchdb não é distribuido. Ele não é capaz de realizar como um sistema distribuido, ou seja, na sua definição, processamento paralelo, todo o dominio de suas funções

DB != RDBMS.. é simples..

Como voce se atém muito a detalhes, vamos la. O couchdb se diz um banco de dados distribuido. Não é. É um sistema de gerenciamendo de banco de dados com replicação.

É falácia se vender como distribuído porque quem escolher o Couchdb para sua aplicação e instanciar 10 nós em 10 máquinas diferentes, vai ver que o desempenho de escrita é amarrado ao nó de pior performance.

As suas menções a papers e artigos da wikipedia não te ajudam em nada porque no final das contas oq vc esta afirmando é: basta ter várias instancias distribuidas e essa distribuição ser transparente pra dizer que um banco é distribuido.

Pra mim, é necessário muito mais que isso… é necessário que todo o dominio de operações possa ser processado paralelamente entre os nós para que exista um ganho em poder de processamento.

Do proprio site de stanford que voce mencionou..

Distributed database systems employ a distributed processing architecture.

Bancos de dados distribuidos empregam uma arquitetura de processamento distribuido.

O meu ponto todo é de que é injusto colocar Cassandra e Couchdb como distribuidos, na mesma categoria..A 'distribuição' do couchdb é parcial.. do cassandra é total.. como o autor do post disse q existem 3 caracteristicas que classificam os bancos NoSQL, por favor, pelo menos separe o couchdb do cassandra e dos outros… o couchdb tem uma limitação séria e ele não funciona como a maioria das pessoas vai achar q ele funciona..

só isso..

O próprio pessoal do Redis se define como “advanced key-value store” ou como “data structures server” .
Não acredito que o fato de ter values como estruturas mais complexas faz com que o Redis deixe de ser considerado key-value.

Quanto ao armazenamento o Redis eu não consideraria Configurável. O padrão como o Sana disse é gravar de tempos em tempos no disco. Ou seja no modo padrão do Redis os dados não são armazenados direto no disco. E mesmo caso você escolha persistir tudo em disco o que você vai ter será um tipo de arquivo de backup para reconstruir o estado do banco na memória, até onde eu sei não tenho a opção de configurar o Redis para usar disco ao invés de memória o que a principio mataria a própria premissa do banco.

Eu acho que entendi o seu ponto. Vc sugere uma categorização por um critério diferente. Ao invés de distribuição, vc quer categorizar pela capacidade de gravar em paralelo, é isso?
Eu concordo que os bancos orientados a documentos tem aplicações bem diferentes de um cassandra ou um hbase.
Seu ponto é que dentro dos bancos distribuídos teriamos 2 categorias de bancos, separadas pela capacidade distribuir e paralelizar processos?

É interessante comparar a evolução do NoSQL com o estado da arte do mercado de banco de dados *antes* que o SQL varresse a concorrência, lá em meados nos anos 90.

Quem mexia com software em PCs nos anos 80 certamente se lembra de sistemas como o dBase, de onde vieram depois o Clipper e o FoxPro, e também das bibliotecas de indexação. Era comum ter que implementar algoritmos como B-Tree manualmente, para gerar os arquivos de índice. Nos mainframes, existiam diversas soluções, várias delas eram do tipo “file of record” (quem já leu um programa em COBOL sabe do que eu estou falando). Nessa época, a maioria dos programadores jamais tinha ouvido falar do que seria um “join”.

Nessa época, o trabalho com banco de dados era caracterizado por uma mentalidade de “processamento em lotes”. Um programa fazia um loop sobre uma tabela (oops, “arquivo”) e ia buscando dados em outros, para compor o resultado desejado. Para otimizar o processo, os índices eram mantidos manualmente. Era comum gravar resultados parciais e agregados dentro das próprias tabelas, para evitar um loop completo sobre o arquivo (obs: qualquer semelhança com a nova onda de denormalização nao é mera coincidência). Isso era especialmente importante se você considerar a taxa de transferência dos discos da época. Outra técnica comum era dispor de programas que deveriam ser executados uma vez por dia, manualmente ou de forma agendada, para limpar registros deletados, compactar índices, e recalcular agregados.

A migração em massa para o SQL aconteceu em meio a uma revolução composta de vários fatores. As novas interfaces gráficas permitiram separar a camada de apresentação da camada de negócio. O conceito de “cliente servidor” encontrou estações poderosas para rodar “clientes ricos”, e servidores com novas tecnologias (NT!) capazes de rodar programas genéricos com relativa facilidade. A capacidade de processamento e memória dos servidores tornou o overhead da interpretação da linguagem SQL aceitável. E a capacidade (e velocidade) dos HDs foi crescendo, viabilizando a manutenção de bases cada vez maiores e mais sofisticadas dentro do servidor.

O uso intensivo do SQL gerou como efeito colateral uma postura “comodista” em relação ao banco de dados. Ao contrário da geração anterior, a maioria dos programadores que aprendeu sua profissão nos últimos 10 ou 15 anos jamais teve que se preocupar com os “detalhes ocultos” do banco de dados. Eu acredito que isso é um dos culpados pela percepção prevalente de que “SQL não escala”. Na verdade, SQL “padrão” tem problemas e limites de escalabilidade, que se tornam evidentes na escala de um Google, Facebook ou Twitter. No entanto, para a maioria dos programadores, o problema não é o SQL em si, mas a falta de conhecimento sobre como o banco de dados funciona.

É interessante olhar as coisas sob essa perspectiva histórica, porque ela nos mostra de forma muito clara que vários problemas que tratamos hoje com NoSQL já existiam antigamente, em outro nível de escala e de performance, mas seguindo princípios muito similares. A grande diferença do cenário atual para aquele de 20 anos atrás está no uso intensivo de paralelismo e comunicação em redes (praticamente inexistentes até o fim dos anos 80); mesmo assim, por mais simplista que possa parecer, algumas das técnicas mais recentes tem raízes no antigo processamento em lotes. O que estes exemplos nos mostram é que existem técnicas simples para contornar vários problemas; com um pouco de criatividade, e com *muito* pragmatismo, é possível criar soluções inteligentes e largamente escaláveis. Só que isso exige que o programador tenha um conhecimento mínimo sobre a arquitetura do banco de dados e seu funcionamento interno – coisa que para a maioria dos programadores, é como falar grego. Daí, fica mais fácil aderir a uma nova onda – que é o NoSQL mas poderia ser qualquer outra coisa, sem que necessariamente tenham conhecimento suficiente para explorar as plataformas atuais ao máximo.

Digo isso tudo para argumentar que o SQL “tradicional” ainda tem MUITA lenha para queimar, especialmente agora que o assunto está sendo tratado seriamente. Para mim, o mais importante no debate do NoSQL não é o “not only” e nem mesmo o “no” que alguns insistem em lembrar; é trazer para a discussão aspectos da tecnologia que muita gente jamais se preocuparia em pesquisar, se não fosse o tema da moda.

Depende do caso. Em um dos projetos de onde eu trabalho, notamos que em produção, é feito em torno de 150 selects pra cada insert/update (somados)

Portanto, otimizamos somente para leitura, o que tornou o processo muito menos complicado