Hivi majuzi nimegundua hilo Red Hat huondoa usaidizi wa MongoDB kutoka kwa Satellite (sema, kwa sababu ya mabadiliko ya leseni). Ilinifanya nifikirie kuwa katika miaka michache iliyopita nimeona rundo la nakala kuhusu jinsi MongoDB ilivyo mbaya na kwamba hakuna mtu anayepaswa kuitumia. Lakini wakati huu, MongoDB imekuwa bidhaa iliyokomaa zaidi. Nini kimetokea? Je! chuki yote ni kwa sababu ya makosa mwanzoni mwa uuzaji wa DBMS mpya? Au watu wanatumia MongoDB mahali pabaya?

Ikiwa ghafla unahisi kama ninatetea MongoDB, tafadhali soma kanusho mwishoni mwa makala.

Mwenendo mpya

Nimekuwa katika tasnia ya programu kwa miaka zaidi kuliko inavyostahili kusema, lakini bado nimekuwa sehemu tu ya mitindo ambayo iligusa tasnia yetu. Nimeshuhudia kuongezeka kwa 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain… orodha haina mwisho. Kila mwaka kuna mwelekeo mpya. Baadhi zinafifia haraka, huku zingine zinabadilisha kimsingi jinsi programu inavyotengenezwa.

Karibu na kila mwelekeo mpya, msisimko fulani wa jumla huundwa: watu wanaweza kuruka ndani ya mashua wenyewe, au wanaona kelele inayotolewa na wengine - na kufuata umati. Utaratibu huu umeratibiwa na Gartner in Mzunguko wa Hype. Ingawa inaweza kujadiliwa, grafu hii inaelezea takribani kile kinachotokea kwa teknolojia kabla ya kuwa muhimu kwa matumizi.

Lakini mara kwa mara kuna (au kuna kuja kwa pili, kama ilivyo katika kesi hii) uvumbuzi mpya, unaoendeshwa na utekelezaji mmoja tu maalum. Kwa upande wa NoSQL, hype iliendeshwa sana na ujio na kupanda kwa hali ya hewa ya MongoDB. MongoDB haikuanza hali hii: kwa kweli, makampuni makubwa ya mtandao yalianza kuwa na matatizo na usindikaji wa kiasi kikubwa cha data, ambayo imesababisha kurudi kwa hifadhidata zisizo za uhusiano. Harakati za jumla zilianza na miradi kama vile Bigtable ya Google na Cassandra ya Facebook, lakini ilikuwa MongoDB ambayo ikawa utekelezaji maarufu na unaoweza kufikiwa wa hifadhidata ya NoSQL ambayo watengenezaji wengi walipata ufikiaji.

Kumbuka: Unaweza kufikiria kuwa ninachanganya hifadhidata za hati na hifadhidata za safuwima, duka za vitufe/thamani, au aina zingine zozote za hifadhi za data ambazo ziko chini ya ufafanuzi wa jumla wa NoSQL. Na wewe ni sahihi. Lakini wakati huo, machafuko yalitawala. Kila mtu anavutiwa na NoSQL, imekuwa kila kitu kabisa muhimu, ingawa wengi hawakuona tofauti katika teknolojia tofauti. Kwa wengi, MongoDB imekuwa sawa na NoSQL.

Na watengenezaji waliruka juu yake. Wazo la hifadhidata isiyo na schema ambayo ina mizani ya kichawi kutatua shida yoyote ilikuwa ya kuvutia sana. Karibu 2014, ilionekana kuwa kila mahali hifadhidata ya uhusiano kama vile MySQL, Postgres au SQL Server ilitumika mwaka mmoja uliopita, hifadhidata za MongoDB zilikuwa zikitumwa. Ulipoulizwa kwa nini, unaweza kupata majibu kutoka kwa banal "hiki ndicho kipimo cha wavuti" hadi "data yangu imeundwa kwa urahisi sana na inafaa vizuri kwenye hifadhidata bila schema."

