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?
- agrupamento
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:
- Não tenho certeza de como implementar um banco de dados de documentos.
- Como os bancos de dados de documentos obtêm tolerância à partição?
- 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?
- Que outros prós e contras existem?