Hai pouco descubrín iso (por exemplo, debido a cambios de licenza). Fíxome pensar que nos últimos anos vin unha chea de artigos sobre o terrible que é MongoDB e que ninguén debería usalo nunca. Pero durante este tempo, MongoDB converteuse nun produto moito máis maduro. Que pasou? Todo o odio débese realmente a erros ao comezo da comercialización do novo DBMS? Ou a xente só está a usar MongoDB no lugar equivocado?
Se de súpeto sentes que estou a defender MongoDB, le ao final do artigo.
Nova tendencia
Levo máis anos na industria do software do que se pode dicir, pero aínda así só formei parte das tendencias que afectan á nosa industria. Assistín ao aumento de 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain... a lista é infinita. Cada ano hai novas tendencias. Algúns están a desaparecer rapidamente, mentres que outros están cambiando fundamentalmente a forma en que se desenvolve o software.
En torno a cada nova tendencia, créase unha certa emoción xeral: as persoas ou ben saltan ao barco eles mesmos ou ven o ruído xerado por outros e seguen á multitude. Este proceso foi codificado por Gartner en . Aínda que é discutible, este gráfico describe aproximadamente o que acontece coas tecnoloxías antes de que se fagan útiles para o seu uso.
Pero de cando en vez hai (ou hai unha segunda chegada, como neste caso) unha nova innovación, impulsada só por unha implementación específica da mesma. No caso de NoSQL, o bombo foi moi impulsado pola chegada e o ascenso meteórico de MongoDB. MongoDB non iniciou esta tendencia: de feito, as grandes empresas de Internet comezaron a ter problemas para procesar grandes cantidades de datos, o que provocou o retorno de bases de datos non relacionais. O movemento xeral comezou con proxectos como Bigtable de Google e Cassandra de Facebook, pero foi MongoDB a que se converteu na implementación máis famosa e accesible da base de datos NoSQL á que tiñan acceso a maioría dos desenvolvedores.
Nota: Podes pensar que estou confundiendo as bases de datos de documentos coas bases de datos de columnas, os almacéns de claves/valores ou calquera dos outros moitos tipos de almacéns de datos que se inclúen na definición xeral de NoSQL. E tes razón. Pero naquel momento reinaba o caos. Todo o mundo está obsesionado co NoSQL, converteuse en todo absolutamente necesario, aínda que moitos non viron as diferenzas nas diferentes tecnoloxías. Para moitos, MongoDB converteuse sinónimo de NoSQL.
E os desenvolvedores puxéronse sobre el. A idea dunha base de datos sen esquemas que se escala máxicamente para resolver calquera problema era bastante tentadora. Ao redor de 2014, parecía que en todas partes se utilizaba unha base de datos relacional como MySQL, Postgres ou SQL Server hai un ano, as bases de datos de MongoDB estaban sendo despregadas. Cando se lle pregunte por que, podería obter respostas desde o banal "esta é a escala da web" ata o máis reflexivo "os meus datos están moi estruturados e encaixan ben nunha base de datos sen esquema".
É importante lembrar que MongoDB, e as bases de datos de documentos en xeral, solucionan unha serie de problemas coas bases de datos relacionais tradicionais:
- Esquema estrito: cunha base de datos relacional, se tes datos xerados dinámicamente, estás obrigado a crear un montón de columnas de datos "diferentes" aleatorias, inserir os blobs de datos alí ou usar unha configuración ... todo isto ten importantes inconvenientes.
- Dificultade de escalar: Se hai tantos datos que non caben nun servidor, MongoDB ofreceu mecanismos para permitirlle escalar en varias máquinas.
- Modificacións complexas de circuítos: sen migracións! Nunha base de datos relacional, cambiar a estrutura da base de datos pode ser un gran problema (especialmente cando hai moitos datos). MongoDB foi capaz de simplificar moito o proceso. E fíxoo tan sinxelo que podes actualizar o esquema en calquera lugar e seguir moi rápido.
- Escribir performance: O rendemento de MongoDB foi bo, especialmente cando se axustou correctamente. Incluso a configuración de MongoDB lista para usar, pola que a miúdo foi criticada, mostrou algunhas cifras de rendemento impresionantes.
Todos os riscos corren por ti
Os beneficios potenciais de MongoDB eran enormes, especialmente para certas clases de problemas. Se le a lista anterior sen comprender o contexto e non ter experiencia, entón pode ter a impresión de que MongoDB é realmente un DBMS revolucionario. O único problema foi que os beneficios enumerados anteriormente incluían unha serie de advertencias, algunhas das cales se enumeran a continuación.
Para ser xustos, ninguén en 10gen/MongoDB Inc. non dirá que o seguinte non é certo, son só compromisos.
- Perda de transacciónsR: As transaccións son unha característica fundamental de moitas bases de datos relacionais (non todas, pero a maioría). Transaccional significa que pode realizar varias operacións atómicamente e pode garantir que os datos permanecen consistentes. Por suposto, cunha base de datos NoSQL, a transaccionalidade pode estar dentro dun único documento, ou pode usar commits en dúas fases para obter semántica transaccional. Pero terás que implementar esta funcionalidade ti mesmo... o que pode ser unha tarefa difícil e que leva moito tempo. Moitas veces non te das conta do problema ata que ves que os datos da base de datos entran en estados non válidos porque é imposible garantir a atomicidade das operacións. Nota: Moitos dixéronme que as transaccións introducíronse en MongoDB 4.0 o ano pasado, pero con algunhas limitacións. A conclusión do artigo segue sendo a mesma: avalía como a tecnoloxía se adapta ás túas necesidades.
- Perda de integridade relacional (claves estranxeiras): se os teus datos teñen relacións, entón terás que aplicalas na aplicación. Ter unha base de datos que respecte estas relacións levará moito traballo á aplicación e, polo tanto, aos seus programadores.
- Incapacidade para aplicar a estrutura de datos: Os esquemas estritos ás veces poden ser un gran problema, pero tamén son un mecanismo poderoso para unha boa estruturación de datos se se usan con prudencia. As bases de datos de documentos como MongoDB ofrecen unha incrible flexibilidade de esquema, pero esa flexibilidade quita a responsabilidade de manter limpos os datos. Se non os coida, acabará escribindo moito código na súa aplicación para ter en conta os datos que non se almacenan no formulario que espera. Como adoita dicir na nosa empresa Simple Thread... a aplicación será reescrita algún día, pero os datos vivirán para sempre. Nota: MongoDB admite a validación de esquemas, que é útil pero non ofrece as mesmas garantías que unha base de datos relacional. En primeiro lugar, engadir ou cambiar a validación do esquema non afecta aos datos existentes na colección. Debes asegurarte de actualizar os datos segundo o novo esquema. Decida por si mesmo se isto é suficiente para as súas necesidades.
- Linguaxe de consulta propia / perda do ecosistema de ferramentas: A chegada de SQL foi unha revolución absoluta, e nada cambiou desde entón. É unha linguaxe incriblemente poderosa, pero tamén bastante complexa. A necesidade de construír consultas de bases de datos nunha nova linguaxe, consistente en fragmentos JSON, é considerada como un gran paso atrás polas persoas que teñen experiencia con SQL. Existe todo un universo de ferramentas que interactúan coas bases de datos SQL, desde IDE ata ferramentas de informes. Pasar a unha base de datos que non admite SQL significa que non podes usar a maioría destas ferramentas ou que necesitas converter os datos a SQL para usalos, o que pode ser máis difícil do que pensas.
Moitos desenvolvedores que acudiron a MongoDB non entendían realmente as compensacións e moitas veces mergullaron de cabeza para configuralo como o seu almacén de datos principal. Despois diso, moitas veces era incriblemente difícil volver.
Que se puido facer doutro xeito?
Non todos saltaron de cabeza e chocaron contra o fondo. Pero moitos proxectos instalaron a base de MongoDB onde simplemente non encaixaba, e terán que vivir con ela durante moitos anos máis. Se estas organizacións levasen tempo a considerar metódicamente as súas opcións tecnolóxicas, moitas farían unha elección diferente.
Como elixir a tecnoloxía correcta? Houbo varios intentos de crear un marco sistemático para a avaliación da tecnoloxía, como и , pero paréceme que esta é unha complexidade innecesaria.
Moitas tecnoloxías pódense valorar de forma intelixente facendo só dúas preguntas básicas. O problema reside en atopar persoas que poidan responderlles con responsabilidade, dedicándose o tempo a atopar respostas e sen prexuízos.
Se non tes problemas, non necesitas unha nova ferramenta. Punto.
Pregunta 1: Que problemas estou intentando resolver?
Se non tes problemas, non necesitas unha nova ferramenta. Punto. Non é necesario buscar unha solución e despois dar con un problema. A menos que teñas un problema que a nova tecnoloxía non soluciona significativamente mellor que a túa tecnoloxía existente, non hai nada que discutir aquí. Se estás pensando en usar esta tecnoloxía porque viu que outros a usan, pensa nos problemas que están a ter e pregúntalle se tes eses problemas. É doado adoptar a tecnoloxía porque outros a están a usar, a dificultade é saber se estás enfrontando os mesmos problemas.
Pregunta 2: Que me boto de menos?
Esta é certamente unha pregunta máis difícil, porque hai que cavar e comprender ben tanto a vella como a nova tecnoloxía. Ás veces non podes entender un novo ata que non creas algo con el ou tes un colega con esa experiencia.
Se non tes ningunha das dúas, ten sentido pensar no investimento mínimo posible para determinar o valor deste instrumento. E se fai un investimento, que difícil será revertir a decisión?
A xente sempre arruina todo
Ao tentar responder a estas preguntas da forma máis imparcial posible, lembra unha cousa: tes que loitar contra a natureza humana. Hai unha serie de prexuízos cognitivos que deben ser superados para avaliar eficazmente a tecnoloxía. Aquí tes só algúns:
- Todo o mundo sabe del, pero aínda é difícil loitar contra el. Só asegúrate de que a tecnoloxía realmente se adapte ás túas necesidades reais.
- Moitos desenvolvedores tenden a subestimar as tecnoloxías coas que traballaron durante moito tempo e a sobreestimar os beneficios dunha nova tecnoloxía. Non só os programadores, todos están suxeitos a este sesgo cognitivo.
- Tendemos a ver o que é e a perder de vista o que non é. Isto pode levar ao caos, combinado co efecto novidade, xa que non só sobrevalora inherentemente a nova tecnoloxía, senón que tamén ignora as súas deficiencias..
A avaliación obxectiva non é fácil, pero comprender os prexuízos cognitivos subxacentes axudarache a tomar decisións máis racionais.
Resumo
Cando xorde unha innovación, hai que responder con moito coidado a dúas preguntas:
- Esta ferramenta resolve un problema real?
- Somos bos para entender os intercambios?
Se non podes responder con confianza a estas dúas preguntas, retrocede uns pasos e pensa.
Entón, a MongoDB foi xeralmente a opción correcta? Claro que si; como coa maioría das tecnoloxías de enxeñaría, depende de moitos factores. Entre os que responderon a estas dúas preguntas, moitos beneficiáronse de MongoDB e seguen facéndoo. Para aqueles de vós que non o fixestes, espero que aprendades unha lección valiosa e non demasiado dolorosa sobre como pasar polo ciclo de bombo.
Exención de responsabilidade
Quero aclarar que nin amo nin odio a MongoDB. Simplemente non tiñamos o tipo de problemas que MongoDB é máis axeitado para resolver. Coñezo 10gen/MongoDB Inc. actuou con moita audacia ao principio, establecendo valores predeterminados inseguros e promovendo MongoDB en todas partes (especialmente nos hackathons) como unha solución única para traballar con calquera dato. Probablemente foi unha mala decisión. Pero confirma o enfoque aquí descrito: estes problemas poderían detectarse moi rapidamente mesmo cunha avaliación superficial da tecnoloxía.
Fonte: www.habr.com