Ni muhimu kukumbuka kuwa MongoDB, na hifadhidata za hati kwa ujumla, husuluhisha shida kadhaa na hifadhidata za jadi za uhusiano:

• Mpango mkali: na hifadhidata ya uhusiano, ikiwa umetoa data kwa nguvu, unalazimishwa kuunda rundo la safu wima za data "tofauti", kushinikiza matone ya data huko, au kutumia usanidi. EAV... yote haya yana mapungufu makubwa.
• Ugumu wa kuongeza: Iwapo kuna data nyingi kiasi kwamba haitoshei kwenye seva moja, MongoDB ilitoa mbinu za kuiruhusu kupanua kwenye mashine nyingi.
• Marekebisho magumu ya mzunguko: hakuna uhamiaji! Katika hifadhidata ya uhusiano, kubadilisha muundo wa hifadhidata inaweza kuwa shida kubwa (haswa wakati kuna data nyingi). MongoDB imeweza kurahisisha sana mchakato. Na kuifanya iwe rahisi sana kwamba unaweza tu kusasisha schema popote ulipo na kuendelea haraka sana.
• Andika utendaji: Utendaji wa MongoDB ulikuwa mzuri, haswa wakati umewekwa vizuri. Hata usanidi wa nje wa kisanduku wa MongoDB, ambayo mara nyingi ilikosolewa, ilionyesha takwimu za utendaji za kuvutia.

Hatari zote ziko juu yako

Faida zinazowezekana za MongoDB zilikuwa kubwa, haswa kwa aina fulani za shida. Ukisoma orodha hapo juu bila kuelewa muktadha na kutokuwa na uzoefu, basi unaweza kupata maoni kwamba MongoDB ni DBMS ya mapinduzi. Tatizo pekee lilikuwa kwamba manufaa yaliyoorodheshwa hapo juu yalikuja na idadi ya tahadhari, ambazo baadhi zimeorodheshwa hapa chini.

Ili kuwa sawa, hakuna mtu katika 10gen/MongoDB Inc. hatasema yafuatayo si kweli, haya ni maelewano tu.

