Problema Estratégico: Misturar DB Relacional e Não Relacional?

Question

Tem havido muita conversa sobre bancos de dados Nosql contra-revolucionários como cassandra , Couchdb , hipertable , MongoDB , Projeto Voldemort , bigtable e muito mais. No que me diz respeito, os profissionais mais fortes são escalabilidade, desempenho e simplicidade.

Eu estou considerando seriamente para sugerir usar algum db não-relacional para o nosso próximo projeto. No entanto, algumas equipes incluem alguns fanáticos de RDBMS, tão convincentes de um interruptor duro podem ser impossíveis em alguns casos apenas por razões emocionais. Além disso, quando se trata de modelos de dados complexos, eu pessoalmente ainda acredito no poder dos RDBMs com seus mecanismos de imposição de consistência de baixo nível.

Agora vem a minha pergunta: Eu queria saber, se alguém pudesse considerar seriamente usando ambos, rdbms e db não relacional em um novo projeto: o modelo de dados crítico complexo, mas não o desempenho ainda ser implementado usando um modelo relacional e DB, enquanto todo o desempenho crítico, mas modelos simples seriam implementados com um dB não-relacional. Além disso, uma mudança de paradigma tão macia seria muito mais fácil de vender para alguns membros altamente da equipe emocionalizados do que um duro.

Alguém recomendaria tal abordagem? Ou você prefere recomendar um preto ou branco, isto é, relações relacionais ou não relacionais? Todos os comentários muito bem vindos!

---

.

P.S.: Alguma ideia se tal mixagem funciona bem com a primavera e o Hibernate / JPA?

Answer 1

Rob Conery escreveu recentemente Sobre o seu Experiência construindo sua popular aplicação web Tekpub Com o MongoDB e o MySQL, destacando os pontos fortes de ambos:

.

As coisas de alta leitura (informações da conta, produções e informações do episódio) é perfeita para um "agora" tipo de coisa como MongoDB. O material "O que aconteceu ontem" é perfeito para um sistema relacionacional.

Em um alto nível, Rob quebra seus dados de aplicativos em dois escopos: dados de tempo de execução e dados históricos. O atual estado do carrinho de compras de um usuário, por exemplo, é ótimo para manter em MongoDB. É um blob de objeto que está constantemente mutante. Para manter um registro histórico do que entrou e sair do carrinho de compras; quando aconteceu; O estado do checkout é ótimo para dados tabulares relacionais no MySQL.

ele resume com isso:

.

funciona perfeitamente. Eu poderia não ser mais feliz com a nossa configuração. É incrivelmente baixa manutenção, podemos apoiá-lo como qualquer outra solução, e nós temos os dados que precisamos quando precisamos.

Atualização de maio de 2016 (6 anos depois)

Isso só se tornou mais verdade nos últimos 6 anos. Agora é comum ver bancos de dados NOSQL alimentando lojas transacionais e bancos de dados relacionais tradicionais alimentando bancos de dados analíticos.

Answer 2

Eu uso os dois.O RDBMS é bom para análise complexa, relatórios e dados acessados de diferentes maneiras por vários usuários.O NOSQL é ótimo quando estou olhando para um dado de uma perspectiva de usuários simples.Uma pergunta que me faço é: "Quem está acessando esses dados?".Se a resposta for 1 usuário, uso NOSQL para armazená-lo.

Claro, existem outras vezes quando é apropriado, mas isso é apenas um exemplo.

Como você mencionou, o NOSQL é um armazenamento mais simples, e pode fazer com que você precise corrigir código complexo para manter os dados ... por exemplo, armazenando uma lista de conexões.

Answer 3

Os bancos de dados de valor chave não relacionais são mais usados para armazenamento e armazenamento em cache BLOB.