Mongodb y PostgreSql thoughts

Question

Tengo una aplicación que funciona completamente con PostgreSql. Después de leer sobre Mongodb, me interesó ver cómo funcionaría la aplicación. Después de algunas semanas, migré todo el sistema a Mongodb.

Me gustan algunas cosas con Mongodb. Sin embargo, encontré ciertas consultas que estaba haciendo en PostgreSql, no podría hacerlo de manera eficiente en Mongodb. Especialmente, cuando tuve que unirme a varias tablas para calcular cierta lógica. Por ejemplo, this.

Además, estoy usando Ruby on Rails 3 y un ODM llamado Mongoid. Mongoid todavía está en versión beta. La documentación fue buena, pero, de nuevo, a veces encontré que el ODM era muy limitado en comparación con lo que Active Record ofrecía con los sistemas de bases de datos tradicionales (SQL).

Incluso a esta fecha, me siento más cómodo trabajando con PostgreSql que Mongodb. Solo porque puedo unir mesas y hacer cualquier cosa con los datos.

He realizado dos tipos de copias de seguridad. Uno con PostgreSql y el otro con Mongodb. Algunos dicen que algunas aplicaciones son más adecuadas con uno u otro tipo de db. ¿Debería continuar con Mongodb y eventualmente esperar que su RoR ODM (Mongoid) madure completamente, o debería considerar usar PostgreSql?

Algunas preguntas más: 1) ¿Cuál sería más adecuado para desarrollar un sitio de redes sociales similar a Facebook. 2) Cuál sería más adecuado para el tipo de página de diseño estándar de 4 páginas (Inicio, Productos, Acerca de, Contacto)

Answer 1

Ha descargado un RDBMS con todas las funciones y probado en décadas para una característica joven de calidad beta -en la tienda de documentos con poco apoyo de la comunidad. A menos que ya esté ejecutando decenas de miles de dólares al mes en servidores y piense que MongoDB encaja mejor con la naturaleza de sus datos, probablemente haya desperdiciado mucho tiempo en beneficio negativo. Es divertido jugar con MongoDB, y he creado algunas aplicaciones para usarlo por esa razón, pero casi nunca es una mejor opción que Postgres/MySQL/SQL Server/etc. para aplicaciones de producción. cotización

Answer 2

vamos a lo que usted escribió y ver lo que nos dice:

"I like a few things with Mongodb. However, I found certain queries I was 
doing in PostgreSql, I couldn't do efficiently in Mongodb. Especially, 
when I had to join several tables to calculate some logic." 

"I found the ODM to be very limiting compared to what Active Record offered 
with traditional (SQL) database systems." 

"I feel more comfortable working with PostgreSql than Mongodb. Only because 
I can join tables and do anything with the data." 

Sobre la base de lo que ha dicho que me parece que debe seguir con PostgreSQL. Esté atento a MongoDB y úselo si es apropiado. Pero teniendo en cuenta lo que has dicho, parece que PG es una mejor opción para ti en este momento.

Compartir y disfrutar.

Answer 3

no he usado MongoDB todavía, y nunca puede recibir todo el año a la misma ya que no he encontrado nada que no pueda ver con Postgres, pero sólo para citar el PostgreSQL 9.2: notas de la versión

Con PostgreSQL 9.2, los resultados de la consulta se pueden devolver como tipos de datos JSON. Combinado con las nuevas extensiones de programación PL/V8 Javascript y PL/Coffee , y el almacén de valores-clave HStore opcional, los usuarios ahora pueden utilizar PostgreSQL como una base de datos de documentos "NoSQL", mientras que conservan la confiabilidad, flexibilidad y rendimiento de PostgreSQL .

Parece que en las nuevas versiones de Postgres puede tener lo mejor de ambos mundos. Todavía no lo he usado, pero como fanático de PostgreSQL (excelentes listas de correo y documentación) no dudaría en usarlo para casi cualquier cosa relacionada con RDBMS.

Answer 4

También tenemos investigaciones sobre lo mismo que es mejor. PostGres o MongoDb. pero con todos los hechos y las cifras a mano, encontramos que PostGres es mucho mejor que MongoDb. en MongoDb, además de consumir memoria y CPU, también ocupa gran cantidad de espacio en el disco. Aumenta el tamaño del disco 2x en cierto intervalo.