• Kupotea kwa shughuliJ: Miamala ni kipengele cha msingi cha hifadhidata nyingi za uhusiano (sio zote, lakini nyingi). Muamala unamaanisha kuwa unaweza kufanya shughuli nyingi kiotomi na unaweza kuhakikisha kuwa data inasalia sawa. Kwa kweli, ukiwa na hifadhidata ya NoSQL, utendakazi unaweza kuwa ndani ya hati moja, au unaweza kutumia ahadi za awamu mbili kupata semantiki za shughuli. Lakini utalazimika kutekeleza utendakazi huu mwenyewe ... ambayo inaweza kuwa kazi ngumu na inayotumia wakati. Mara nyingi hautambui shida hadi uone kuwa data kwenye hifadhidata inaingia katika hali batili kwa sababu haiwezekani kudhibitisha atomicity ya shughuli. Kumbuka: Nimeambiwa na wengi kwamba shughuli zilianzishwa katika MongoDB 4.0 mwaka jana, lakini kwa mapungufu fulani. Hitimisho kutoka kwa kifungu bado ni sawa: tathmini jinsi teknolojia inafaa mahitaji yako.
• Kupoteza uadilifu wa uhusiano (funguo za kigeni): ikiwa data yako ina uhusiano, basi itabidi uitumie kwenye programu. Kuwa na hifadhidata inayoheshimu mahusiano haya kutachukua kazi nyingi kutoka kwa programu na kwa hivyo kwa watayarishaji wako wa programu.
• Kutokuwa na uwezo wa kutumia muundo wa data: Miradi kali wakati mwingine inaweza kuwa tatizo kubwa, lakini pia ni njia yenye nguvu ya uundaji mzuri wa data ikiwa itatumiwa kwa busara. Hifadhidata za hati kama vile MongoDB hutoa unyumbufu wa ajabu wa schema, lakini kubadilika huko kunaondoa jukumu la kuweka data safi. Usipozitunza, utaishia kuandika msimbo mwingi katika programu yako ili kuhesabu data ambayo haijahifadhiwa katika fomu unayotarajia. Kama wanavyosema mara kwa mara katika kampuni yetu Simple Thread… programu itaandikwa upya siku moja, lakini data itaishi milele. Kumbuka: MongoDB inasaidia uthibitishaji wa schema, ambayo ni muhimu lakini haitoi hakikisho sawa na hifadhidata ya uhusiano. Kwanza kabisa, kuongeza au kubadilisha uthibitishaji wa taratibu hakuathiri data iliyopo kwenye mkusanyiko. Lazima uhakikishe kuwa unasasisha data kulingana na schema mpya. Amua mwenyewe ikiwa hii inatosha kwa mahitaji yako.
• Lugha ya kuuliza mwenyewe / upotezaji wa mfumo wa ikolojia wa zana: Ujio wa SQL ulikuwa mapinduzi kabisa, na hakuna kilichobadilika tangu wakati huo. Ni lugha yenye nguvu sana, lakini pia ngumu sana. Haja ya kuunda hoja za hifadhidata katika lugha mpya, inayojumuisha vipande vya JSON, inachukuliwa kuwa hatua kubwa ya kurudi nyuma na watu ambao wana uzoefu na SQL. Kuna ulimwengu mzima wa zana zinazoingiliana na hifadhidata za SQL, kutoka kwa IDE hadi zana za kuripoti. Kuhamia kwenye hifadhidata ambayo haiauni SQL inamaanisha kuwa huwezi kutumia nyingi ya zana hizi, au unahitaji kubadilisha data hadi SQL ili kuzitumia, ambayo inaweza kuwa ngumu zaidi kuliko unavyofikiria.

Watengenezaji wengi waliogeukia MongoDB hawakuelewa kabisa utendakazi, na mara nyingi waliiweka kama hifadhi yao ya msingi ya data. Baada ya hapo, mara nyingi ilikuwa ngumu sana kurudi.

Ni nini kingefanywa tofauti?

Sio kila mtu aliruka kichwa kwanza na kuanguka chini. Lakini miradi michache imeweka msingi wa MongoDB ambapo haikutoshea - na watalazimika kuishi nayo kwa miaka mingi zaidi. Iwapo mashirika haya yangechukua muda kufikiria kimantiki chaguo lao la teknolojia, mengi yangefanya chaguo tofauti.

Jinsi ya kuchagua teknolojia sahihi? Kumekuwa na majaribio kadhaa ya kuunda mfumo wa kimfumo wa tathmini ya teknolojia, kama vile "Mfumo wa utekelezaji wa teknolojia katika mashirika ya programu" и "Framefork ya kutathmini teknolojia ya programu", lakini inaonekana kwangu kuwa huu ni ugumu usio wa lazima.

Teknolojia nyingi zinaweza kuthaminiwa kwa akili kwa kuuliza maswali mawili tu ya msingi. Tatizo liko katika kutafuta watu wanaoweza kuwajibu kwa uwajibikaji, kuchukua muda kutafuta majibu na bila upendeleo.

Ikiwa hukabiliwi na tatizo fulani, huhitaji zana mpya. Nukta.

Swali la 1: Ni matatizo gani ninajaribu kutatua?

Ikiwa hukabiliwi na tatizo fulani, huhitaji zana mpya. Nukta. Hakuna haja ya kutafuta suluhu na kisha kuja na tatizo. Isipokuwa unakabiliwa na tatizo ambalo teknolojia mpya haitatatui vizuri zaidi kuliko teknolojia yako iliyopo, basi hakuna cha kujadili hapa. Ikiwa unafikiria kutumia teknolojia hii kwa sababu umewaona wengine wakiitumia, fikiria matatizo wanayopata na uulize ikiwa una matatizo hayo. Ni rahisi kukumbatia teknolojia kwa sababu wengine wanaitumia, ugumu ni kujua ikiwa unakabiliwa na masuala sawa.

