¿Las empresas usan MySQL para nuevos proyectos o Mongo se hizo cargo por completo?

Estoy usando MongoDB y MySQL en mi proyecto actual, así que vine aquí para compartir mi experiencia.

Una parte de nuestro proyecto es reconocer una gran cantidad (10 millones) de imágenes escaneadas usando ICR. La salida del ICR es una estructura de datos compleja. Además, el software ICR escribe 10 documentos por segundo. Todos estos datos complejos se escriben y leen juntos para cada documento.

Elegimos MongoDB para esta parte porque solo podemos escribir y leer la compleja estructura de datos como un JSON. Si se tratara de una base de datos relacional, necesitaríamos hacer muchas uniones para recuperar los datos de un solo documento.

Después del reconocimiento, realizamos un procesamiento posterior de los datos. Una vez que se realiza el procesamiento posterior, tenemos que clasificar los datos y hacer análisis e informes al respecto. Para esto, volcamos los campos que se utilizan en informes y análisis a una base de datos MySQL. Ejecutar consultas de informes diferentes en MongoDB a veces es muy difícil pero bastante fácil en DB relacional. Entonces usamos MySQL para este propósito.

En pocas palabras: voy a hacer un nuevo proyecto, así que tengo que usar MongoDB, esa es una decisión muy equivocada. MongoDB y MySQL resuelven dos problemas diferentes. Necesitamos identificar nuestro problema primero y luego elegir la mejor herramienta o combinación de herramientas para resolver ese problema.

MongoDB no “reemplaza” MySQL.

MongoDB es una base de datos orientada a documentos y es ideal para casos de uso donde este tipo de modelo de datos funciona bien, como aplicaciones de registro, cosas que son básicamente conjuntos de propiedades que pertenecen a entidades específicas, etc.

El punto óptimo de MongoDB definitivamente no es el tipo de cosas que hace con una base de datos relacional, por lo que no la usaría para datos tabulares o datos en los que esté interesado en navegar y consultar a través de combinaciones.

MongoDB tampoco realiza transacciones ACID, que son necesarias para muchos tipos de datos, incluso en “proyectos nuevos”.

Entonces, muchas empresas usan MongoDB para algunos tipos de datos y MySQL (o PostgreSQL) para los datos relacionales en su mundo de datos.

Un ejemplo sería un juego multiusuario: puede usar MongoDB para representar el mundo del juego y los elementos del mundo del juego, y puede usar MySQL para representar a los usuarios, el inventario de usuarios, la ubicación del usuario, el historial de usuarios y todo lo relacionado con la facturación .

Después de buenas respuestas voy a ser poco serio. 🙂

NoSQL? ¡No! SQL

Siempre me gusta señalar “olas” en el mundo DB

  • 90s, OO DBMS, que matará a RDBMS. Quedan pocos días para morir … Pero los vendedores de RDBMS se han extendido a ORDBMS.
  • 2000, DBMS basado en XML, matarán RDBMS. Pero … los proveedores de RDBMS han proporcionado un tipo de campo XML y algunas funciones.
  • 2005+ diferentes noSQL, que nuevamente matan a RDBMS
  • Los bs basados ​​en JSON son geniales. Pero … los proveedores de RDBMS agregan ahora el tipo de campo JSON y algunas funciones …
  • Valores clave … bueno, tienen buena escalabilidad, los proveedores de RDBMS intentan colocar el almacenamiento de valores clave como un almacenamiento de tabla u otras soluciones diferentes.
  • En nuestro Valentina DB, por ejemplo, intentamos implementar ahora híbrido: KeyValue como parte del modelo Object-Relational. Hemos extendido SQL para esto, etc. Vea un pequeño artículo para más detalles.

En mi humilde opinión, los dbs basados ​​en algunos formatos son solo una “ola”, que se integrará en los sistemas ORDBMS +

Esta pregunta es divertida: me recuerda cómo en mi última compañía, los ingenieros comenzaron a usar la palabra “mongo” como un verbo que significa complicar demasiado una solución.

Recientemente, he estado un poco involucrado en la evaluación de nuevas empresas en etapa inicial y una de las señales de alerta es cuando las personas usan ciertas tecnologías porque son palabras de moda recientes sin siquiera considerar si las soluciones más simples funcionarían. (Por alguna razón, esto tiende a incluir MongoDB, Hadoop, hoy en día también “aprendizaje profundo” e “AI” como términos generales para arrojar).

Entonces, no hay nada intrínsecamente malo con MongoDB, como la mayoría de estas nuevas tecnologías, hay casos en los que tiene mucho sentido usar, pero usar algo solo porque es un objeto brillante es una muy mala idea.

