Ek het dit onlangs uitgevind (hulle sê as gevolg van lisensie veranderinge). Dit het my aan die dink gesit, want die afgelope paar jaar het ek 'n klomp artikels gesien oor hoe verskriklik MongoDB is en hoe niemand dit ooit moet gebruik nie. Maar gedurende hierdie tyd het MongoDB 'n baie meer volwasse produk geword. Wat het gebeur? Is al die haat werklik te wyte aan foute in die vroeë bemarking van 'n nuwe DBBS? Of gebruik mense net MongoDB op die verkeerde plekke?
As jy voel dat ek MongoDB verdedig, lees asseblief aan die einde van die artikel.
Nuwe neiging
Ek werk al meer jare in die sagteware-industrie as wat ek kan sê, maar ek is steeds net blootgestel aan 'n klein gedeelte van die neigings wat ons bedryf getref het. Ek het die opkoms van 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain gesien ... die lys is eindeloos. Elke jaar verskyn nuwe neigings. Sommige verdwyn vinnig, terwyl ander die manier waarop sagteware ontwikkel word fundamenteel verander.
Elke nuwe neiging skep 'n algemene opwinding: mense spring óf aan boord, óf sien die geraas wat deur ander gegenereer word en volg die skare. Hierdie proses word gekodifiseer deur Gartner in . Alhoewel dit omstrede is, beskryf hierdie tydlyn rofweg wat met tegnologie gebeur voordat dit uiteindelik bruikbaar word.
Maar van tyd tot tyd verskyn 'n nuwe innovasie (of het 'n wederkoms, soos in hierdie geval) gedryf deur slegs een spesifieke implementering. In die geval van NoSQL is die hype sterk gedryf deur die opkoms en meteoriese opkoms van MongoDB. MongoDB het nie hierdie tendens begin nie: in werklikheid het groot internetmaatskappye probleme begin ondervind met die verwerking van groot hoeveelhede data, wat gelei het tot die terugkeer van nie-relasionele databasisse. Die algehele beweging het begin met projekte soos Google se Bigtable en Facebook se Cassandra, maar dit was MongoDB wat die bekendste en toeganklikste NoSQL-databasisimplementering geword het waartoe die meeste ontwikkelaars toegang gehad het.
Let wel: Jy mag dalk dink dat ek dokument databasisse verwar met kolom databasisse, sleutel/waarde winkels, of enige van die talle ander tipes data winkels wat onder die algemene NoSQL definisie val. En jy is reg. Maar in daardie tyd het chaos geheers. Almal is obsessief met NoSQL, dit het almal geword absoluut nodig, hoewel baie nie die verskille in verskillende tegnologieë gesien het nie. Vir baie het MongoDB geword sinoniem GeenSQL.
En die ontwikkelaars het daarop toegeslaan. Die idee van 'n skemalose databasis wat magies skaal om enige probleem op te los, was nogal aanloklik. Rondom 2014 het dit gelyk of oral wat 'n jaar gelede 'n relasionele databasis soos MySQL, Postgres of SQL Server gebruik het, MongoDB-databasisse begin ontplooi het. As jy gevra word hoekom, kan jy 'n antwoord kry van die banale "dit is die skaal van die web" tot die meer deurdagte "my data is baie los gestruktureer en pas goed in 'n databasis sonder 'n skema."
Dit is belangrik om te onthou dat MongoDB, en dokumentdatabasisse in die algemeen, 'n aantal probleme met tradisionele relasionele databasisse oplos:
- Streng skema: Met 'n relasionele databasis, as jy dinamies gegenereerde data het, word jy gedwing om óf 'n klomp ewekansige "verskeie" kolomme data te skep, stukke data daar in te skuif, óf konfigurasie te gebruik ... dit alles het aansienlike nadele.
- Moeilik skaal: As daar soveel data is dat dit nie op een bediener pas nie, het MongoDB meganismes aangebied om dit oor verskeie masjiene te laat skaal.
- Komplekse stroombaanmodifikasies: geen migrasies nie! In 'n relasionele databasis kan die verandering van die databasisstruktuur 'n groot probleem wees (veral wanneer daar baie data is). MongoDB kon die proses aansienlik vereenvoudig. En dit het dit so maklik gemaak dat jy net die stroombaan kan opdateer terwyl jy gaan en baie vinnig aanbeweeg.
- Opname van prestasie: MongoDB-prestasie was goed, veral wanneer dit behoorlik gekonfigureer is. Selfs MongoDB se out-of-the-box-konfigurasie, waarvoor dit dikwels gekritiseer is, het 'n paar indrukwekkende prestasiegetalle getoon.
Alle risiko's is op jou
Die potensiële voordele van MongoDB was enorm, veral vir sekere klasse probleme. As jy die bogenoemde lys lees sonder om die konteks te verstaan en sonder ervaring, kan jy die indruk kry dat MongoDB werklik 'n revolusionêre DBMS is. Die enigste probleem was dat die voordele hierbo gelys het met 'n aantal waarskuwings, waarvan sommige hieronder gelys word.
Om regverdig te wees, niemand by 10gen/MongoDB Inc. sal nie sê dat die volgende nie waar is nie, dit is net kompromieë.
- Verlore transaksies: Transaksies is 'n kernkenmerk van baie relasionele databasisse (nie almal nie, maar die meeste). Transaksionele beteken dat jy veelvuldige bewerkings atomies kan uitvoer en kan verseker dat die data konsekwent bly. Natuurlik, met 'n NoSQL-databasis, kan transaksionaliteit binne 'n enkele dokument wees, of jy kan twee-fase-verbintenisse gebruik om transaksionele semantiek te kry. Maar jy sal self hierdie funksionaliteit moet implementeer ... wat 'n moeilike en tydrowende taak kan wees. Dikwels besef jy nie dat daar 'n probleem is nie totdat jy sien dat die data in die databasis in ongeldige toestande beland omdat die atomiteit van bedrywighede nie gewaarborg kan word nie. Let wel: Baie mense het vir my gesê dat MongoDB 4.0 verlede jaar transaksies bekendgestel het, maar met sekere beperkings. Die wegneemete van die artikel bly dieselfde: evalueer hoe goed die tegnologie aan jou behoeftes voldoen.
- Verlies aan relasionele integriteit (vreemde sleutels): As jou data verwantskappe het, sal jy dit in die aansoek moet toepas. Om 'n databasis te hê wat hierdie verhoudings respekteer, sal baie van die werk van die toepassing afneem en dus jou programmeerders.
- Gebrek aan vermoë om datastruktuur toe te pas: Streng skemas kan soms 'n groot probleem wees, maar dit is ook 'n kragtige meganisme vir goeie datastrukturering as dit verstandig gebruik word. Dokumentdatabasisse soos MongoDB bied ongelooflike skema-buigsaamheid, maar hierdie buigsaamheid verwyder die verantwoordelikheid om die data skoon te hou. As jy nie vir hulle sorg nie, sal jy uiteindelik baie kode in jou aansoek skryf om rekening te hou met data wat nie gestoor word in die vorm wat jy verwag nie. Soos ons dikwels by ons maatskappy Simple Thread sê... die toepassing sal eendag herskryf word, maar die data sal vir ewig lewe. Let wel: MongoDB ondersteun skemakontrolering: dit is nuttig, maar bied nie dieselfde waarborge as in 'n relasionele databasis nie. Eerstens, die byvoeging of verandering van 'n skemakontrole beïnvloed nie bestaande data in die versameling nie. Dit is aan jou om te verseker dat jy die data volgens die nuwe skema opdateer. Besluit self of dit genoeg is vir jou behoeftes.
- Inheemse navraagtaal / verlies van instrument-ekosisteem: Die koms van SQL was 'n absolute rewolusie en niks het sedertdien verander nie. Dit is 'n ongelooflike kragtige taal, maar ook redelik kompleks. Die behoefte om databasisnavrae te konstrueer in 'n nuwe taal wat uit JSON-fragmente bestaan, word beskou as 'n groot stap terug deur mense wat ondervinding het om met SQL te werk. Daar is 'n hele heelal van gereedskap wat in wisselwerking met SQL-databasisse werk, van IDE's tot verslagdoeningsinstrumente. Om na 'n databasis te skuif wat nie SQL ondersteun nie, beteken dat jy nie die meeste van hierdie gereedskap kan gebruik nie of dat jy die data in SQL moet vertaal om dit te gebruik, wat moeiliker kan wees as wat jy dink.
Baie ontwikkelaars wat hulle tot MongoDB gewend het, het nie regtig die kompromieë verstaan nie, en het dikwels kop eerste geduik om dit as hul primêre datawinkel te installeer. Hierna was dit dikwels ongelooflik moeilik om terug te kom.
Wat kon anders gedoen word?
Nie almal het kop eerste gespring en die bodem getref nie. Maar baie projekte het MongoDB geïnstalleer op plekke waar dit eenvoudig nie gepas het nie – en hulle sal nog baie jare daarmee moet saamleef. As hierdie organisasies 'n geruime tyd spandeer en metodies deur hul tegnologie-keuses gedink het, sou baie verskillende keuses gemaak het.
Hoe om die regte tegnologie te kies? Daar was verskeie pogings om 'n sistematiese raamwerk vir tegnologie-assessering te skep, soos и , maar dit lyk vir my of dit onnodige kompleksiteit is.
Baie tegnologieë kan intelligent geassesseer word deur net twee basiese vrae te vra. Die probleem is om mense te vind wat hulle verantwoordelik kan beantwoord, die tyd neem om die antwoorde te vind en sonder vooroordeel.
As jy nie 'n probleem ondervind nie, het jy nie 'n nuwe instrument nodig nie. Punt.
Vraag 1: Watter probleme probeer ek oplos?
As jy nie 'n probleem ondervind nie, het jy nie 'n nuwe instrument nodig nie. Punt. Dit is nie nodig om na 'n oplossing te soek en dan 'n probleem uit te dink nie. Tensy jy 'n probleem teëgekom het wat die nuwe tegnologie aansienlik beter oplos as jou bestaande tegnologie, is daar niks om hier te bespreek nie. As jy dit oorweeg om hierdie tegnologie te gebruik omdat jy ander dit sien gebruik het, dink aan watter probleme hulle in die gesig staar en vra of jy daardie probleme het. Dit is maklik om 'n tegnologie te aanvaar omdat ander dit gebruik, die uitdaging is om te verstaan of jy dieselfde probleme ondervind.
Vraag 2: Wat mis ek?
Dit is beslis 'n moeiliker vraag, want jy sal moet ingrawe en 'n goeie begrip hê van beide die ou en nuwe tegnologie. Soms kan jy nie regtig 'n nuwe een verstaan voordat jy iets daarmee gebou het of iemand met daardie ervaring het nie.
As jy nie een het nie, is dit sinvol om aan die minimum moontlike belegging te dink om die waarde van hierdie instrument te bepaal. En sodra jy die belegging gemaak het, hoe moeilik sal dit wees om die besluit om te keer?
Mense verwoes altyd alles
Terwyl jy hierdie vrae so onpartydig as moontlik probeer beantwoord, onthou een ding: jy sal die menslike natuur moet beveg. Daar is 'n aantal kognitiewe vooroordele wat oorkom moet word om tegnologie effektief te evalueer. Hier is net 'n paar:
- - almal weet van hom, maar dit is steeds moeilik om teen hom te veg. Maak net seker die tegnologie pas werklik by jou werklike behoeftes.
- — Baie ontwikkelaars is geneig om tegnologieë waarmee hulle lank gewerk het te onderskat en die voordele van nuwe tegnologie te oorskat. Dit is nie net programmeerders nie, almal is vatbaar vir hierdie kognitiewe vooroordeel.
- - Ons is geneig om te sien wat daar is en uit die oog te verloor wat ontbreek. Dit kan tot chaos lei wanneer dit gekombineer word met die nuwigheidseffek, aangesien jy nie net nuwe tegnologie inherent oorwaardeer nie, maar ook die tekortkominge daarvan ignoreer.
Objektiewe assessering is nie maklik nie, maar om die onderliggende kognitiewe vooroordele te verstaan, sal jou help om meer rasionele besluite te neem.
Opsomming
Wanneer 'n innovasie verskyn, moet twee vrae met groot sorg beantwoord word:
- Los hierdie hulpmiddel 'n werklike probleem op?
- Verstaan ons die afwegings goed?
As jy nie met selfvertroue hierdie twee vrae kan beantwoord nie, neem 'n paar treë terug en dink.
So was MongoDB selfs die regte keuse? Natuurlik ja; Soos met die meeste ingenieurstegnologieë, hang dit van baie faktore af. Onder diegene wat hierdie twee vrae beantwoord het, het baie baat gevind by MongoDB en gaan voort om dit te doen. Vir diegene wat dit nie gedoen het nie, ek hoop jy het 'n waardevolle en nie te pynlike les geleer om deur die hype-siklus te beweeg nie.
Vrywaring
Ek wil dit duidelik maak dat ek nie 'n liefdes- of haatverhouding met MongoDB het nie. Ons het net nie die soort probleme gehad wat MongoDB die beste geskik is om op te los nie. Ek weet dat 10gen/MongoDB Inc. was aanvanklik baie dapper, het onveilige verstekstellings gestel en MongoDB oral (veral by hackathons) bevorder as 'n universele oplossing om met enige data te werk. Dit was waarskynlik 'n slegte besluit. Maar dit bevestig die benadering wat hier beskryf word: hierdie probleme kan baie vinnig opgespoor word selfs met 'n oppervlakkige beoordeling van die tegnologie.
Bron: will.com