Swali la 2: Ninakosa nini?

Hakika hili ni swali gumu zaidi, kwa sababu unapaswa kuchimba na kuelewa teknolojia ya zamani na mpya vizuri. Wakati mwingine huwezi kuelewa mpya hadi ujenge kitu nayo au uwe na mwenzako aliye na uzoefu huo.

Ikiwa huna aidha, basi ni jambo la busara kufikiria kuhusu uwekezaji wa chini unaowezekana ili kubainisha thamani ya chombo hiki. Na ikiwa utafanya uwekezaji, itakuwa ngumu kiasi gani kubadili uamuzi?

Watu daima huharibu kila kitu

Katika kujaribu kujibu maswali haya bila upendeleo iwezekanavyo, kumbuka jambo moja: unapaswa kupigana na asili ya kibinadamu. Kuna idadi ya upendeleo wa utambuzi ambao lazima ushindwe ili kutathmini teknolojia kwa ufanisi. Hapa kuna machache tu:

• Athari ya kujiunga na wengi Kila mtu anajua kuhusu yeye, lakini bado ni vigumu kupigana naye. Hakikisha tu kwamba teknolojia inakidhi mahitaji yako halisi.
• athari mpya Watengenezaji wengi huwa na tabia ya kudharau teknolojia ambazo wamekuwa wakifanya kazi nazo kwa muda mrefu na kukadiria faida za teknolojia mpya. Sio watengenezaji programu tu, kila mtu yuko chini ya upendeleo huu wa utambuzi.
• Athari Chanya ya Sifa Tunaelekea kuona kile kilicho na kupoteza kuona kile ambacho sio. Hii inaweza kusababisha machafuko, pamoja na athari ya riwaya, kwani sio tu unathamini sana teknolojia mpya, lakini pia hupuuza mapungufu yake..

Tathmini ya lengo si rahisi, lakini kuelewa upendeleo wa msingi wa utambuzi kutakusaidia kufanya maamuzi ya busara zaidi.

Muhtasari

Wakati uvumbuzi unaonekana, maswali mawili yanahitaji kujibiwa kwa uangalifu mkubwa:

• Je, chombo hiki kinatatua tatizo halisi?
• Je, tunaelewa vizuri ubadilishanaji wa bei?

Ikiwa huwezi kujibu maswali haya mawili kwa ujasiri, chukua hatua chache nyuma na ufikirie.

Kwa hivyo la MongoDB kwa ujumla lilikuwa chaguo sahihi? Bila shaka ndiyo; kama ilivyo kwa teknolojia nyingi za uhandisi, inategemea mambo mengi. Miongoni mwa waliojibu maswali haya mawili, wengi wamefaidika na MongoDB na wanaendelea kufanya hivyo. Kwa wale ambao hamjapata, natumai mmejifunza somo muhimu na sio chungu sana juu ya kusonga mbele kwa mzunguko wa hype.

Kanusho

Ninataka kufafanua kuwa siipendi wala siichukii MongoDB. Hatukuwa na aina ya matatizo ambayo MongoDB inafaa zaidi kutatua. Ninajua kuwa 10gen/MongoDB Inc. ilifanya kazi kwa ujasiri sana mwanzoni, ikiweka chaguo-msingi zisizo salama na kukuza MongoDB kila mahali (hasa kwenye hackathons) kama suluhisho la kusimama mara moja la kufanya kazi na data yoyote. Pengine ulikuwa uamuzi mbaya. Lakini inathibitisha mbinu iliyoelezwa hapa: matatizo haya yanaweza kugunduliwa haraka sana hata kwa tathmini ya juu juu ya teknolojia.

Chanzo: mapenzi.com