Mongo no se hará cargo de MySQ o viceversa. Se usan por diferentes razones. Desde que Oracle se hizo cargo de MySQL, ha adquirido más funciones que lo convierten en una relación de base de datos viable. Sin embargo, la base de datos que usaría sería PostGreSQL. Durante mucho tiempo, Mongo tuvo muchos problemas con la caída de registros al compartir y agrupar. Se ha hecho más confiable recientemente. Sin embargo, PostgreSQL tiene los dos aspectos de base de datos relacional, tiene todas las características de una base de datos Oracle o DB2 más algunas, Y tiene clave de documento NoSQL, pares de valores disponibles, además tiene una capacidad de agrupación probada.

Mongo ni siquiera es el “último granista” en NoSQL DBs. Yo miraría a Couchbase o Cassandra.

Sí, MySQL es una opción sólida y confiable para DB.

Oracle potencia significativamente MySQL para los últimos años. Ahora se puede usar como almacén de documentos, tiene soporte avanzado de datos geo y nosql json con columnas / índices virtuales, tiene agrupación integrada, nueva consola con sintaxis JS, Oracle también ofrece ahora soluciones empresariales e incluso MySQL en la nube y Hay mucho más por venir en el futuro, sin mencionar la velocidad de mejora y el próximo MySQL 8.0.

MySQL tampoco fue un problema real a gran escala y es utilizado por grandes compañías como Facebook. MySQL también sigue siendo un # 2 DB en el mundo.

Las bases de datos más nuevas y los lenguajes de codificación tienden a ser adoptados por personas más jóvenes que tal vez no tengan la experiencia que las diferentes etapas de la administración podrían tener.

Según mi experiencia en general, será un programador más joven que desea usar mongodb debido a los beneficios declarados, tal vez no tengan la experiencia para ver algunos de los beneficios más importantes de permanecer con MySQL ya que solo están mirando el rendimiento de Un tema en particular.

Por ejemplo, como gerente de proyecto, no veo características, veo dolores de cabeza y compromisos que deben ser atendidos y considerados desde una variedad de ángulos diferentes, siendo el más común obtener un buen número competitivo de programadores que pueden asumir fácilmente el trabajo en una fecha posterior de manera económica y escalable. MySQL continúa ganando esa consideración.

El interés de los accionistas también es una consideración, no estoy aquí para probar o probar proyectos más nuevos con dinero de los accionistas. Si MySQL es adecuado para su propósito, nunca me preguntarán sobre mi elección de usarlo, mientras que probar diferentes formas siempre conducirá a que alguien cuestione su metodología.

Mysql no es perfecto y ha habido momentos en los que he tenido que hacer soluciones para resolver problemas de MySQL, pero en realidad la mayoría de esas soluciones han sido buenos procesos generales de recuperación ante desastres de todos modos.

Para responder a su pregunta, los últimos 20 proyectos han utilizado MySQL en 17 casos.

Si la startup tiene alguna forma de sobrevivir, esperemos que elijan las herramientas adecuadas para el trabajo y no solo cosas nuevas y brillantes.

La gente se está moviendo de MySQL a MariaDB (autores originales de MySQL) y luego tienes Postgres. Cuando las personas tienen datos relacionales, usan una base de datos SQL, espero.

Cuando solo tienes documentos o muy pocas cosas relacionales, Mongo es muy agradable. Uso Mongo para muchos de mis proyectos, cuando creo que encaja.

Uno no tiene que hacerse cargo del otro para tener éxito. Tenemos literalmente miles de millones de servicios web y servidores de bases de datos.

Lo único que puede matar algo como MySQL es si no hay correcciones de errores, características y si el propietario no muestra interés en el proyecto. Pero luego tienes MariaDB, que es un clon de MySQL, y cuando digo clon, comienzan como el mismo código fuente. Se han dividido un poco, pero puede usar cualquier biblioteca, herramienta o consulta mysql y funciona en mariadb.

Simplemente elija la herramienta adecuada para el trabajo, no importa si alguna gran empresa lo usa o no, lo que importa es si es correcto.

Hola,

¡Sí! MySQL aún vale la pena

MySQL

Por lo general, se usa en conexión con PHP. Es un sistema de base de datos que permite al usuario almacenar y recibir datos de su sitio web. Es un sistema extremadamente fácil de usar, que le permite almacenar datos hasta que sean necesarios en su sitio web.

Conozca más sobre las tecnologías de creación de sitios web

Gracias.

