Ég komst nýlega að því (segja þeir vegna leyfisbreytinga). Þetta fékk mig til að hugsa vegna þess að á síðustu árum hef ég séð fullt af greinum um hversu hræðilegt MongoDB er og hvernig enginn ætti að nota það. En á þessum tíma hefur MongoDB orðið miklu þroskaðri vara. Hvað gerðist? Er allt hatrið virkilega vegna mistaka í fyrstu markaðssetningu nýs DBMS? Eða er fólk bara að nota MongoDB á röngum stöðum?
Ef þér finnst ég vera að verja MongoDB, vinsamlegast lestu í lok greinarinnar.
Nýtt stefna
Ég hef starfað í hugbúnaðariðnaðinum í fleiri ár en ég get sagt, en ég hef samt aðeins orðið var við lítinn hluta af þeim straumum sem hafa slegið í gegn í iðnaði okkar. Ég hef orðið vitni að uppgangi 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain ... listinn er endalaus. Á hverju ári birtast ný trend. Sumir hverfa fljótt á meðan aðrir breyta því hvernig hugbúnaður er þróaður í grundvallaratriðum.
Sérhver ný stefna skapar almenna spennu: annaðhvort hoppar fólk um borð eða sér hávaðann frá öðrum og fylgir hópnum. Þetta ferli er staðfest af Gartner í . Þótt hún sé umdeild lýsir þessi tímalína í grófum dráttum hvað verður um tækni áður en hún verður að lokum gagnleg.
En af og til kemur ný nýjung fram (eða kemur aftur, eins og í þessu tilfelli) sem er knúin áfram af aðeins einni ákveðinni útfærslu. Þegar um NoSQL var að ræða var efla spennan að miklu leyti knúin áfram af tilkomu og loftslagshækkun MongoDB. MongoDB byrjaði ekki þessa þróun: í raun fóru stór internetfyrirtæki að eiga í vandræðum með að vinna mikið magn af gögnum, sem leiddi til þess að gagnagrunnar sem ekki voru tengdir skiluðu. Heildarhreyfingin byrjaði með verkefnum eins og Bigtable frá Google og Cassandra frá Facebook, en það var MongoDB sem varð þekktasta og aðgengilegasta NoSQL gagnagrunnsútfærslan sem flestir forritarar höfðu aðgang að.
Athugið: Þú gætir haldið að ég sé að rugla saman skjalagagnagrunnum við dálkagagnagrunna, lykil-/gildageymslur eða einhverja af þeim fjölmörgu öðrum gerðum gagnageymslu sem falla undir almennu NoSQL skilgreininguna. Og það er rétt hjá þér. En á þeim tíma ríkti glundroði. Allir eru helteknir af NoSQL, það eru allir orðnir algerlega nauðsynlegt, þó að margir hafi ekki séð muninn á mismunandi tækni. Fyrir marga er MongoDB orðið samheiti við NoSQL.
Og hönnuðirnir punched á það. Hugmyndin um kerfislausan gagnagrunn sem stækkar á töfrandi hátt til að leysa hvaða vandamál sem er var frekar freistandi. Í kringum 2014 virtist sem alls staðar þar sem fyrir ári síðan notaði venslagagnagrunnur eins og MySQL, Postgres eða SQL Server byrjaði að dreifa MongoDB gagnagrunnum. Þegar þú varst spurður hvers vegna gætirðu fengið svar frá hinu banala „þetta er umfang vefsins“ yfir í hinu yfirvegaða „gögnin mín eru mjög lauslega byggð og passa vel inn í gagnagrunn án skema.
Það er mikilvægt að muna að MongoDB, og skjalagagnagrunnar almennt, leysa fjölda vandamála með hefðbundnum venslagagnagrunnum:
- Strangt kerfi: Með tengslagagnagrunni, ef þú ert með breytilega mynduð gögn, þá neyðist þú til að búa til fullt af handahófi "ýmsir" dálka af gögnum, troða gögnum þar inn eða nota stillingar ...allt hefur þetta verulega galla.
- Erfiðleikar við að skala: Ef það er svo mikið af gögnum að það passi ekki á einum netþjóni, bauð MongoDB upp á kerfi til að gera það kleift að skalast yfir margar vélar.
- Flóknar breytingar á hringrás: engir fólksflutningar! Í venslagagnagrunni getur breyting á uppbyggingu gagnagrunnsins verið mikið vandamál (sérstaklega þegar það er mikið af gögnum). MongoDB tókst að einfalda ferlið til muna. Og það gerði það svo auðvelt að þú getur bara uppfært hringrásina þegar þú ferð og haldið áfram mjög hratt.
- Upptaka frammistöðu: MongoDB árangur var góður, sérstaklega þegar hann er rétt stilltur. Jafnvel út-af-the-box stillingar MongoDB, sem hún var oft gagnrýnd fyrir, sýndi glæsilegar frammistöðutölur.
Öll áhætta er á þér
Mögulegur ávinningur af MongoDB var gríðarlegur, sérstaklega fyrir ákveðna flokka vandamála. Ef þú lest ofangreindan lista án þess að skilja samhengið og án reynslu gætirðu fengið á tilfinninguna að MongoDB sé sannarlega byltingarkennd DBMS. Eina vandamálið var að ávinningunum sem taldir eru upp hér að ofan fylgdu ýmsir fyrirvarar, sem sumir eru taldir upp hér að neðan.
Til að vera sanngjarn, enginn hjá 10gen/MongoDB Inc. mun ekki segja að eftirfarandi sé ekki rétt, þetta eru bara málamiðlanir.
- Töpuð viðskipti: Færslur eru kjarnaeiginleiki margra venslagagnagrunna (ekki allir, en flestir). Transactional þýðir að þú getur framkvæmt margar aðgerðir í frumeindakerfi og getur tryggt að gögnin haldist í samræmi. Auðvitað, með NoSQL gagnagrunni, getur viðskipti verið innan eins skjals, eða þú getur notað tveggja fasa skuldbindingar til að fá viðskiptamerkingarfræði. En þú verður að útfæra þessa virkni sjálfur... sem getur verið erfitt og tímafrekt verkefni. Oft áttarðu þig ekki á því að vandamálið er til staðar fyrr en þú sérð að gögnin í gagnagrunninum lenda í ógildum ríkjum vegna þess að ekki er hægt að tryggja atomvirkni aðgerða. Athugið: Margir sögðu mér að MongoDB 4.0 kynnti viðskipti á síðasta ári, en með nokkrum takmörkunum. Afleiðingin frá greininni er sú sama: metið hversu vel tæknin uppfyllir þarfir þínar.
- Tap á samskiptaheilleika (erlendir lyklar): Ef gögnin þín hafa tengsl, þá verður þú að nota þau í forritinu. Að hafa gagnagrunn sem virðir þessi tengsl mun taka mikla vinnu af forritinu og þar með forriturunum þínum.
- Skortur á getu til að beita uppbyggingu gagna: Strangt skema getur stundum verið mikið vandamál, en þau eru líka öflugur búnaður fyrir góða uppbyggingu gagna ef þau eru notuð skynsamlega. Skjalagagnagrunnar eins og MongoDB veita ótrúlegan skemasveigjanleika, en þessi sveigjanleiki fjarlægir ábyrgðina á að halda gögnunum hreinum. Ef þú hugsar ekki um þá endar þú með því að skrifa mikinn kóða í forritið þitt til að gera grein fyrir gögnum sem eru ekki geymd á því formi sem þú býst við. Eins og við segjum oft hjá fyrirtækinu okkar Simple Thread... forritið verður einhvern tíma endurskrifað en gögnin munu lifa að eilífu. Athugið: MongoDB styður skemaathugun: það er gagnlegt, en veitir ekki sömu tryggingar og í venslagagnagrunni. Í fyrsta lagi hefur það ekki áhrif á núverandi gögn í safninu að bæta við eða breyta skemaathugun. Það er undir þér komið að tryggja að þú uppfærir gögnin í samræmi við nýja skemað. Ákveddu sjálfur hvort þetta dugi fyrir þínum þörfum.
- Innfæddur fyrirspurnarmál / tap á vistkerfi verkfæra: Tilkoma SQL var algjör bylting og ekkert hefur breyst síðan þá. Þetta er ótrúlega kraftmikið tungumál en líka frekar flókið. Þörfin á að búa til gagnagrunnsfyrirspurnir á nýju tungumáli sem samanstendur af JSON brotum er litið á sem stórt skref aftur á bak af fólki sem hefur reynslu af að vinna með SQL. Það er allur heimur af verkfærum sem hafa samskipti við SQL gagnagrunna, allt frá IDE til skýrslutækja. Að flytja í gagnagrunn sem styður ekki SQL þýðir að þú getur ekki notað flest þessi verkfæri eða þú þarft að þýða gögnin yfir í SQL til að nota þau, sem getur verið erfiðara en þú heldur.
Margir forritarar sem sneru sér að MongoDB skildu í raun ekki málamiðlanir og köfuðu oft á hausinn í að setja það upp sem aðalgagnageymslu þeirra. Eftir þetta var oft ótrúlega erfitt að koma til baka.
Hvað hefði verið hægt að gera öðruvísi?
Það hoppuðu ekki allir á hausinn og lentu í botninum. En mörg verkefni hafa sett upp MongoDB á stöðum þar sem það passaði einfaldlega ekki - og þau munu þurfa að búa við það í mörg ár fram í tímann. Ef þessar stofnanir hefðu eytt tíma og íhugað tæknival sitt á aðferðum, hefðu margir tekið aðra valkosti.
Hvernig á að velja rétta tækni? Nokkrar tilraunir hafa verið gerðar til að búa til kerfisbundinn ramma fyrir tæknimat, s.s и , en mér sýnist þetta vera óþarfa flókið.
Hægt er að meta marga tækni á skynsamlegan hátt með því að spyrja aðeins tveggja grundvallarspurninga. Vandamálið er að finna fólk sem getur svarað þeim á ábyrgan hátt, gefur sér tíma til að finna svörin og án hlutdrægni.
Ef þú stendur ekki frammi fyrir neinum vandamálum þarftu ekki nýtt verkfæri. Punktur.
Spurning 1: Hvaða vandamál er ég að reyna að leysa?
Ef þú stendur ekki frammi fyrir neinum vandamálum þarftu ekki nýtt verkfæri. Punktur. Það er engin þörf á að leita lausna og finna síðan upp vandamál. Nema þú hafir lent í vandamáli sem nýja tæknin leysir verulega betur en núverandi tækni, þá er ekkert að ræða hér. Ef þú ert að íhuga að nota þessa tækni vegna þess að þú hefur séð aðra nota hana skaltu hugsa um hvaða vandamál þeir standa frammi fyrir og spyrja hvort þú eigir við þessi vandamál að etja. Það er auðvelt að samþykkja tækni vegna þess að aðrir nota hana, áskorunin er að skilja hvort þú stendur frammi fyrir sömu vandamálum.
Spurning 2: Hvers er ég að missa af?
Þetta er örugglega erfiðari spurning því þú verður að grafa þig inn og hafa góðan skilning á bæði gömlu og nýju tækninni. Stundum geturðu í raun ekki skilið nýjan fyrr en þú hefur byggt eitthvað með honum eða hefur einhvern með þá reynslu.
Ef þú hefur hvorugt, þá er skynsamlegt að hugsa um lágmarks mögulega fjárfestingu til að ákvarða verðmæti þessa gernings. Og þegar þú hefur fjárfest, hversu erfitt verður það að snúa ákvörðuninni við?
Fólk eyðileggur alltaf allt
Þegar þú reynir að svara þessum spurningum eins hlutlausan og mögulegt er, mundu eitt: þú verður að berjast gegn mannlegu eðli. Það er fjöldi vitræna hlutdrægni sem þarf að sigrast á til að meta tækni á áhrifaríkan hátt. Hér eru aðeins nokkrar:
- - allir vita af honum, en það er samt erfitt að berjast við hann. Gakktu úr skugga um að tæknin passi raunverulega við raunverulegar þarfir þínar.
- — Margir þróunaraðilar hafa tilhneigingu til að vanmeta tækni sem þeir hafa unnið með í langan tíma og ofmeta kosti nýrrar tækni. Það eru ekki bara forritarar, allir eru viðkvæmir fyrir þessari vitsmunalegu hlutdrægni.
- - Okkur hættir til að sjá hvað er þarna og missa sjónar á því sem vantar. Þetta getur leitt til glundroða þegar það er blandað saman við nýjungaráhrifin, þar sem þú ofmetur ekki aðeins nýja tækni í eðli sínu, heldur hunsar einnig galla hennar.
Hlutlægt mat er ekki auðvelt, en að skilja undirliggjandi vitræna hlutdrægni mun hjálpa þér að taka skynsamlegri ákvarðanir.
Yfirlit
Alltaf þegar nýjung kemur fram þarf að svara tveimur spurningum af mikilli varúð:
- Leysir þetta tól raunverulegt vandamál?
- Skiljum við málamiðlanir vel?
Ef þú getur ekki svarað þessum tveimur spurningum með öryggi skaltu taka nokkur skref til baka og hugsa.
Svo var MongoDB jafnvel rétti kosturinn? Auðvitað já; Eins og með flestar verkfræðitækni veltur þetta á mörgum þáttum. Meðal þeirra sem svöruðu þessum tveimur spurningum hafa margir notið góðs af MongoDB og halda því áfram. Fyrir þá sem gerðu það ekki, vona ég að þú hafir lært dýrmæta og ekki of sársaukafulla lexíu um að fara í gegnum efla hringrásina.
Fyrirvari
Ég vil taka það fram að ég á hvorki ástar- né haturssambandi við MongoDB. Við höfum bara ekki lent í svona vandamálum sem MongoDB er best til þess fallin að leysa. Ég veit að 10gen/MongoDB Inc. var mjög djörf í fyrstu, setti óörugg vanskil og kynnti MongoDB alls staðar (sérstaklega á hackathons) sem alhliða lausn til að vinna með hvaða gögn sem er. Það var líklega slæm ákvörðun. En það staðfestir nálgunina sem lýst er hér: þessi vandamál gætu fundist mjög fljótt jafnvel með yfirborðslegu mati á tækninni.
Heimild: www.habr.com