Quando você deve usar um documento versus banco de dados relacional versus gráfico? [fechadas]


29

Para fins de discussão, vamos considerar um cenário do FourSquare.

Cenário

Entidades:

  • Comercial
  • Lugares

Relacionamentos:

  • Checkins: usuários <-> lugares, muitos para muitos
  • Amigos: usuários <-> usuários, muitos para muitos

Design do Banco de Dados

É provável que esses erros apresentem erros, indique-os.

RDBMS

Tabelas:

  • Comercial
  • Lugares
  • Checkins (junção)
  • Amigos (junção)

Prós:

  • CAP: consistência, disponibilidade

Contras:

  • CAP: tolerância de partição, também conhecida como sharding
  • esquemas = estrutura inflexível
  • má replicação?

Gráfico

Objetos:

  • Comercial
  • Lugares

Arestas:

  • Amigos: Usuário <-> Usuário
  • Checkins: Usuário -> Locais
    • contém carimbo de data e hora

Prós:

  • CAP: consistência, disponibilidade?
  • objetos e bordas facilmente esquemáticos e sem esquemas
  • consultas transversais ao gráfico, por exemplo:
    • agrupamento
      • encontrando grupos de amigos
      • encontrar restaurantes gostados por pessoas semelhantes
    • alguma outra consulta comum / útil?

Contras:

  • CAP: tolerância de partição?

Documento / Objeto

3 bancos de dados separados?

  • Comercial
    • lista de amigos
  • Checkins
    • timestamp
    • do utilizador
    • Lugar, colocar
  • Lugares

Prós:

  • CAP: disponibilidade, tolerância de partição
  • objetos esquemáticos e facilmente mutáveis

Contras:

  • CAP: consistência

Questões

Para o registro, eles acabaram usando o MongoDB. Além de todos os pontos de interrogação acima:

  1. Não tenho certeza de como implementar um banco de dados de documentos.
  2. Como os bancos de dados de documentos obtêm tolerância à partição?
  3. Para obter as entradas de um único usuário, presumo que a operação analise todas as entradas e filtre os metadados para o nome de usuário (mapa + filtro). O desempenho de analisar mais de 1.000.000 de documentos para cada usuário seria muito ruim. Presumo que este não seja o comportamento correto?
  4. Que outros prós e contras existem?

(1) Você precisa especificar a relação entre 2 tabelas em termos de negócios. Isso ocorre porque pode haver relacionamentos paralelos. Por exemplo, os usuários <--> usuários não implicam um relacionamento de 1 mm. Pode significar mais de 1. Por exemplo: um usuário gosta de outro usuário e odeia outros usuários. Estes são 2 relacionamentos. (2) Ajudaria se você pudesse resumir o que deseja 'exatamente'.
NoChance

@EmmadKareem: (1) Não estou tentando complicar o cenário. O único relacionamento de usuário <-> usuário no qual estou interessado é uma amizade mútua, que é uma conexão muitos para muitos. (2) Gostaria que as 4 perguntas listadas na parte inferior da postagem fossem respondidas.
wting

Respostas:


13

Sua pergunta pode ser o tópico de um curso universitário de um semestre. Você precisa dividi-lo em pedaços gerenciáveis. Como tal, vou apenas dar algumas respostas parciais.

Uma das primeiras coisas a considerar ao decidir que tipo de banco de dados usar é que tipo de consultas você executará e se você as conhecerá antes de criar o banco de dados. Os bancos de dados SQL têm a vantagem de consultas poderosas e flexíveis em todos os dados no banco de dados. Os bancos de dados de gráficos têm recursos de consulta altamente especializados que os tornam os melhores para dados gráficos e realmente ruins para dados não gráficos (embora os bancos de dados gráficos possam ser componentes nos bancos de dados SQL). Os bancos de dados NoSQL são muito mais limitados em sua capacidade de recuperar e operar dados.

A seguir, como você se sente sobre as propriedades do ACID: Atomicidade, Consistência, Isolamento e Durabilidade. Os bancos de dados SQL fornecem fortes garantias sobre todos os 4. Os bancos de dados NoSQL normalmente não prometem todos os 4, e as maneiras como eles partem estão entre as principais diferenças que diferenciam as várias implementações de banco de dados NoSQL. Por outro lado, não é possível garantir consistência e disponibilidade em face de uma partição (consulte o thorem CAP do Brewer ); portanto, nenhum banco de dados SQL funcionará se você insistir na disponibilidade total em face de uma partição. Pessoalmente, eu me preocupo muito com a durabilidade dos dados no banco de dados, pois normalmente trabalho com dados em que até uma perda de dados de 0,0001% é inaceitável e os conjuntos de dados são pequenos o suficiente para que eu não precise me preocupar com partições. favorece fortemente os bancos de dados SQL.

Outra consideração muito prática é a qualidade do código do servidor, a disponibilidade de administradores e programadores de banco de dados, a qualidade do suporte disponível para problemas que surgem, a qualidade e a disponibilidade das bibliotecas de interface para conectar seu aplicativo ao banco de dados e assim por diante. O MySQL existe há quase duas décadas, a grande maioria dos bugs foi solucionada, é amplamente utilizado e, portanto, oferece grande suporte e grande disponibilidade de pessoal, e provavelmente será suportado pelos próximos 10 anos. Você não pode dizer nada sobre Riak.

Observe que, embora o Google praticamente tenha inventado os bancos de dados NoSQL para armazenar uma versão em cache e indexada de toda a rede mundial de computadores, eles ainda usam o MySQL para algumas coisas.


1
Sei que estava pedindo muito, então uma resposta geral teria sido boa. As perguntas principais são: (1) Por que usar o banco de dados de documentos para suposto grande sharding quando você pode implementar o sharding horizontalmente na lógica usando o sharding de alcance? (2) Como você projetaria um banco de dados de documentos para usar em um cenário do FourSquare e como ele lida com alguns usos comuns (mostrar check-ins do usuário, mostrar amigos do usuário, mostrar os usuários do local atualmente com check-in)?
wting

1
@ William, existem dezenas de artigos que respondem às suas perguntas facilmente acessíveis via Google. Mesmo vários apenas no Stack Overflow . Faça sua lição de casa.
Old Pro
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.