MongoDB vs MySQL
activerecord comparison (3)
El artículo titulado: ¿Para qué diablos estás usando realmente NoSQL? hace un muy buen trabajo al presentar 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/ publicación de blog también
Reedición: encontré material reciente (publicado en 2014) sobre este tema que considero relevante: ¿Qué queda de NoSQL?
Solía ​​construir aplicaciones de Ruby on Rails con MySQL.
MongoDB se ha vuelto cada vez más famoso y ahora estoy empezando a darle una oportunidad.
El problema es que no conozco la teoría subyacente de cómo funciona MongoDB (estoy usando una gema mongoide si es importante)
Entonces, me gustaría tener una comparación sobre el rendimiento entre el uso de MySQL + ActiveRecord y el modelo generado por la gema mongoid, ¿alguien podría ayudarme a resolverlo?
No sé mucho 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 del proyecto Doctrine recientemente escribieron una publicación de blog bastante útil sobre el tema.
Por lo que he leído hasta ahora ... aquí está mi opinión sobre esto.
El 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, al permitir 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 los requisitos de escalabilidad. Tenga en cuenta que con MongoDB, dependiendo de los requisitos de datos de las propiedades ACID, la aplicación tendrá que intensificar y manejar según sea necesario.