MongoDB vs MySQL

Solía construir aplicaciones de Ruby on Rails con MySQL.MongoDB vs MySQL

Actualmente, MongoDB se vuelve cada vez más famoso y ahora estoy empezando a darle una oportunidad.

El problema es que no sé la teoría subyacente de cómo está funcionando MongoDB (estoy usando joya MongoId si importa)

Así que me gustaría tener una comparación en el rendimiento entre el uso de MySQL + ActiveRecord y el modelo generado por la gema mongoide, ¿alguien podría ayudarme a resolverlo?

Fuente

2010-12-15 PeterWong

Puede encontrar esto divertido e interesante para escuchar http://www.xtranormal.com/watch/6995033/mongo-db-is-web-scale – dkroy

El artículo titulado: What the heck are you actually using NoSQL for? hace un muy buen trabajo presentando los pros y los contras del uso de NoSQL.

Editar: Lea también http://blog.fatalmind.com/2011/05/13/choosing-nosql-for-the-right-reason/ entrada en el blog demasiado

Re-Edit: He encontrado algo de material reciente (publicado en 2014) sobre este tema que se considera relevante: What’s left of NoSQL?

Fuente

2010-12-15 09:10:24 cristian

No entra en detalles o detalles sobre cuándo usar una implementación NoSQL sobre la otra, como sugeriría el título, sin embargo, el caso está bastante bien. No use algo solo porque puede o es la última palabra o tendencia/palabra/tecnología. Tal vez la herramienta que tiene funciona perfectamente, pero no la está usando bien. Como dice el refrán: un mal trabajador culpa a sus herramientas. De cualquier manera, la moraleja de la historia es perfecta. –

Como dice @MattSetter, no use algo solo porque puede o porque está de moda. Agregaré esto: la mayoría de los datos no están fuertemente relacionados o basados en documentos y MongoDB es muy fácil de escalar. – wprl

No conozco gran parte de la teoría subyacente. Pero este es el consejo que obtuve: solo use MongoDB si lo ejecuta en varios servidores; ahí es cuando brillará. Por lo que yo entiendo, el movimiento NoSQL apareció en gran parte debido al dolor de las bases de datos relacionales de equilibrio de carga en varios servidores. Entonces, si aloja su aplicación en no más de un servidor, MySQL sería la opción preferida.

Las buenas personas en el Doctrine project recientemente escribieron un muy útil blog post sobre el tema.

Fuente

2010-12-15 09:04:18 Henrik

¿Hay alguna función en MongoDB que la haga más adecuada para varios servidores ? – PeterWong

Al igual que muchas soluciones de búsqueda, MongoDB usa "sharding". Es una forma de dividir rangos de datos en múltiples servidores. Además, dado que MongoDB carece de muchas de las funciones de integridad de datos de las bases de datos relacionales, debe ejecutarse en no menos de dos servidores (un maestro y un esclavo). http: //en.wikipedia.org/wiki/MongoDB – Henrik

Las bases de datos relacionales admiten sharding. Las soluciones NoSQL no admiten transacciones y, a menudo, fallan en los registros de descarga en el disco. Buena suerte al usarlos donde la coherencia de los datos es imprescindible. –

De lo que he leído hasta ahora ... aquí está mi opinión sobre esto.

SQL estándar intercambia un menor rendimiento por la riqueza de características ... es decir, le permite realizar uniones y transacciones entre conjuntos de datos (tablas/colecciones, si lo desea), entre otras cosas.

Esto permite que un desarrollador de aplicaciones aplique parte de la complejidad de la aplicación en la capa de la base de datos. Esto tiene sus ventajas de no tener que preocuparse por la integridad de los datos y el resto de las propiedades de ACID según la tecnología probada. La falta de escalabilidad extrema funciona para casi todos los proyectos, siempre y cuando se pueda mantener la aplicación funcionando dentro de los límites de tiempo esperados, lo que a veces puede resultar en la necesidad de comprar sistemas de bases de datos relacionales de alto rendimiento/costos.

Por otro lado, Mongo DB, excluye deliberadamente gran parte de la complejidad inherente asociada con las bases de datos relacionales, permitiendo un mejor rendimiento escalable.

Este enfoque obliga al desarrollador de la aplicación a volver a diseñar la aplicación para evitar la falta de características relacionales ... lo que en sí mismo es bueno, pero el esfuerzo involucrado generalmente solo vale la pena si tiene la escalabilidad requisitos. Tenga en cuenta que con MongoDB, dependiendo de los requisitos de datos w.r.t ACID propiedades, la aplicación tendrá que intensificar y manejar según sea necesario.

Fuente

2013-03-10 02:04:26 Imhou

Tiene razón en general, pero me gustaría señalar que Mongo es "en su mayoría" compatible con ACID a nivel de documentos. Las uniones son el diablo. Ambas trampas potenciales se vuelven menos problemáticas al planificar el diseño de la base de datos para evitar la necesidad de uniones o escrituras en más de un documento. La definición del esquema se realiza en la aplicación, pero se puede hacer utilizando bibliotecas, por lo que no es muy diferente de definir sus esquemas en, por ejemplo, un archivo hibernate.xml (excepto, como usted dice, que las definiciones de esquema se aplican en la aplicación, no en la base de datos). – wprl

Respuesta

Cuestiones relacionadas