O que é mais rápido: PostgreSQL vs MongoDB em grandes conjuntos de dados JSON?

Eu tenho um grande conjunto de dados com objetos JSON de 9m em ~ 300 bytes cada. São postagens de um agregador de links: basicamente links (uma URL, título e ID do autor) e comentários (texto e ID do autor) + metadados.

Eles poderiam muito bem ser registros relacionais em uma tabela, exceto pelo fato de terem um campo de matriz com IDs apontando para registros filho.

Qual implementação parece mais sólida?

1. Objetos JSON em um banco de dados PostgreSQL (apenas uma tabela grande com uma coluna, a saber, o objeto JSON)
2. Objetos JSON em um MongoDB
3. Explodir os objetos JSON em colunas e usar matrizes no PostgreSQL

Quero maximizar o desempenho nas junções, para que eu possa massagear os dados e explorá-los até encontrar análises interessantes; nesse ponto, acho que será melhor transformar os dados em um formulário específico para cada análise.

Para carregamento de dados, o Postgre supera o MongoDB. O MongoDB é quase sempre mais rápido ao retornar contagens de consultas. O PostgreSQL é quase sempre mais rápido para consultas usando índices.

Confira este site e este também para obter mais informações. Eles têm explicações muito detalhadas.

Você pode se beneficiar mais com o design sem esquema do Mongodb. Isso significa que é muito fácil modificar estruturas de dados em tempo real.

Não existe junção no Mongodb. Então, como se pensa em dados e como usá-los precisa ser modificado para levar em conta os ambientes de banco de dados baseados em documentos e sem esquema.

Talvez a velocidade se torne menos importante à medida que as perspectivas e as prioridades mudam.

Espero que ajude.

-Todd

Para os números mencionados, acho que todas as alternativas devem funcionar (leia-se: você poderá concluir sua análise em tempo razoável). Eu recomendo um design que possa levar a resultados significativamente mais rápidos.

Como respondido anteriormente, em geral o postgresql é mais rápido que o mongo, algumas vezes mais que 4 vezes mais rápido. Veja, por exemplo: http://www.enterprisedb.com/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality

Você disse que está interessado em melhorar o desempenho nas junções. Suponho que você esteja interessado em calcular semelhanças entre as entidades (por exemplo, post, autor), para que você se junte principalmente à tabela com ele próprio (por exemplo, por post ou autor) e agregado.

Acrescente a isso o fato de que, após o carregamento inicial, seu banco de dados será somente leitura, o que torna o problema muito adequado ao uso do índice. Você não pagará pela atualização do índice, uma vez que não terá nenhum, e eu acho que você tem armazenamento extra para o índice.

Eu usaria o postgres e armazenaria os dados em duas tabelas:

criar postagens de tabela (inteiro post_id, url varchar (255), author_id inteiro);

- Carregue dados e crie os índices. - Isso levará a uma carga mais rápida e a melhores índices. Altere as postagens da tabela e adicione a chave primária posts_pk (post_id); criar índice post_author nas postagens (author_id);

criar comentários de tabela (comment_id inteiro, post_id inteiro, author_id inteiro, comment varchar (255)); alterar os comentários da tabela adicionar restrição chave primária comments_pk (comment_id); criar índice comment_author nos comentários (author_id); criar índice comment_post nos comentários (post_id);

Em seguida, você pode calcular a similaridade do autor com base nos comentários em consultas como selecione m. author_id como m_author_id, a. author_id como a_author_id, conte (m.post_id distinto) como postagens de comentários, enquanto m junta comentários como um grupo usando (post_id) por m.author_id, a. author_id

Caso você esteja interessado em tokenizar as palavras no comentário para nlp, adicione outra tabela para isso, mas lembre-se de que isso aumentará significativamente o volume de seus dados. Geralmente, é melhor não representar toda a tokenização no banco de dados.