Recientemente supe que (se dice que es por cambios en la licencia). Esto me hizo reflexionar sobre cómo en los últimos años he visto un montón de artículos diciendo lo terrible que es MongoDB y que nadie debería usarlo nunca. Pero durante este tiempo, MongoDB se ha convertido en un producto mucho más maduro. ¿Qué ha pasado? ¿De verdad todo el odio se debe a errores en el inicio del marketing de esta nueva base de datos? ¿O simplemente la gente aplica MongoDB en lugares inapropiados?
Si de repente sientes que estoy defendiendo a MongoDB, por favor, lee al final del artículo.
Nueva tendencia
He trabajado en la industria del software más años de los que sería apropiado mencionar, pero aun así, me ha tocado solo una pequeña parte de las tendencias que han impactado nuestra industria. He sido testigo del auge de 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain... la lista es interminable. Cada año surgen nuevas tendencias. Algunas desaparecen rápidamente, mientras que otras cambian fundamentalmente la forma en que se desarrolla el software.
Alrededor de cada nueva tendencia se genera una especie de emoción colectiva: las personas o se suben al barco por sí mismas, o ven el alboroto generado por otros y siguen a la multitud. Este proceso fue codificado por la empresa Gartner en el . Aunque es controvertido, este gráfico describe aproximadamente lo que sucede con las tecnologías antes de que finalmente se vuelvan útiles.
Pero de vez en cuando aparece (o ocurre una segunda venida, como en este caso) una nueva innovación impulsada solo por una implementación específica. En el caso de NoSQL, el hype estuvo fuertemente influenciado por la aparición y el rápido ascenso de MongoDB. No fue MongoDB la que inició esta tendencia: en realidad, las grandes empresas de Internet comenzaron a tener problemas para manejar grandes volúmenes de datos, lo que llevó al 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 la que se convirtió en la implementación de base de datos NoSQL más conocida y accesible para la mayoría de los desarrolladores.
Nota: puedes pensar que estoy mezclando bases de datos documentales con bases de datos columnar, almacenes de clave/valor o cualquiera de los numerosos otros tipos de almacenamiento de datos que caen bajo la definición general de NoSQL. Y tienes razón. Pero en aquel tiempo reinaba el caos. Todos estaban obsesionados con NoSQL, a todos les parecía absolutamente es necesario, aunque muchos no vieron diferencias en las distintas tecnologías. Para muchos, MongoDB se convirtió en sinónimo de NoSQL.
Y los desarrolladores se lanzaron a ella. La idea de una base de datos sin esquema que se escalara mágicamente para resolver cualquier problema era bastante atractiva. Alrededor de 2014, parecía que en todos los lugares donde un año antes se utilizaba una base de datos relacional como MySQL, Postgres o SQL Server, estaban implementando bases de datos MongoDB. Si preguntabas por qué, podías obtener respuestas que iban desde lo banal "es la escala de la web" hasta algo más elaborado "mis datos están muy débilmente estructurados y encajan bien en una base de datos sin esquema".
Es importante recordar que MongoDB y las bases de datos de documentos en general resuelven una serie de problemas en comparación con las bases de datos relacionales tradicionales:
- Esquema rígido: con una base de datos relacional, si tienes datos formados dinámicamente, se te obliga a crear un montón de columnas de datos "diferentes" al azar, meter blobs de datos allí o usar una configuración … todo esto tiene desventajas significativas.
- Dificultad para escalar: si hay tantos datos que no caben en un solo servidor, MongoDB ofrecía mecanismos que permitían escalar a múltiples máquinas.
- Modificaciones complejas del esquema: ¡sin migraciones! En una base de datos relacional, cambiar la estructura de la base de datos puede convertirse en un gran problema (especialmente cuando hay muchos datos). MongoDB logró simplificar significativamente este proceso. Y lo hizo tan fácil que puedes simplemente actualizar el esquema sobre la marcha y avanzar rápidamente.
- Rendimiento de escritura: el rendimiento de MongoDB era bueno, especialmente con una configuración adecuada. Incluso la configuración de MongoDB de manera predeterminada, por la que a menudo la criticaban, mostraba algunas métricas de rendimiento impresionantes.
Todos los riesgos son tuyos
Los potenciales beneficios de MongoDB eran enormes, especialmente para ciertos tipos de problemas. Si lees la lista anterior sin entender el contexto y sin experiencia, podrías tener la impresión de que MongoDB es realmente una base de datos revolucionaria. El único problema era que los beneficios mencionados anteriormente venían acompañados de una serie de advertencias, algunas de las cuales se detallan a continuación.
Para ser justos, nadie en 10gen/MongoDB Inc. dirá que lo que se menciona a continuación es mentira, simplemente son compromisos.
- Pérdida de transacciones: las transacciones son una característica principal de muchas bases de datos relacionales (no todas, pero la mayoría). La atomicidad de las transacciones implica que puedes realizar varias operaciones de manera atómica y garantizar que los datos se mantendrán consistentes. Por supuesto, en una base de datos NoSQL, la atomicidad puede ser dentro de un solo documento o puedes utilizar confirmaciones en dos fases para obtener semántica transaccional. Pero tendrás que implementar esta funcionalidad por tu cuenta... lo que puede ser una tarea complicada y que consume tiempo. A menudo, no te das cuenta de los problemas hasta que ves que los datos en la base de datos entran en estados inválidos, porque no es posible garantizar la atomicidad de las operaciones. Nota: muchos me han informado que el año pasado aparecieron transacciones en MongoDB 4.0, pero con varias limitaciones. La conclusión del artículo sigue siendo la misma: evalúa cuánto se adapta la tecnología a tus necesidades.
- Pérdida de integridad relacional (claves externas): si tus datos tienen relaciones, tendrás que aplicarlas en la aplicación. Tener una base de datos que mantenga estas relaciones quitará una parte considerable del trabajo de la aplicación y, por consiguiente, de tus programadores.
- Falta de posibilidad de aplicar estructuras de datos: los esquemas estrictos a veces se convierten en un gran problema, pero también son un poderoso mecanismo para una buena estructuración de datos si se utilizan correctamente. Las bases de datos documentales, como MongoDB, ofrecen una increíble flexibilidad de esquema, pero esta flexibilidad elimina la responsabilidad de mantener los datos limpios. Si no te ocupas de ellos, al final tendrás que escribir mucho código en la aplicación para manejar datos que no están en la forma que esperas. Como se dice a menudo en nuestra empresa Simple Thread... la aplicación será reescrita algún día, pero los datos vivirán para siempre. Nota: MongoDB admite la verificación de esquemas: es útil, pero no ofrece las mismas garantías que una base de datos relacional. En primer lugar, agregar o modificar la verificación de esquemas no afecta los datos existentes en la colección. Debe asegurarse de que está actualizando los datos de acuerdo con el nuevo esquema. Decida por sí mismo si esto es suficiente para sus necesidades.
- Lenguaje de consulta propio / pérdida del ecosistema de herramientas: la aparición de SQL fue una revolución absoluta, y desde entonces nada ha cambiado. Es un lenguaje increíblemente poderoso, pero también bastante complejo. La necesidad de construir consultas a la base de datos en un nuevo lenguaje compuesto de fragmentos JSON se considera un gran paso atrás por las personas con experiencia en SQL. Existe todo un universo de herramientas que interactúan con bases de datos SQL: desde IDE hasta herramientas de informes. Pasarse a una base de datos que no admite SQL significa que no se puede utilizar la mayoría de estas herramientas o que es necesario convertir los datos a SQL para poder usarlos, lo que puede resultar más complicado de lo que piensa.
Muchos desarrolladores que se pasaron a MongoDB no entendían muy bien los compromisos y a menudo se sumergieron de cabeza al instalarlo como su almacenamiento de datos principal. Después de eso, a menudo era increíblemente difícil volver atrás.
¿Qué se podría haber hecho de manera diferente?
No todos se lanzaron de cabeza y chocaron con el fondo. Pero no pocos proyectos instalaron MongoDB en lugares donde simplemente no era adecuada, y tendrán que vivir con ella durante muchos años más. Si estas organizaciones hubieran dedicado un tiempo a pensar de manera metódica en la elección de tecnologías, muchas habrían tomado decisiones diferentes.
¿Cómo elegir la tecnología adecuada? Ha habido varios intentos de crear un marco sistemático para evaluar tecnologías, como y , pero me parece que esto es una complejidad innecesaria.
Muchas tecnologías se pueden evaluar razonablemente formulando solo dos preguntas básicas. El problema radica en encontrar personas que puedan responderlas con responsabilidad, dedicando tiempo a buscar respuestas y sin prejuicios.
Si no enfrenta un problema, no necesita una nueva herramienta. Punto.
Pregunta 1: ¿Qué problemas estoy tratando de resolver?
Si no estás enfrentando un problema, no necesitas una nueva herramienta. Punto. No busques una solución y luego inventes un problema. Si no has encontrado un problema que una nueva tecnología resuelva significativamente mejor que tu tecnología existente, entonces no hay nada que discutir. Si estás considerando usar esta tecnología solo porque has visto cómo la usan otros, piensa en los problemas con los que se enfrentan y pregúntate si tú tienes esos mismos problemas. Es fácil adoptar tecnología porque otros la utilizan; la dificultad radica en entender si enfrentas los mismos problemas.
Pregunta 2: ¿Qué estoy dejando atrás?
Esta es, sin duda, una pregunta más difícil porque tendrás que profundizar y comprender bien tanto la antigua como la nueva tecnología. A veces no puedes realmente entender lo nuevo hasta que construyes algo con ello o hasta que tienes un empleado con esa experiencia.
Si no tienes ni una cosa ni la otra, tiene sentido considerar las inversiones mínimas posibles para determinar el valor de esta herramienta. Y si realizas inversiones, ¿qué tan difícil será revertir la decisión?
La gente siempre lo arruina todo.
Al intentar responder a estas preguntas de la manera más objetiva posible, recuerda una cosa: tendrás que luchar contra la naturaleza humana. Hay varios sesgos cognitivos que debes superar para evaluar una tecnología de manera efectiva. Aquí hay algunos:
- — todos saben de él, pero sigue siendo difícil de combatir. Asegúrate de que la tecnología realmente satisfaga tus necesidades reales.
- — muchos desarrolladores tienden a subestimar las tecnologías con las que han trabajado durante mucho tiempo y sobreestimar las ventajas de la nueva tecnología. No solo los programadores, todos están sujetos a este sesgo cognitivo.
- — tendemos a ver lo que hay y pasamos por alto lo que falta. Esto puede llevar al caos combinado con el efecto de novedad, ya que no solo sobreestimas la nueva tecnología por su propia naturaleza, sino que también ignoras sus desventajas..
Es difícil dar una evaluación objetiva, pero entender las principales distorsiones cognitivas ayudará a tomar decisiones más racionales.
Currículum
Cuando surge una innovación, se debe responder con mucho cuidado a dos preguntas:
- ¿Este instrumento resuelve un problema real?
- ¿Entendemos bien los compromisos?
Si no puedes responder con confianza a estas dos preguntas, da algunos pasos atrás y reflexiona.
¿Era realmente la MongoDB una buena elección? Por supuesto que sí; como en la mayoría de las tecnologías de ingeniería, esto depende de muchos factores. Entre aquellos que respondieron a estas dos preguntas, muchos se beneficiaron de MongoDB y continúan haciéndolo. Quien no lo hizo, espero que haya aprendido una valiosa y no demasiado dolorosa lección sobre el ciclo de exageración.
Descargo de responsabilidad
Quiero aclarar que no siento ni amor ni odio hacia MongoDB. Simplemente, no hemos tenido problemas que fueran mejor resueltos por MongoDB. Sé que 10gen/MongoDB Inc. inicialmente actuó de manera bastante audaz al establecer valores predeterminados inseguros y promocionar MongoDB como una solución universal para manejar cualquier tipo de dato (especialmente en hackatones). Probablemente, fue una mala decisión. Pero esto refuerza el enfoque descrito aquí: estos problemas podían haberse identificado muy rápidamente incluso con una evaluación superficial de la tecnología.
Fuente: habr.com
