Nalaman ko kamakailan (sabi nila dahil sa mga pagbabago sa lisensya). Naisip ko ito dahil sa nakalipas na ilang taon nakakita ako ng isang tonelada ng mga artikulo tungkol sa kung gaano kakila-kilabot ang MongoDB at kung paano hindi ito dapat gamitin ng sinuman. Ngunit sa panahong ito, ang MongoDB ay naging isang mas mature na produkto. Anong nangyari? Ang lahat ba ng galit ay talagang dahil sa mga pagkakamali sa maagang marketing ng isang bagong DBMS? O ginagamit lang ba ng mga tao ang MongoDB sa mga maling lugar?
Kung sa tingin mo ay pinagtatanggol ko ang MongoDB, pakibasa sa dulo ng artikulo.
Bagong trend
Nagtrabaho ako sa industriya ng software nang higit pa sa masasabi ko, ngunit nalantad pa rin ako sa isang maliit na bahagi ng mga uso na tumama sa ating industriya. Nasaksihan ko ang pagtaas ng 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... walang katapusan ang listahan. Bawat taon, lumalabas ang mga bagong uso. Ang ilan ay mabilis na nawawala, habang ang iba ay pangunahing nagbabago sa paraan ng pagbuo ng software.
Ang bawat bagong trend ay lumilikha ng pangkalahatang kasabikan: ang mga tao ay maaaring tumalon, o makita ang ingay na nabuo ng iba at sinusundan ang karamihan. Ang prosesong ito ay na-codify ni Gartner sa . Bagama't kontrobersyal, ang timeline na ito ay halos naglalarawan kung ano ang nangyayari sa mga teknolohiya bago sila maging kapaki-pakinabang.
Ngunit paminsan-minsan ay lumilitaw ang isang bagong pagbabago (o may pangalawang pagdating, tulad ng sa kasong ito) na hinihimok ng isang partikular na pagpapatupad lamang. Sa kaso ng NoSQL, ang hype ay labis na hinimok ng paglitaw at meteoric na pagtaas ng MongoDB. Hindi sinimulan ng MongoDB ang trend na ito: sa katunayan, ang mga malalaking kumpanya sa Internet ay nagsimulang magkaroon ng mga problema sa pagproseso ng malalaking halaga ng data, na humantong sa pagbabalik ng mga database na hindi nauugnay. Nagsimula ang pangkalahatang kilusan sa mga proyekto tulad ng Bigtable ng Google at Cassandra ng Facebook, ngunit ang MongoDB ang naging pinakakilala at naa-access na pagpapatupad ng database ng NoSQL kung saan may access ang karamihan sa mga developer.
Tandaan: Maaari mong isipin na nililito ko ang mga database ng dokumento sa mga columnar database, key/value store, o alinman sa maraming iba pang uri ng data store na nasa ilalim ng pangkalahatang kahulugan ng NoSQL. At tama ka. Ngunit sa oras na iyon ay naghari ang kaguluhan. Ang lahat ay nahuhumaling sa NoSQL, ito ay naging lahat ganap na kinakailangan, bagaman marami ang hindi nakakita ng mga pagkakaiba sa iba't ibang teknolohiya. Para sa marami, naging MongoDB magkasingkahulugan sa NoSQL.
At sinugod ito ng mga developer. Ang ideya ng isang schemaless database na magically scales upang malutas ang anumang problema ay medyo nakatutukso. Sa paligid ng 2014, tila sa lahat ng dako noong nakaraang taon ay gumamit ng relational database tulad ng MySQL, Postgres o SQL Server na nagsimulang mag-deploy ng mga database ng MongoDB. Kapag tinanong kung bakit, maaari kang makakuha ng isang sagot mula sa karaniwang "ito ang sukat ng web" hanggang sa mas maalalahanin na "ang aking data ay napakaluwag na istraktura at akma nang maayos sa isang database na walang schema."
Mahalagang tandaan na ang MongoDB, at ang mga database ng dokumento sa pangkalahatan, ay lumulutas ng ilang problema sa mga tradisyonal na relational database:
- Mahigpit na pamamaraan: Sa isang relational database, kung dynamic na nakabuo ka ng data, mapipilitan kang lumikha ng isang grupo ng mga random na "miscellaneous" na mga column ng data, magtulak ng mga blobs ng data doon, o gumamit ng configuration ...lahat ng ito ay may mga makabuluhang disbentaha.
- Kahirapan sa pag-scale: Kung napakaraming data na hindi ito kasya sa isang server, nag-aalok ang MongoDB ng mga mekanismo upang payagan itong mag-scale sa maraming makina.
- Mga kumplikadong pagbabago sa circuit: walang migrasyon! Sa isang relational database, ang pagbabago ng istraktura ng database ay maaaring maging isang malaking problema (lalo na kapag mayroong maraming data). Nagawa ng MongoDB na lubos na gawing simple ang proseso. At ginawa nitong napakadali na maaari mo lamang i-update ang circuit habang nagpapatuloy ka at napakabilis na magpatuloy.
- Pagganap ng pagre-record: Ang pagganap ng MongoDB ay mabuti, lalo na kapag maayos na na-configure. Kahit na ang out-of-the-box na configuration ng MongoDB, kung saan madalas itong pinupuna, ay nagpakita ng ilang kahanga-hangang mga numero ng pagganap.
Nasa iyo ang lahat ng panganib
Ang mga potensyal na benepisyo ng MongoDB ay napakalaki, lalo na para sa ilang mga klase ng mga problema. Kung babasahin mo ang listahan sa itaas nang hindi nauunawaan ang konteksto at walang karanasan, maaari kang makakuha ng impresyon na ang MongoDB ay tunay na isang rebolusyonaryong DBMS. Ang tanging problema ay ang mga benepisyong nakalista sa itaas ay kasama ng ilang mga caveat, ang ilan sa mga ito ay nakalista sa ibaba.
Upang maging patas, walang sinuman sa 10gen/MongoDB Inc. hindi sasabihin na hindi totoo ang mga sumusunod, ito ay mga kompromiso lamang.
- Nawala ang mga transaksyon: Ang mga transaksyon ay isang pangunahing tampok ng maraming relational database (hindi lahat, ngunit karamihan). Nangangahulugan ang Transaksyonal na makakagawa ka ng maraming operasyon nang atomiko at matitiyak na mananatiling pare-pareho ang data. Siyempre, sa isang database ng NoSQL, ang transactionality ay maaaring nasa loob ng isang dokumento, o maaari kang gumamit ng two-phase commits upang makakuha ng transactional semantics. Ngunit kakailanganin mong ipatupad ang functionality na ito sa iyong sarili... na maaaring maging isang mahirap at matagal na gawain. Kadalasan hindi mo namamalayan na may problema hanggang sa makita mo ang data sa database na napupunta sa mga di-wastong estado dahil hindi matitiyak ang atomicity ng mga operasyon. Tandaan: Maraming tao ang nagsabi sa akin na ipinakilala ng MongoDB 4.0 ang mga transaksyon noong nakaraang taon, ngunit may ilang mga limitasyon. Ang takeaway mula sa artikulo ay nananatiling pareho: suriin kung gaano kahusay ang teknolohiya ay nakakatugon sa iyong mga pangangailangan.
- Pagkawala ng integridad ng relasyon (mga dayuhang susi): Kung may mga ugnayan ang iyong data, kakailanganin mong ilapat ang mga ito sa application. Ang pagkakaroon ng database na gumagalang sa mga relasyong ito ay magdadala ng maraming trabaho sa application at samakatuwid ay ang iyong mga programmer.
- Kakulangan ng kakayahang maglapat ng istraktura ng data: Ang mahigpit na mga schema ay maaaring minsan ay isang malaking problema, ngunit ang mga ito ay isang malakas na mekanismo para sa mahusay na pag-istruktura ng data kung ginamit nang matalino. Ang mga database ng dokumento tulad ng MongoDB ay nagbibigay ng hindi kapani-paniwalang flexibility ng schema, ngunit ang flexibility na ito ay nag-aalis ng responsibilidad para sa pagpapanatiling malinis ng data. Kung hindi mo aalagaan ang mga ito, magtatapos ka sa pagsusulat ng maraming code sa iyong aplikasyon para sa account para sa data na hindi nakaimbak sa form na iyong inaasahan. Gaya ng madalas naming sinasabi sa aming kumpanya na Simple Thread... ang application ay muling isusulat sa ibang araw, ngunit ang data ay mabubuhay magpakailanman. Tandaan: Sinusuportahan ng MongoDB ang schema checking: ito ay kapaki-pakinabang, ngunit hindi nagbibigay ng parehong mga garantiya tulad ng sa isang relational database. Una sa lahat, ang pagdaragdag o pagbabago ng schema check ay hindi makakaapekto sa umiiral na data sa koleksyon. Nasa sa iyo na tiyaking i-update mo ang data ayon sa bagong schema. Magpasya para sa iyong sarili kung ito ay sapat para sa iyong mga pangangailangan.
- Native query language / pagkawala ng tool ecosystem: Ang pagdating ng SQL ay isang ganap na rebolusyon at walang nagbago mula noon. Ito ay isang hindi kapani-paniwalang makapangyarihang wika, ngunit medyo kumplikado din. Ang pangangailangan na bumuo ng mga query sa database sa isang bagong wika na binubuo ng mga fragment ng JSON ay itinuturing na isang malaking hakbang pabalik ng mga taong may karanasan sa pagtatrabaho sa SQL. Mayroong isang buong uniberso ng mga tool na nakikipag-ugnayan sa mga database ng SQL, mula sa mga IDE hanggang sa mga tool sa pag-uulat. Ang paglipat sa isang database na hindi sumusuporta sa SQL ay nangangahulugan na hindi mo magagamit ang karamihan sa mga tool na ito o kailangan mong isalin ang data sa SQL upang magamit ang mga ito, na maaaring maging mas mahirap kaysa sa iyong iniisip.
Maraming mga developer na bumaling sa MongoDB ay hindi talaga nauunawaan ang mga trade-off, at madalas na unang sumabak sa pag-install nito bilang kanilang pangunahing data store. Pagkatapos nito ay madalas na hindi kapani-paniwalang mahirap bumalik.
Ano ang maaaring ginawa sa ibang paraan?
Hindi lahat ay tumalon nang una at tumama sa ilalim. Ngunit maraming mga proyekto ang nag-install ng MongoDB sa mga lugar kung saan ito ay hindi magkasya - at kakailanganin nilang mabuhay kasama nito sa loob ng maraming taon na darating. Kung ang mga organisasyong ito ay gumugol ng ilang oras at maingat na pinag-isipan ang kanilang mga pagpipilian sa teknolohiya, marami ang maaaring gumawa ng iba't ibang mga pagpipilian.
Paano pumili ng tamang teknolohiya? Mayroong ilang mga pagtatangka upang lumikha ng isang sistematikong balangkas para sa pagtatasa ng teknolohiya, tulad ng ΠΈ , ngunit sa tingin ko ito ay hindi kinakailangang kumplikado.
Maraming mga teknolohiya ang maaaring matalinong masuri sa pamamagitan ng pagtatanong lamang ng dalawang pangunahing katanungan. Ang problema ay ang paghahanap ng mga taong makakasagot sa kanila nang responsable, naglalaan ng oras upang mahanap ang mga sagot at walang bias.
Kung hindi ka nahaharap sa anumang problema, hindi mo kailangan ng bagong tool. Dot.
Tanong 1: Anong mga problema ang sinusubukan kong lutasin?
Kung hindi ka nahaharap sa anumang problema, hindi mo kailangan ng bagong tool. Dot. Hindi na kailangang maghanap ng solusyon at pagkatapos ay mag-imbento ng problema. Maliban kung nakatagpo ka ng isang problema na mas mahusay na nalutas ng bagong teknolohiya kaysa sa iyong kasalukuyang teknolohiya, walang dapat pag-usapan dito. Kung isinasaalang-alang mo ang paggamit ng teknolohiyang ito dahil nakita mong ginagamit ito ng iba, pag-isipan kung anong mga problema ang kanilang kinakaharap at itanong kung mayroon kang mga problemang iyon. Madaling tanggapin ang isang teknolohiya dahil ginagamit ito ng iba, ang hamon ay pag-unawa kung nahaharap ka sa parehong mga problema.
Tanong 2: Ano ang kulang sa akin?
Ito ay talagang isang mas mahirap na tanong dahil kailangan mong maghukay at magkaroon ng isang mahusay na pag-unawa sa parehong luma at bagong teknolohiya. Minsan hindi mo talaga mauunawaan ang isang bago hangga't hindi ka nakabuo ng isang bagay gamit ito o may isang taong may ganoong karanasan.
Kung wala ka, makatuwirang isipin ang pinakamababang posibleng pamumuhunan upang matukoy ang halaga ng instrumentong ito. At sa sandaling gumawa ka ng pamumuhunan, gaano kahirap na baligtarin ang desisyon?
Laging sinisira ng mga tao ang lahat
Habang sinusubukan mong sagutin ang mga tanong na ito nang walang kinikilingan hangga't maaari, tandaan ang isang bagay: kailangan mong labanan ang kalikasan ng tao. Mayroong ilang mga cognitive biases na dapat lampasan upang mabisang masuri ang teknolohiya. Narito ang ilan lamang:
- - alam ng lahat ang tungkol sa kanya, ngunit mahirap pa ring labanan siya. Siguraduhin lamang na ang teknolohiya ay aktuwal na tumutugma sa iyong aktwal na mga pangangailangan.
- β Maraming mga developer ang may posibilidad na maliitin ang mga teknolohiyang matagal na nilang pinagtatrabahuhan at labis na binibigyang halaga ang mga benepisyo ng bagong teknolohiya. Hindi lang mga programmer, lahat ay madaling kapitan sa cognitive bias na ito.
- - Madalas nating makita kung ano ang naroroon at mawala sa paningin kung ano ang nawawala. Maaari itong humantong sa kaguluhan kapag isinama sa bagong epekto, dahil hindi mo lamang likas na labis na pinahahalagahan ang bagong teknolohiya, ngunit binabalewala din ang mga pagkukulang nito.
Hindi madali ang pagtatasa ng layunin, ngunit ang pag-unawa sa pinagbabatayan ng mga pagkiling sa pag-iisip ay makakatulong sa iyong gumawa ng mas makatuwirang mga desisyon.
Buod
Sa tuwing may lalabas na pagbabago, dalawang tanong ang dapat sagutin nang may matinding pag-iingat:
- Nalulutas ba ng tool na ito ang isang tunay na problema?
- Naiintindihan ba natin ang mga trade-off?
Kung hindi mo kumpiyansa na masasagot ang dalawang tanong na ito, bumalik ng ilang hakbang at mag-isip.
Kaya ang MongoDB ba ang tamang pagpipilian? Oo naman; Tulad ng karamihan sa mga teknolohiya sa engineering, ito ay nakasalalay sa maraming mga kadahilanan. Sa mga sumagot sa dalawang tanong na ito, marami ang nakinabang sa MongoDB at patuloy na ginagawa ito. Para sa mga hindi, sana natuto kayo ng isang mahalaga at hindi masyadong masakit na aral tungkol sa paglipat sa hype cycle.
Disclaimer
Gusto kong linawin na wala akong relasyon sa pag-ibig o poot sa MongoDB. Wala lang kaming uri ng mga problema na pinakaangkop na lutasin ng MongoDB. Alam ko na ang 10gen/MongoDB Inc. ay napaka-bold sa una, nagtakda ng mga hindi secure na default at nagpo-promote ng MongoDB sa lahat ng dako (lalo na sa mga hackathon) bilang isang unibersal na solusyon para sa pagtatrabaho sa anumang data. Marahil ito ay isang masamang desisyon. Ngunit kinukumpirma nito ang diskarte na inilarawan dito: ang mga problemang ito ay maaaring matukoy nang napakabilis kahit na sa isang mababaw na pagtatasa ng teknolohiya.
Pinagmulan: www.habr.com