Answer 5

En primer lugar, postgres es un RDBMS y MongoDB es NoSQL.
pero las tecnologías autónomas NoSQL no cumplen con los estándares ACID porque sacrifican las protecciones críticas de los datos en favor del rendimiento de alto rendimiento para las aplicaciones no estructuradas.

Postgres 9.4 proporciona capacidades NoSQL junto con soporte completo de transacciones, almacenando documentos JSON con restricciones en los datos de los campos.

por lo que obtendrá todas las ventajas de ambos RDBMS y NoSQL

comprobarlo por artículo detallado http://www.aptuz.com/blog/is-postgres-nosql-database-better-than-mongodb/

Para experimentar un rendimiento NoSQL Postgres' por sí mismo. Descargue el pg_nosql_benchmark en GitHub. aquí está el enlace https://github.com/EnterpriseDB/pg_nosql_benchmark

Answer 6

Mi experiencia con Postgres y Mongo después de trabajar con ambas bases de datos en mis proyectos.

Postgres (RDBMS)

Postgres se recomienda si sus aplicaciones futuras tengan un esquema complicado que necesita una gran cantidad de combinaciones o todos los datos de tener relaciones o si tenemos la escritura pesada. Postgres es de código abierto, más rápido, compatible con ACID y utiliza menos memoria en el disco, y tiene un buen rendimiento para el almacenamiento JSON también e incluye la serialización completa de las transacciones con 3 niveles de aislamiento de transacciones.

La mayor ventaja de quedarse con Postgres es que tenemos lo mejor de ambos mundos. Podemos almacenar datos en JSONB con restricciones, consistencia y velocidad. Por otro lado, podemos usar todas las características SQL para otros tipos de datos. El motor subyacente es muy estable y se adapta bien a un buen rango de volúmenes de datos. También se ejecuta en su elección de hardware y sistema operativo. Postgres proporciona capacidades NoSQL junto con soporte total de transacciones, almacenando documentos JSON con restricciones en los datos de los campos.

restricciones generales para Postgres

Escalado Postgres horizontalmente es significativamente más difícil, pero factible.

Las operaciones de lectura rápida no se pueden lograr completamente con Postgres.

bases de datos de SQL NO

Mongo DB (Wired Tigre)

MongoDB puede vencer a Postgres en la dimensión de la “escala horizontal”. El almacenamiento de JSON es lo que Mongo está optimizado para hacer. Mongo almacena sus datos en un formato binario llamado BSONb que es (más o menos) solo una representación binaria de un superconjunto de JSON. MongoDB almacena los objetos exactamente como fueron diseñados.Según MongoDB, para aplicaciones de escritura intensiva, Mongo dice que el nuevo motor (Wired Tiger) ofrece a los usuarios un aumento de hasta 10 veces en el rendimiento de escritura (debería intentarlo), con una reducción del 80% en la utilización de almacenamiento, ayudando a reducir los costos de almacenamiento , lograr una mayor utilización de hardware.

restricciones generales de MongoDB

El uso de un esquema menos motor de almacenamiento lleva al problema de los esquemas implícitos. Estos esquemas no están definidos por nuestro motor de almacenamiento, sino que se definen en función del comportamiento y las expectativas de la aplicación.

Las tecnologías independientes de NoSQL no cumplen con los estándares de ACID porque sacrifican las protecciones críticas de datos a favor del rendimiento de alto rendimiento para aplicaciones no estructuradas. No es difícil aplicar ACID en bases de datos NoSQL, pero haría que la base de datos fuera lenta e inflexible hasta cierto punto. "La mayoría de las limitaciones de NoSQL se optimizaron en las versiones más nuevas y versiones que superaron en gran medida sus limitaciones anteriores".

1. ¿Cuál sería más adecuado para desarrollar un sitio de redes sociales similar a Facebook? Facebook actualmente usa una combinación de bases de datos como Hive y Cassandra.
2. Cuál sería más adecuado para el tipo de página de diseño estándar de 4 páginas (Inicio, Productos, Acerca de, Contacto) De nuevo depende de cómo quiera almacenar y procesar sus datos. pero cualquier base de datos SQL o NOSQL haría el trabajo.