Recientemente descubrí que Red Hat está eliminando el soporte MongoDB de Satellite (dicen que debido a cambios en la 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. Que paso ¿Todo el odio se debe realmente a errores al comienzo de la comercialización de un nuevo DBMS? ¿O la gente usa MongoDB en un lugar equivocado?

Si de repente siente que estoy protegiendo a MongoDB, lea el descargo de responsabilidad al final del artículo.

Nueva tendencia

He trabajado en la industria del software durante más que suficiente tiempo para hablar decentemente, pero de todos modos, solo una pequeña parte de las tendencias que afectaron a nuestra industria me explicaron. He sido testigo del crecimiento de 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain ... la lista es interminable. Cada año aparecen nuevas tendencias. Algunos se desvanecen rápidamente, mientras que otros cambian fundamentalmente la forma en que se desarrolla el software.

Alrededor de cada nueva tendencia, se crea una cierta emoción general: las personas se suben al bote o ven el ruido generado por otros, y siguen a la multitud. Gartner codifica este proceso en un ciclo exagerado . Aunque controvertido, este gráfico describe más o menos lo que le sucede a las tecnologías antes de que finalmente se vuelvan utilizables.

Pero de vez en cuando, aparece una nueva innovación (o sucede una segunda venida, como en este caso), impulsada por una sola implementación específica. En el caso de NoSQL, la exageración fue fuertemente impulsada por el advenimiento y el rápido aumento de MongoDB. MongoDB no lanzó esta tendencia: de hecho, las grandes compañías de Internet comenzaron a tener problemas para procesar grandes cantidades de datos, lo que condujo al regreso de bases de datos no relacionales. El movimiento general comenzó con proyectos como Bigtable de Google y Cassandra de Facebook, pero fue MongoDB la que se convirtió en la implementación más famosa y asequible de la base de datos NoSQL, a la que la mayoría de los desarrolladores tenían acceso.

Nota: puede pensar que estoy mezclando 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. Todos estaban obsesionados con NoSQL, todos lo necesitaban absolutamente , aunque muchos no vieron las diferencias en las diferentes tecnologías. Para muchos, MongoDB se ha convertido en sinónimo de NoSQL.

Y los desarrolladores la atacaron. Fue una idea bastante tentadora tener una base de datos sin un esquema que se escale mágicamente para resolver cualquier problema. Alrededor de 2014, parecía que en todas partes donde se utilizó una base de datos relacional hace un año, como MySQL, Postgres o SQL Server, las bases de datos MongoDB comenzaron a implementarse. A la pregunta de por qué, podría obtener una respuesta desde el banal "esta es la escala de la web" al más reflexivo "mis datos están muy mal estructurados y encajan bien en la base de datos sin un esquema".

Es importante recordar que MongoDB y las bases de datos de documentos generalmente resuelven una serie de problemas con las bases de datos relacionales tradicionales:

• Esquema estricto : con una base de datos relacional, si ha generado datos dinámicamente, se ve obligado a crear un grupo de columnas de datos "diferentes" aleatorias, insertar blobs de datos allí o usar la configuración EAV ... todo esto tiene inconvenientes significativos.
  
• La dificultad de escalar : si hay tantos datos que no caben en un solo servidor, MongoDB ha propuesto mecanismos para escalarlos en múltiples máquinas.
  
• Modificaciones de circuito sofisticadas : ¡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 pudo simplificar enormemente el proceso. Y lo hizo tan fácil que puedes actualizar el circuito sobre la marcha y seguir adelante muy rápidamente.
  
• Rendimiento de grabación : el rendimiento de MongoDB fue bueno, especialmente con el ajuste adecuado. Incluso la configuración MongoDB fuera de la caja, por lo que a menudo fue criticada, mostró algunas métricas de rendimiento impresionantes.

Todos los riesgos están en ti.

Los beneficios potenciales de MongoDB fueron 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 era que las ventajas anteriores estaban acompañadas de una serie de reservas, algunas de las cuales se enumeran a continuación.

Para ser justos, nadie en 10gen / MongoDB Inc. él no dirá que lo siguiente no es cierto; es solo un compromiso.

• Pérdida de transacciones : las transacciones son una característica importante de muchas bases de datos relacionales (no todas, sino la mayoría). Transaccional significa que puede realizar varias operaciones atómicamente y puede garantizar que los datos se mantendrán consistentes. Por supuesto, con una base de datos NoSQL, la transaccionalidad puede estar dentro del mismo documento, o puede usar confirmaciones de dos fases para obtener semántica transaccional. Pero debe implementar esta funcionalidad usted mismo ... que puede ser una tarea compleja y que requiere mucho tiempo. A menudo no es consciente del problema hasta que ve que los datos en la base de datos caen en estados inaceptables, porque es imposible garantizar la atomicidad de las operaciones. Nota: muchos me dijeron que las transacciones aparecieron en MongoDB 4.0 el año pasado, pero con varias limitaciones. La conclusión del artículo sigue siendo la misma: evalúe cómo la tecnología satisface sus necesidades.
  
• Pérdida de integridad relacional (claves foráneas) : si hay una relación en sus datos, entonces debe aplicarla en la aplicación. Tener una base de datos que cumpla con estas relaciones eliminará una parte significativa del trabajo de la aplicación y, por lo tanto, de sus programadores.
  
• Falta de capacidad para aplicar la estructura de datos : los esquemas estrictos a veces se convierten en un gran problema, pero también es un mecanismo poderoso para una buena estructuración de datos, si se usa correctamente. Las bases de datos de documentos como MongoDB proporcionan una increíble flexibilidad de esquema, pero esta flexibilidad elimina la responsabilidad de mantener limpios los datos. Si no se ocupa de ellos, al final tendrá que escribir una gran cantidad de código en la aplicación para tener en cuenta los datos que no están almacenados en la forma que espera. Como nuestra compañía suele decir Simple Thread ... algún día la aplicación se reescribirá y los datos vivirán para siempre. Nota: MongoDB admite la validación de esquema: es útil, pero no proporciona las mismas garantías que en una base de datos relacional. En primer lugar, agregar o modificar una verificación de esquema no afecta los datos existentes en la colección. Usted mismo 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 nativo / pérdida del ecosistema de herramientas : el advenimiento de SQL se ha convertido en 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 diseñar 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 las bases de datos SQL: desde el IDE hasta las herramientas de informes. Ir a una base de datos que no admite SQL significa que no puede usar la mayoría de estas herramientas o que necesita convertir los datos a SQL para usarlas, y esto puede ser más difícil de lo que piensa.

Muchos desarrolladores que recurrieron a MongoDB realmente no entendieron las compensaciones, y a menudo se lanzaron de cabeza, configurándolo como el almacén de datos principal. Después de esto, a menudo era increíblemente difícil regresar.

¿Qué podría haberse hecho de manera diferente?

No todos saltaron de cabeza y tocaron el fondo. Pero muchos proyectos instalaron la base MongoDB donde simplemente no encajaba, y tendrán que vivir con ella durante muchos años más. Si estas organizaciones pasaron algún tiempo y consideraron metódicamente la elección de tecnologías, 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 evaluar tecnologías, como "Marco para introducir tecnologías en organizaciones de software" y "Marco para evaluar tecnologías de software" , pero me parece que esta es una complejidad innecesaria.

Muchas tecnologías pueden evaluarse razonablemente haciendo solo dos preguntas básicas. El problema es encontrar personas que puedan responder de manera responsable ante ellos, gastando tiempo buscando respuestas y sin prejuicios.

Si no encuentra ningún problema, no necesita una nueva herramienta. El punto

Pregunta 1: ¿Qué problemas estoy tratando de resolver?

Si no encuentra ningún problema, no necesita una nueva herramienta. El punto No es necesario buscar una solución y luego encontrar un problema. Si no ha encontrado un problema que una nueva tecnología no resuelve mucho mejor que su tecnología existente, entonces no hay nada que discutir. Si está considerando usar esta tecnología porque vio cómo otros la usan, considere los problemas que enfrentan y pregunte si tiene esos problemas. Es fácil aceptar la tecnología porque otros la usan, la dificultad radica en comprender si enfrenta los mismos problemas.

Pregunta 2: ¿Qué estoy perdiendo?

Esta es ciertamente una pregunta más difícil, porque hay que cavar y comprender bien tanto la tecnología antigua como la nueva. A veces, no puede entender realmente uno nuevo hasta que construya algo con él o tenga un empleado con esa experiencia.

Si no tiene ni lo uno ni lo otro, entonces tiene sentido pensar en la mínima inversión posible para determinar el valor de esta herramienta. Y si realiza una inversión, ¿qué tan difícil será revertir la decisión?

La gente siempre estropea todo

Intentando responder a estas preguntas de la manera más imparcial posible, recuerda una cosa: tienes que luchar con la naturaleza humana. Hay una serie de sesgos cognitivos que deben superarse para evaluar la tecnología de manera efectiva. Aquí hay algunos:

• El efecto de unirse a la mayoría : todo el mundo lo sabe, pero aún es difícil luchar con él. Solo asegúrese de que la tecnología realmente coincida con sus necesidades reales.
  
• El efecto de la novedad : muchos desarrolladores tienden a subestimar las tecnologías con las que han estado trabajando durante mucho tiempo y a sobrestimar las ventajas de la nueva tecnología. No solo los programadores, todos están sujetos a este sesgo cognitivo.
  
• El efecto de las características positivas : tendemos a ver qué es y perdemos de vista lo que falta. Esto puede conducir al caos en combinación con el efecto de novedad, porque no solo sobreestima la nueva tecnología, sino que también ignora sus deficiencias .

Una evaluación objetiva no es fácil, pero comprender los sesgos cognitivos básicos ayudará a tomar decisiones más racionales.

Resumen

Cuando aparece una cierta innovación, dos preguntas deben responderse con mucho cuidado:

• ¿Esta herramienta resuelve un problema real?
  
• ¿Entendemos bien los compromisos?

Si no puede responder con confianza estas dos preguntas, retroceda unos pasos y piense.

Entonces, ¿MongoDB fue generalmente la elección correcta? Por supuesto que si; Como con la mayoría de las tecnologías de ingeniería, esto depende de muchos factores. Entre los que respondieron estas dos preguntas, muchos se han beneficiado de MongoDB y continúan beneficiándose de él. Quien no haya hecho esto, espero que haya recibido una valiosa y no muy dolorosa lección sobre el movimiento a lo largo del ciclo exagerado.

Descargo de responsabilidad

Quiero aclarar que no tengo ni amor ni odio por MongoDB. Es solo que no tuvimos problemas para los cuales MongoDB es el más adecuado. Sé que 10gen / MongoDB Inc. Al principio, actuó con audacia, estableciendo valores predeterminados inseguros y promoviendo MongoDB en todas partes (especialmente en hackatones) como una solución universal para trabajar con cualquier información. 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.