mysql - example - sql vs nosql

¿Tiene sentido usar AMBOS mongodb y mysql en la misma aplicación de rieles?

Question

Tengo una buena razón para usar MongoDB para parte de mi aplicación. Pero la gente generalmente lo describe como no adecuado para aplicaciones "transaccionales" como un banco donde las transacciones tienen que ser exactas / consistentes, etc.

¿Tiene sentido dividir los modelos en Rails y algunos de ellos usan MySql y otros mongo? ¿O esto generalmente causará más problemas de los que vale?

No estoy creando una aplicación bancaria ni nada de eso, pero pensé que podría tener sentido que la tabla de transacciones de mi usuario (ingresos de registro) hiciera esa parte en MySQL.

Answer 1

Desconfiaba de un enfoque dividido aunque no lo excluyera.

Si necesita MySQL + InnoDB y suena como si lo hiciera, solo introduciría MongoDB para las partes preferiblemente más aisladas que tienen algo importante que obtener de los beneficios que ofrece MongoDB, y tengo relaciones mínimas con las tablas centrales de MySQL.

Actualmente estoy luchando con el mismo problema, una aplicación Rails con tablas 20ish en MySQL. El uso de Mongodb resolvería algunos problemas de diseño de la base de datos (subobjetos anidados y columnas de matriz indexables especialmente), pero es difícil justificar la sobrecarga adicional de:

• 2 métodos de consulta diferentes
• Código personalizado incómodo a lo largo de las costuras de los objetos MySQL / Mongo que se relacionan entre sí.
• Una segunda plataforma de base de datos para soporte en producción.

Estoy en el proceso de lanzar MongoDB para nuestra mesa de registro, y voy a tomarlo desde allí.

Answer 2

Eso es lo que hacemos con CouchDB y PostgreSQL.

Todos nuestros usuarios y grupos de cosas están en la base de datos postgresql.
Cualquier otra cosa (en nuestro caso, algunos registros con datos estadísticos) se encuentran en la base de datos couchdb.

En nuestro caso, nos permite tener una base de datos couchdb por cliente (la aplicación se conecta a uno u otro según el host del usuario).
Y solo una base de datos postgresql con todos los usuarios en ella.

Entonces, sí, creo que es una buena idea tener una base de datos SQL y NOSQL en la misma aplicación.

Answer 3

No hay ninguna razón por la que no pueda mantener la tabla de sus usuarios en MongoDB. Si decide mantener una tabla de transacciones en MongoDB es otra pregunta. Si necesita transacciones de múltiples objetos, entonces tiene que usar una base de datos relacional que admita transacciones. Si no necesita este tipo de transacción, entonces usar MongoDB para esto puede ser una buena idea.

Tenga en cuenta que si utiliza MongoDB, le recomendamos que se ejecute con replicación para la conmutación por error.

Lo que hay que tener en cuenta en general es que si está utilizando una base de datos relacional debido a las garantías de coherencia, debe asegurarse de que su hardware esté configurado para aprovechar esas características. Vea la nota de advertencia aquí:

http://dev.mysql.com/doc/refman/4.1/en/innodb-configuration.html

Si no está tomando estas precauciones, entonces no hay una gran diferencia entre la durabilidad de MongoDB y la de una base de datos relacional.

Answer 4

Piense también en la durabilidad: http://blog.mongodb.org/post/381927266/what-about-durability , por ejemplo, cuando pierde energía (electricidad).

Answer 5

Yo diría que has respondido tu propia pregunta aquí.

Tengo una buena razón para usar mongodb para parte de mi aplicación.

Suponiendo que también tenga una buena razón para mantener otras partes en MySQL, diría que la respuesta es sí. Su pregunta implica (al menos para mí) que tiene una comprensión buena y bien investigada de las diversas opciones y sus fortalezas y debilidades y, por lo tanto, ha llegado a una conclusión sensata en cuanto a que es posible dividir sus modelos.

Suponiendo que las dos mitades no están vinculadas de alguna manera (las relaciones entre los dos sonidos son como una receta para el dolor más adelante), sugeriría que lo haga y use cada herramienta para lo que es mejor.

Es posible abordar algunas de las preocupaciones que Michael plantea con este enfoque. Ya que se está enfocando en usar Rails, puede usar ActiveRecord para sus modelos basados ​​en MySQL y usar MongoMapper para sus modelos basados ​​en MongoDb. De esta manera, no tendrá que lidiar con dos métodos de consulta completamente diferentes ya que MongoMapper proporciona un enfoque muy ActiveRecordish. Por supuesto, puede desplegar fácilmente en consultas específicas de Mongo cuando lo necesite.

En mi opinión, la preocupación con respecto a las relaciones entre bases de datos es válida y si esto es algo que terminaría teniendo, definitivamente recomendaría examinar la situación para asegurarme de que sea algo con lo que esté feliz de vivir. Me imagino que podría estar ahorrando mucho dolor para más adelante en ese caso particular.

En general, sugeriría que siempre que sus dos mitades estén relativamente desconectadas entre sí, una capa de persistencia de personalidad dividida funcionará bien para usted.