Saltar al contenido

Usando MySQL y Mongodb juntos

Si encuentras algún detalle que te causa duda puedes dejarlo en los comentarios y te ayudaremos tan rápido como podamos.

Solución:

Suena perfectamente razonable usar dos tecnologías de base de datos en un proyecto. Solo asegúrese de usar la herramienta adecuada para el trabajo.

Es común usar MySQL como almacenamiento principal y MongoDB como almacenamiento en caché/almacenamiento intermedio para mayor velocidad.

Por ejemplo, puede tener datos de lectura intensiva en MongoDB. Los datos para generar informes son perfectos para un sistema relacional como MySQL.

Hay una discusión bastante buena sobre casos de uso para MongoDB en el sitio principal de MongoDB. En general, si su caso de negocios incluye la necesidad de transacciones y una gran funcionalidad de T-SQL, será mejor que use un RDBMS como MySQL.

Los buenos casos de uso para MongoDB son los siguientes: 1) Sus datos están en un formato de documento, es decir, una estructura irregular en documentos individuales (es decir, no es necesario unir los datos) 2) Está considerando usar un sistema de archivos plano (nuevamente debido a la estructura de sus datos), pero le gustaría ‘más’ en términos de capacidad para indexar/consultar esos datos. 3) Su proyecto se encuentra en un estado en el que realmente no sabe cuál será el esquema o la estructura de sus datos en última instancia. 4) Tiene tipos de datos especializados, como datos geoespaciales, y desea poder consultarlos. 5) Es posible que necesite escalar de forma rápida y económica su ubicación de almacenamiento de datos.

Aquí hay una discusión bien escrita sobre el uso de mongodb, por alguien que tomó cursos de mongoDb

Consideraciones para elegir o no MongoDB

El bloguero dice principalmente que usar mongodb con otros sistemas de base de datos está perfectamente bien, pero usarlo en todo el sistema puede ser muy desafiante y casi imposible en algunos escenarios determinados.

Aquí hay algunos subtítulos:

Razones para elegir Mongo

  • Orientado a documentos y sin esquemas
  • Escalabilidad horizontal y alta disponibilidad
  • Escrituras rápidas en el modo disparar y olvidar
  • Marco completo de consulta y agregación
  • Arquitectura comparativamente intuitiva

Razones para no elegir Mongo

  • Sin SQL = Sin uniones
  • Sin transacciones ACID
  • Sus índices no cabrían en la memoria

Nos puedes ayudar nuestro ensayo añadiendo un comentario y dejando una puntuación te estamos agradecidos.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *