¿Qué es más rápido: PostgreSQL vs MongoDB en grandes conjuntos de datos JSON?

10

Tengo un gran conjunto de datos con 9 millones de objetos JSON a ~ 300 bytes cada uno. Son publicaciones de un agregador de enlaces: básicamente enlaces (una URL, título e identificación del autor) y comentarios (texto e identificación del autor) + metadatos.

Bien podrían ser registros relacionales en una tabla, excepto por el hecho de que tienen un campo de matriz con ID que apuntan a registros secundarios.

¿Qué implementación se ve más sólida?

Objetos JSON en una base de datos PostgreSQL (solo una tabla grande con una columna, es decir, el objeto JSON)
Objetos JSON en un MongoDB
Explote los objetos JSON en columnas y use matrices en PostgreSQL

Quiero maximizar el rendimiento en uniones, para poder masajear los datos y explorarlos hasta encontrar análisis interesantes, momento en el que creo que será mejor transformar los datos en una forma específica para cada análisis.

— azul-dino
fuente

podría querer pagar copo de nieve. Puede manejar datos estructurados y semiestructurados juntos. www.snowflake.net

Creo que necesita ampliar lo que significa para usted "maximizar el rendimiento en uniones". ¿Unirse a qué?

— Spacedman

10

Para la carga de datos, Postgre supera a MongoDB. MongoDB es casi siempre más rápido al devolver conteos de consultas. PostgreSQL es casi siempre más rápido para consultas que usan índices.

Consulte este sitio web y este también para obtener más información. Tienen explicaciones muy detalladas.

— programador sin título
fuente

Muy buenos enlaces, especialmente el primero que se ve más detallado y completo. Al buscar el año (una cadena) y devolver la identificación del registro (un int), potgresql es aproximadamente 4 veces más rápido, pero al devolver el autor, el orden de magnitud es el mismo. MongoDB es solo un 20% más lento cuando regresa el autor. ¿Hay una diferencia fundamental entre devolver un int y devolver una cadena que podría explicar esto? Es decir, si recid fuera una cadena, ¿la ventaja de postgresql desaparecería y ambas serían más o menos las mismas que en el caso del autor?

— MASL

1

Puede beneficiarse más del diseño sin esquemas de Mongodb. Esto significa que es muy fácil modificar las estructuras de datos sobre la marcha.

No existe una unión en Mongodb. Entonces, cómo se piensa en los datos y cómo usarlos debe modificarse para tener en cuenta los entornos db basados en documentos y sin esquemas.

Tal vez la velocidad se vuelve menos importante a medida que cambian la perspectiva y las prioridades.

Espero que eso ayude.

-Todd

— Todd Canedy
fuente

En la mayoría de los puntos de referencia recientes, PostgreSQL totalmente propiedad MongoDB ...

— Ha dejado de fumar - Anony-Mousse

@ Anony-Mousse: Interesante. ¿Conoces alguna fuente?

— Isaac

Por ejemplo, tiborsimko.org/postgresql-mongodb-json-select-speed.html y enterprisedb.com/postgres-plus-edb-blog/marc-linster/… de la otra respuesta. Una razón clave es: Postgres tiene buenos índices, mientras que los índices en MongoDB no valen la pena. Además, Postgres obtuvo soporte BSON y otras adiciones para manejar JSON, que mejoraron considerablemente el rendimiento. Es por eso que se volvió mucho más rápido que en las primeras versiones.

— HA SALIDO - Anony-Mousse

0

Para los números que menciona, creo que todas las alternativas deberían funcionar (lea: podrá finalizar su análisis en un tiempo razonable). Recomiendo un diseño que pueda conducir a resultados significativamente más rápidos.

Como se respondió anteriormente, en general postgresql es más rápido que mongo, algunas veces más de 4 veces más rápido. Ver por ejemplo: http://www.enterprisedb.com/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality

Dijiste que estás interesado en mejorar el rendimiento en las uniones. Supongo que está interesado en calcular las similitudes entre las entidades (por ejemplo, publicación, autor), por lo que principalmente se unirá a la tabla consigo mismo (por ejemplo, por publicación o autor) y agregado.

Agregue a eso el hecho de que después de la carga inicial, su base de datos será de solo lectura, lo que hace que el problema sea muy adecuado para indexar el uso. No pagará por la actualización del índice ya que no tendrá ninguna y supongo que tiene el almacenamiento adicional para el índice.

Hubiera utilizado postgres y almacenar los datos en dos tablas:

crear publicaciones de tabla (post_id integer, url varchar (255), author_id integer);

- Cargar datos y luego crear los índices. - Eso conducirá a una carga más rápida y mejores índices alterar las publicaciones de la tabla agregar restricción posts_pk clave principal (post_id); crear índice post_author en publicaciones (author_id);

crear comentarios de tabla (comentario_id entero, post_id entero, author_id entero, comentario varchar (255)); alterar los comentarios de la tabla agregar restricción llave primaria comments_pk (comment_id); crear índice comment_author en los comentarios (author_id); crear índice comment_post en comentarios (post_id);

Luego, puede calcular la similitud de autor basándose en comentarios en consultas como select m. author_id como m_author_id, a. author_id como a_author_id, cuenta (distinto m.post_id) como publicaciones de comentarios a medida que se unen a los comentarios como un grupo que usa (post_id) por m.author_id, a. author_id

En caso de que esté interesado en tokenizar las palabras en el comentario para nlp, agregue otra tabla para eso, pero recuerde que aumentará significativamente el volumen de sus datos. Por lo general, es mejor no representar la tokenización completa en la base de datos.

— DaL
fuente