Fa poc ho vaig descobrir (diuen per canvis de llicència). Això em va fer pensar perquè en els últims anys he vist un munt d'articles sobre el terrible que és MongoDB i com ningú no l'hauria d'utilitzar mai. Però durant aquest temps, MongoDB s'ha convertit en un producte molt més madur. Què va passar? Tot l'odi es deu realment a errors en la comercialització primerenca d'un nou SGBD? O la gent només utilitza MongoDB als llocs equivocats?
Si creieu que estic defensant MongoDB, llegiu-lo al final de l'article.
Nova tendència
He estat treballant a la indústria del programari durant més anys dels que puc dir, però encara només he estat exposat a una petita part de les tendències que han afectat la nostra indústria. He estat testimoni de l'auge de 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... la llista és interminable. Cada any apareixen noves tendències. Alguns s'esvaeixen ràpidament, mentre que d'altres canvien fonamentalment la forma en què es desenvolupa el programari.
Cada nova tendència crea una emoció general: la gent salta a bord o veu el soroll generat pels altres i segueix la multitud. Aquest procés està codificat per Gartner a . Tot i que és controvertida, aquesta línia de temps descriu aproximadament què passa amb les tecnologies abans que acabin esdevenint útils.
Però de tant en tant apareix una nova innovació (o té una segona vinguda, com en aquest cas) impulsada només per una implementació concreta. En el cas de NoSQL, el bombo va ser molt impulsat per l'aparició i l'augment meteòric de MongoDB. MongoDB no va iniciar aquesta tendència: de fet, les grans empreses d'Internet van començar a tenir problemes per processar grans quantitats de dades, fet que va provocar el retorn de bases de dades no relacionals. El moviment global va començar amb projectes com Bigtable de Google i Cassandra de Facebook, però va ser MongoDB la que es va convertir en la implementació de bases de dades NoSQL més coneguda i accessible a la qual van tenir accés la majoria de desenvolupadors.
Nota: podeu pensar que estic confonent les bases de dades de documents amb bases de dades de columna, magatzems de claus/valors o qualsevol dels nombrosos altres tipus de magatzems de dades que es troben sota la definició general de NoSQL. I tens raó. Però en aquell moment regnava el caos. Tothom està obsessionat amb NoSQL, s'ha convertit en tothom absolutament necessari, tot i que molts no van veure les diferències en les diferents tecnologies. Per a molts, MongoDB s'ha convertit en sinònim de NoSQL.
I els desenvolupadors s'hi van llançar. La idea d'una base de dades sense esquema que s'escala màgicament per resoldre qualsevol problema era força temptadora. Cap al 2014, semblava que a tot arreu que fa un any s'utilitzava una base de dades relacional com MySQL, Postgres o SQL Server començava a desplegar bases de dades MongoDB. Quan se li va preguntar per què, podríeu obtenir una resposta del banal "aquesta és l'escala de la web" a la més reflexiva "les meves dades estan molt estructurades i encaixen bé en una base de dades sense esquema".
És important recordar que MongoDB, i les bases de dades de documents en general, resolen una sèrie de problemes amb les bases de dades relacionals tradicionals:
- Esquema estricte: amb una base de dades relacional, si heu generat dades dinàmicament, us haureu de crear un munt de columnes de dades "diverses" aleatòries, introduir-hi taques de dades o utilitzar la configuració. ...tot això té importants inconvenients.
- Dificultat per escalar: Si hi ha tantes dades que no encaixen en un servidor, MongoDB va oferir mecanismes per permetre escalar a diverses màquines.
- Modificacions complexes de circuits: sense migracions! En una base de dades relacional, canviar l'estructura de la base de dades pot ser un gran problema (sobretot quan hi ha moltes dades). MongoDB va ser capaç de simplificar molt el procés. I ho va fer tan fàcil que només podeu actualitzar el circuit a mesura que aneu i seguir endavant molt ràpidament.
- Rendiment de gravació: El rendiment de MongoDB va ser bo, sobretot quan es va configurar correctament. Fins i tot la configuració fora de la caixa de MongoDB, per la qual es va criticar sovint, va mostrar uns números de rendiment impressionants.
Tots els riscos són sobre tu
Els beneficis potencials de MongoDB eren enormes, especialment per a determinades classes de problemes. Si llegiu la llista anterior sense entendre el context i sense experiència, podeu tenir la impressió que MongoDB és realment un SGBD revolucionari. L'únic problema va ser que els avantatges esmentats anteriorment venien amb una sèrie d'advertències, algunes de les quals s'enumeren a continuació.
Per ser justos, ningú a 10gen/MongoDB Inc. no diré que el següent no és cert, només són compromisos.
- Transaccions perdudes: Les transaccions són una característica bàsica de moltes bases de dades relacionals (no totes, però la majoria). Transaccional vol dir que podeu realitzar múltiples operacions atòmicament i garantir que les dades es mantenen coherents. Per descomptat, amb una base de dades NoSQL, la transaccionalitat pot estar dins d'un sol document, o podeu utilitzar commits en dues fases per obtenir semàntica transaccional. Però haureu d'implementar aquesta funcionalitat vosaltres mateixos... que pot ser una tasca difícil i que requereix molt de temps. Sovint no t'adones que hi ha un problema fins que no veus que les dades de la base de dades acaben en estats no vàlids perquè no es pot garantir l'atomicitat de les operacions. Nota: Molta gent em va dir que MongoDB 4.0 va introduir transaccions l'any passat, però amb algunes limitacions. La conclusió de l'article segueix sent la mateixa: avalueu fins a quin punt la tecnologia satisfà les vostres necessitats.
- Pèrdua d'integritat relacional (claus estrangera): Si les vostres dades tenen relacions, haureu d'aplicar-les a l'aplicació. Tenir una base de dades que respecti aquestes relacions suposarà una gran part del treball de l'aplicació i, per tant, dels vostres programadors.
- Manca de capacitat per aplicar l'estructura de dades: Els esquemes estrictes de vegades poden ser un gran problema, però també són un mecanisme potent per a una bona estructuració de dades si s'utilitzen amb prudència. Les bases de dades de documents com MongoDB ofereixen una flexibilitat d'esquema increïble, però aquesta flexibilitat elimina la responsabilitat de mantenir netes les dades. Si no els cuideu, acabareu escrivint molt de codi a la vostra aplicació per tenir en compte les dades que no s'emmagatzemen en la forma que espereu. Com diem sovint a la nostra empresa Simple Thread... l'aplicació algun dia es reescriurà, però les dades viuran per sempre. Nota: MongoDB admet la comprovació d'esquemes: és útil, però no ofereix les mateixes garanties que en una base de dades relacional. En primer lloc, afegir o canviar una comprovació d'esquema no afecta les dades existents a la col·lecció. Depèn de vostè assegurar-se que actualitzeu les dades segons el nou esquema. Decideix tu mateix si això és suficient per a les teves necessitats.
- Llenguatge de consulta natiu / pèrdua de l'ecosistema d'eines: L'arribada de SQL va ser una revolució absoluta i res ha canviat des d'aleshores. És un llenguatge increïblement potent, però també força complex. La necessitat de construir consultes de bases de dades en un llenguatge nou que consta de fragments JSON es considera un gran pas enrere per les persones que tenen experiència treballant amb SQL. Hi ha tot un univers d'eines que interactuen amb bases de dades SQL, des d'IDE fins a eines d'informes. Passar a una base de dades que no admet SQL significa que no podeu utilitzar la majoria d'aquestes eines o que heu de traduir les dades a SQL per utilitzar-les, cosa que pot ser més difícil del que penseu.
Molts desenvolupadors que van recórrer a MongoDB no entenien realment els avantatges i sovint es van posar de cap a instal·lar-lo com a magatzem de dades principal. Després d'això, sovint era increïblement difícil tornar.
Què es podria haver fet de manera diferent?
No tothom va saltar de cap i va tocar el fons. Però molts projectes han instal·lat MongoDB en llocs on simplement no encaixava, i hauran de conviure amb ell durant molts anys. Si aquestes organitzacions haguessin passat una estona i haguessin pensat metòdicament a través de les seves opcions tecnològiques, moltes haurien fet decisions diferents.
Com triar la tecnologia adequada? Hi ha hagut diversos intents de crear un marc sistemàtic per a l'avaluació de la tecnologia, com ara и , però em sembla que això és una complexitat innecessària.
Moltes tecnologies es poden avaluar intel·ligentment fent només dues preguntes bàsiques. El problema és trobar persones que els puguin respondre de manera responsable, prenent-se el temps per trobar les respostes i sense prejudicis.
Si no teniu cap problema, no necessiteu una eina nova. Punt.
Pregunta 1: Quins problemes estic intentant resoldre?
Si no teniu cap problema, no necessiteu una eina nova. Punt. No cal buscar una solució i després inventar un problema. A menys que hàgiu trobat un problema que la nova tecnologia soluciona molt millor que la vostra tecnologia existent, no hi ha res a parlar aquí. Si esteu pensant en utilitzar aquesta tecnologia perquè heu vist que altres l'utilitzen, penseu en quins problemes s'enfronten i pregunteu si teniu aquests problemes. És fàcil acceptar una tecnologia perquè altres l'utilitzen, el repte és entendre si t'enfrontes als mateixos problemes.
Pregunta 2: Què em perdo?
Sens dubte, aquesta és una pregunta més difícil perquè haureu d'aprofundir i tenir una bona comprensió tant de la tecnologia antiga com de la nova. De vegades no pots entendre-ne un de nou fins que no n'hagis construït o no tinguis algú amb aquesta experiència.
Si no teniu cap dels dos, té sentit pensar en la inversió mínima possible per determinar el valor d'aquest instrument. I un cop feta la inversió, com de difícil serà revertir la decisió?
La gent sempre ho arruïna tot
Quan intenteu respondre aquestes preguntes de la manera més imparcial possible, recordeu una cosa: haureu de lluitar contra la naturalesa humana. Hi ha una sèrie de biaixos cognitius que s'han de superar per avaluar eficaçment la tecnologia. Aquests són només alguns:
- - tothom sap d'ell, però encara és difícil lluitar contra ell. Només assegureu-vos que la tecnologia s'ajusti realment a les vostres necessitats reals.
- — Molts desenvolupadors tendeixen a subestimar les tecnologies amb les quals han treballat durant molt de temps i a sobreestimar els beneficis de les noves tecnologies. No només es tracta de programadors, tothom és susceptible a aquest biaix cognitiu.
- - Tenim tendència a veure què hi ha i perdre de vista el que falta. Això pot conduir al caos quan es combina amb l'efecte novetat, ja que no només sobrevalores inherentment la nova tecnologia, sinó que també ignores les seves deficiències..
L'avaluació objectiva no és fàcil, però comprendre els biaixos cognitius subjacents us ajudarà a prendre decisions més racionals.
Resum
Sempre que apareix una innovació, cal respondre amb molta cura dues preguntes:
- Aquesta eina resol un problema real?
- Entenem bé els compromisos?
Si no pots respondre amb confiança a aquestes dues preguntes, fes uns quants passos enrere i pensa.
Llavors, MongoDB era fins i tot l'opció correcta? Per descomptat que sí; Com passa amb la majoria de tecnologies d'enginyeria, això depèn de molts factors. Entre els que van respondre aquestes dues preguntes, molts s'han beneficiat de MongoDB i continuen fent-ho. Per a aquells que no ho van fer, espero que hàgiu après una lliçó valuosa i no massa dolorosa sobre com moure's pel cicle de l'exageració.
Exempció de responsabilitat
Vull aclarir que no tinc ni una relació d'amor ni d'odi amb MongoDB. Simplement no hem tingut el tipus de problemes que MongoDB és més adequat per resoldre. Sé que 10gen/MongoDB Inc. va ser molt agosarat al principi, establint valors predeterminats insegurs i promocionant MongoDB a tot arreu (especialment als hackatons) com una solució universal per treballar amb qualsevol dada. Probablement va ser una mala decisió. Però confirma l'enfocament descrit aquí: aquests problemes es podrien detectar molt ràpidament fins i tot amb una avaluació superficial de la tecnologia.
Font: www.habr.com