Hace poco descubrí que (digamos, debido a cambios de licencia). Me hizo pensar que en los últimos años he visto un montón de artículos sobre lo terrible que es MongoDB y que nadie debería usarlo. Pero durante este tiempo, MongoDB se ha convertido en un producto mucho más maduro. ¿Qué pasó? ¿Todo el odio se debe realmente a errores al comienzo de la comercialización del nuevo DBMS? ¿O las personas simplemente usan MongoDB en el lugar equivocado?
Si de repente siente que estoy defendiendo a MongoDB, lea al final del artículo.
Nueva tendencia
He estado en la industria del software durante más años de los que es justo decir, pero aún así solo he sido parte de las tendencias que afectan a nuestra industria. He sido testigo del auge de 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain… la lista es interminable. Cada año hay nuevas tendencias. Algunos se están desvaneciendo rápidamente, mientras que otros están cambiando fundamentalmente la forma en que se desarrolla el software.
Alrededor de cada nueva tendencia, se crea una cierta emoción general: las personas saltan al bote ellas mismas o ven el ruido generado por otros, y siguen a la multitud. Este proceso ha sido codificado por Gartner en . Aunque discutible, este gráfico describe aproximadamente lo que sucede con las tecnologías antes de que eventualmente se vuelvan útiles para su uso.
Pero de vez en cuando hay (o hay una segunda venida, como en este caso) una nueva innovación, impulsada por una sola implementación específica de la misma. En el caso de NoSQL, la publicidad fue fuertemente impulsada por el advenimiento y el ascenso meteórico de MongoDB. MongoDB no inició esta tendencia: de hecho, las grandes empresas de Internet comenzaron a tener problemas para procesar grandes cantidades de datos, lo que provocó el regreso de las bases de datos no relacionales. El movimiento general comenzó con proyectos como Bigtable de Google y Cassandra de Facebook, pero fue MongoDB el que se convirtió en la implementación más famosa y accesible de la base de datos NoSQL a la que la mayoría de los desarrolladores tenían acceso.
Nota: Puede pensar que estoy confundiendo bases de datos de documentos con bases de datos de columnas, almacenes de clave/valor o cualquiera de los muchos otros tipos de almacenes de datos que se incluyen en la definición general de NoSQL. Y tienes razón. Pero en ese momento reinaba el caos. Todo el mundo está obsesionado con NoSQL, se ha convertido en todo absolutamente necesario, aunque muchos no vieron las diferencias en las diferentes tecnologías. Para muchos, MongoDB se ha convertido sinónimo de No SQL.
Y los desarrolladores se lanzaron sobre él. La idea de una base de datos sin esquemas que escala mágicamente para resolver cualquier problema era bastante tentadora. Alrededor de 2014, parecía que en todos los lugares donde se usaba una base de datos relacional como MySQL, Postgres o SQL Server hace un año, se estaban implementando bases de datos MongoDB. Cuando se le preguntó por qué, podría obtener respuestas desde el banal "esta es la escala de la web" hasta el más reflexivo "mis datos están muy poco estructurados y encajan bien en una base de datos sin un esquema".
Es importante recordar que MongoDB y las bases de datos de documentos en general resuelven una serie de problemas con las bases de datos relacionales tradicionales:
- esquema estricto: con una base de datos relacional, si tiene datos generados dinámicamente, se ve obligado a crear un montón de columnas de datos aleatorias "diferentes", insertar blobs de datos allí o usar una configuración … todo esto tiene importantes inconvenientes.
- Dificultad de escalar: si hay tantos datos que no caben en un servidor, MongoDB ofreció mecanismos para permitir que se escale entre varias máquinas.
- Modificaciones de circuitos complejos: ¡sin migraciones! En una base de datos relacional, cambiar la estructura de la base de datos puede ser un gran problema (especialmente cuando hay muchos datos). MongoDB ha sido capaz de simplificar enormemente el proceso. Y lo hizo tan fácil que puede actualizar el esquema sobre la marcha y avanzar realmente rápido.
- Rendimiento de escritura: El rendimiento de MongoDB fue bueno, especialmente cuando se ajustó correctamente. Incluso la configuración lista para usar de MongoDB, por la que a menudo fue criticado, mostró algunas cifras de rendimiento impresionantes.
Todos los riesgos están en ti
Los beneficios potenciales de MongoDB eran enormes, especialmente para ciertas clases de problemas. Si lee la lista anterior sin comprender el contexto y sin experiencia, puede tener la impresión de que MongoDB es realmente un DBMS revolucionario. El único problema fue que los beneficios enumerados anteriormente venían con una serie de advertencias, algunas de las cuales se enumeran a continuación.
Para ser justos, nadie en 10gen/MongoDB Inc. No diré que lo siguiente no es cierto, estos son solo compromisos.
- Pérdida de transaccionesR: Las transacciones son una característica fundamental de muchas bases de datos relacionales (no todas, pero sí la mayoría). Transaccional significa que puede realizar múltiples operaciones de forma atómica y puede garantizar que los datos se mantengan consistentes. Por supuesto, con una base de datos NoSQL, la transaccionalidad puede estar dentro de un solo documento, o puede usar confirmaciones de dos fases para obtener semántica transaccional. Pero tendrá que implementar esta funcionalidad usted mismo... lo que puede ser una tarea difícil y lenta. A menudo, no se da cuenta del problema hasta que ve que los datos de la base de datos entran en estados no válidos porque es imposible garantizar la atomicidad de las operaciones. Nota: Muchos me han dicho que las transacciones se introdujeron en MongoDB 4.0 el año pasado, pero con algunas limitaciones. La conclusión del artículo sigue siendo la misma: evalúe cómo la tecnología se adapta a sus necesidades.
- Pérdida de integridad relacional (claves foráneas): si sus datos tienen relaciones, entonces tendrá que aplicarlas en la aplicación. Tener una base de datos que respete estas relaciones le quitará mucho trabajo a la aplicación y, por lo tanto, a sus programadores.
- Incapacidad para aplicar la estructura de datos.: Los esquemas estrictos a veces pueden ser un gran problema, pero también son un mecanismo poderoso para una buena estructuración de datos si se usan con prudencia. Las bases de datos de documentos como MongoDB brindan una flexibilidad de esquema increíble, pero esa flexibilidad elimina la responsabilidad de mantener los datos limpios. Si no los cuida, terminará escribiendo una gran cantidad de código en su aplicación para dar cuenta de los datos que no se almacenan en la forma esperada. Como suelen decir en nuestra empresa Simple Thread… algún día se reescribirá la aplicación, pero los datos vivirán para siempre. Nota: MongoDB admite la validación de esquemas, que es útil pero no ofrece las mismas garantías que una base de datos relacional. En primer lugar, agregar o cambiar la validación del esquema no afecta los datos existentes en la colección. Debe asegurarse de actualizar los datos de acuerdo con el nuevo esquema. Decide por ti mismo si esto es suficiente para tus necesidades.
- Lenguaje de consulta propio/pérdida del ecosistema de herramientas: La llegada de SQL fue una revolución absoluta y nada ha cambiado desde entonces. Es un lenguaje increíblemente poderoso, pero también bastante complejo. Las personas que tienen experiencia con SQL consideran que la necesidad de construir consultas de bases de datos en un nuevo lenguaje, que consta de fragmentos JSON, es un gran paso atrás. Existe todo un universo de herramientas que interactúan con bases de datos SQL, desde IDE hasta herramientas de generación de informes. Pasar a una base de datos que no admite SQL significa que no puede usar la mayoría de estas herramientas, o necesita convertir los datos a SQL para poder usarlas, lo que puede ser más difícil de lo que piensa.
Muchos desarrolladores que recurrieron a MongoDB realmente no entendieron las ventajas y desventajas y, a menudo, se lanzaron de cabeza a configurarlo como su almacén de datos principal. Después de eso, a menudo era increíblemente difícil volver atrás.
¿Qué podría haberse hecho de manera diferente?
No todos saltaron de cabeza y se estrellaron contra el fondo. Pero bastantes proyectos han instalado la base de MongoDB donde simplemente no encajaba, y tendrán que vivir con ella durante muchos años más. Si estas organizaciones se hubieran tomado un tiempo para considerar metódicamente sus opciones tecnológicas, muchas habrían tomado una decisión diferente.
¿Cómo elegir la tecnología adecuada? Ha habido varios intentos de crear un marco sistemático para la evaluación de la tecnología, como и , pero me parece que esto es una complejidad innecesaria.
Muchas tecnologías se pueden valorar inteligentemente con solo dos preguntas básicas. El problema radica en encontrar personas que puedan responderlas con responsabilidad, tomándose el tiempo para encontrar respuestas y sin sesgos.
Si no enfrenta ningún problema, no necesita una nueva herramienta. Punto.
Pregunta 1: ¿Qué problemas estoy tratando de resolver?
Si no enfrenta ningún problema, no necesita una nueva herramienta. Punto. No es necesario buscar una solución y luego plantear un problema. A menos que se enfrente a un problema que la nueva tecnología no resuelva significativamente mejor que la tecnología existente, entonces no hay nada que discutir aquí. Si está considerando usar esta tecnología porque ha visto que otros la usan, piense en los problemas que están teniendo y pregúnteles si usted tiene esos problemas. Es fácil adoptar la tecnología porque otros la están usando, la dificultad es saber si estás enfrentando los mismos problemas.
Pregunta 2: ¿Qué me estoy perdiendo?
Esta es ciertamente una pregunta más difícil, porque hay que profundizar y comprender bien tanto la tecnología antigua como la nueva. A veces no puedes entender realmente uno nuevo hasta que hayas construido algo con él o tengas un colega con esa experiencia.
Si no tiene ninguno de los dos, entonces tiene sentido pensar en la inversión mínima posible para determinar el valor de este instrumento. Y si haces una inversión, ¿qué tan difícil será revertir la decisión?
La gente siempre arruina todo.
Al tratar de responder a estas preguntas de la manera más imparcial posible, recuerda una cosa: tienes que luchar contra la naturaleza humana. Hay una serie de sesgos cognitivos que deben superarse para evaluar la tecnología de manera efectiva. Aquí hay algunos:
- Todo el mundo sabe de él, pero todavía es difícil luchar contra él. Solo asegúrese de que la tecnología realmente se adapte a sus necesidades reales.
- Muchos desarrolladores tienden a subestimar las tecnologías con las que han estado trabajando durante mucho tiempo y sobreestiman los beneficios de una nueva tecnología. No solo los programadores, todos están sujetos a este sesgo cognitivo.
- Tendemos a ver lo que es y a perder de vista lo que no es. Esto puede conducir al caos, combinado con el efecto de novedad, ya que no solo sobrevaloras la nueva tecnología de forma inherente, sino que también ignoras sus deficiencias..
La evaluación objetiva no es fácil, pero comprender los sesgos cognitivos subyacentes lo ayudará a tomar decisiones más racionales.
Resumen
Cuando aparece una innovación, hay que responder con mucho cuidado a dos preguntas:
- ¿Esta herramienta resuelve un problema real?
- ¿Somos buenos para entender las compensaciones?
Si no puede responder con confianza estas dos preguntas, retroceda unos pasos y piense.
Entonces, ¿fue la MongoDB generalmente la elección correcta? Por supuesto que sí; como con la mayoría de las tecnologías de ingeniería, depende de muchos factores. Entre los que respondieron estas dos preguntas, muchos se han beneficiado de MongoDB y continúan haciéndolo. Para aquellos de ustedes que no lo han hecho, espero que hayan aprendido una lección valiosa y no demasiado dolorosa sobre cómo moverse a través del ciclo de publicidad.
Descargo de responsabilidad
Quiero aclarar que ni amo ni odio a MongoDB. Simplemente no teníamos el tipo de problemas que MongoDB es el más adecuado para resolver. Sé que 10gen/MongoDB Inc. actuó con mucha audacia al principio, estableciendo valores predeterminados inseguros y promocionando MongoDB en todas partes (especialmente en hackatones) como una solución integral para trabajar con cualquier dato. Probablemente fue una mala decisión. Pero confirma el enfoque descrito aquí: estos problemas podrían detectarse muy rápidamente incluso con una evaluación superficial de la tecnología.
Fuente: habr.com