De su pregunta queda claro que su organización no comprende los datos, lo cual es un hecho cuando las personas no se toman el tiempo para estudiar el modelo relacional, cómo se desvía SQL de él y cómo los DBMS se desvían del modelo relacional.

Básicamente, sería mejor usar PostgreSQL; Las razones dadas para usar Mongo no son limitaciones del modelo relacional, de SQL o de los DBMS de SQL en general, sino de MySQL (y algunos otros DBMS cuasi-SQL), pero no de PostgreSQL.

Usar algunos NoSQL como Mongo no será una solución, sino un dolor de cabeza.

Mongo y MySQL están diseñados para casos de uso completamente diferentes. De hecho, no es raro ver AMBOS usados ​​en el mismo sitio / aplicación / thingamajig para manejar diferentes secciones del programa.

Mongo es una adición bienvenida a la caja de herramientas del desarrollador moderno, no un sustituto de las herramientas existentes.

Dicho esto, tenía la impresión de que el uso general de Mongo y otras tecnologías NoSQL realmente ha estado en decadencia últimamente.

Por un tiempo muy corto consideramos MongoDB.

Pero no aportó nada al juego que necesitaríamos. Muchas de nuestras estructuras aún dependen de las relaciones, con solo un puñado de bits que realmente podrían obtener de un tipo de documento. E incluso esos documentos tendrían fuertes relaciones con el resto de los datos.

Terminamos yendo con PostgreSQL. En esa etapa, solo traían sus tipos JSON al juego, y encajaría muy bien en nuestro caso de uso. JSONB agrega un poco más de velocidad si está leyendo más que escribiendo, y conserva todos los bits buenos de una base de datos relacional.

Ha estado funcionando realmente bien hasta ahora.

MongoDB y MySQL son herramientas completamente diferentes. Al igual que una nevera y caja fuerte. Sí, almacenan cosas, ¡pero los propósitos son diferentes!

Son herramientas que no compiten. Tienen diferentes ventajas y desventajas. Un mejor caso de uso es no favorecer a uno, sino usarlos juntos para obtener una ventaja combinada.

¡Se siente como si estuviera sentado en una reunión con un gerente al que le encanta usar palabras de moda! Antes de contestar esto, quiero compartir mi experiencia. Uno de los gerentes senior solo pidió desarrollar y cito “Awesome UI with NodeJS”. ¡Ella no entendió cuando mis colegas trataron de explicar que es imposible!

Compartí esta experiencia divertida porque esta pregunta es muy similar a esa.

MySql y MongoDB son dos cosas diferentes que intentan resolver dos problemas diferentes por completo. Le sugiero que lea SQL vs NoSQL e intente reformular su pregunta.

Es muy raro que una solución nueva (o recientemente popular) elimine rápidamente una solución establecida porque el personal tiene experiencia con la solución establecida. La mayoría de las veces, lo nuevo y mejorado no es lo suficientemente mejor / más rápido para garantizar el salto de la nave al instante, las empresas se mueven lentamente, al igual que * la mayoría de los desarrolladores. ¡Todos sabemos aquel que dominará todo instantáneamente! (y sí, ¡todos la odiamos!) pero para la mayoría de nosotros, somos muy capaces en lo que sabemos, y aprender nuevas cosas no sucederá de la noche a la mañana, lleva tiempo

No hay bases de datos SQL que no sean las mismas que las bases de datos relacionales, mongo será lento para realizar las tareas más altas que una base de datos relacional, como referencias cruzadas de productos de ventas superiores con artículos de stock existentes y los pedidos realizados para una determinada venta y relación db será más lento en el cálculo para procesar tareas rectas.

(Tenga en cuenta que, en mi experiencia, algunas consultas SQL tardan mucho en procesarse porque las tablas no están configuradas correctamente, un índice faltante hará una gran diferencia en las tablas grandes)

No puedes comparar ambos cabeza a cabeza, cada uno tiene su propuesta.

He estado trabajando en varias empresas de comercio electrónico y usan un superconjunto de MySQL, ya que MySQL tiene muchos inconvenientes y, a veces, es difícil implementar solo cosas simples como entidades maestras / esclavas, todas usan mariaDb (MySQL hecho correctamente) 🙂

Ranking de motores DB

Mongo no está ni remotamente cerca de hacerse cargo de MySQL.

Lol Yes MySql todavía se usa.

Acabo de crear una nueva aplicación wpf que se conecta a mySql para Bombardier, que es una compañía masiva. RDMS se usa mucho en mi programación diaria aquí y mongo simplemente no satisface nuestras necesidades.