2010-03-19 8 views
23

Tengo una buena razón para usar MongoDB como parte de mi aplicación. Pero la gente generalmente lo describe como no apto para aplicaciones "transaccionales" como un banco donde las transacciones deben ser exactas/consistentes, etc.¿Tiene sentido usar AMBOS mongodb y mysql en la misma aplicación de rieles?

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

No estoy creando una aplicación de banca ni nada pero estaba pensando que podría tener sentido que la tabla de mi usuario o la tabla de transacciones (ingresos de grabación) hicieran esa parte en MySql.

Respuesta

23

Eso es lo que hacemos con CouchDB y PostgreSQL.

Todos nuestros usuarios y grupos 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 de couchdb.

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

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

+2

¡Muchas gracias por el ejemplo del mundo real! –

+1

¿Utiliza un conector CouchDB, o simplemente realiza llamadas a través de REST directamente? Tengo un escenario que tiene sentido para usar ambos también, y no estoy seguro de que una capa de Active Record en el medio valga la pena, ya que las llamadas se recuperarán y ejecutarán. – eddieroger

3

Sería cauteloso con un enfoque dividido aunque no lo excluiría.

Si necesita MySQL + InnoDB y suena como usted, solo presentaría MongoDB para partes preferiblemente aisladas que tienen algo significativo que ganar de los beneficios que aporta MongoDB, y tiene relaciones mínimas con las tablas centrales de MySQL .

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

  • 2 métodos Consulta de diferentes
  • código personalizado torpe a lo largo de las costuras de Objetos MySQL/Mongo que se relacionan entre sí.
  • Una segunda plataforma de base de datos para admitir en producción.

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

2

Diría que ha respondido su propia pregunta aquí.

Tengo un buen motivo para usar mongodb como parte de mi aplicación.

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

Suponiendo que las dos mitades no están vinculadas de alguna manera (las relaciones entre los dos suenan como una receta para el dolor más adelante), le sugiero que vaya y use cada herramienta para lo que es mejor.

Es posible abordar algunas de las preocupaciones que plantea Michael con este enfoque. ya que se está enfocando en el uso de 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 activo de ActiveRecordish. Por supuesto, puede acceder fácilmente a las consultas específicas de Mongo cuando lo necesite.

La preocupación con respecto a las relaciones entre DB es válida en mi opinión y si esto es algo que terminaría teniendo mucho, definitivamente le aconsejo que examine la situación para asegurarse de que esto es algo que está feliz de vivir con. Me imagino que podrías estar ahorrando mucho dolor para más adelante en ese caso particular.

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

4

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

+0

Este es el factor decisivo para muchos tipos de aplicaciones. Mongo es una gran opción para grandes volmenes de datos no críticos. –

+0

Genial, buen punto: –

5

No hay ninguna razón por la que no pueda mantener su tabla de usuarios en MongoDB. Si decide mantener una tabla de transacciones en MongoDB es otra pregunta. Si necesita transacciones multiobjeto, debe usar una base de datos relacional que admita transacciones. Si no necesita este estilo de transacción, usar MongoDB para esto puede ser una buena idea.

Tenga en cuenta que si usa MongoDB, recomendamos ejecutar con la replicación para failover.

Lo más importante a tener en cuenta es que si está utilizando una base de datos relacional debido a las garantías de consistencia, aún necesita asegurarse de que su hardware esté configurado para aprovechar esas características. Ver la nota de precaución aquí:

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

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

+0

Wow, no tenía idea de que ese era el caso en MySql. ¡Gracias por la info! –

Cuestiones relacionadas