Nedávno som sa dozvedel, že (hovoria, kvôli zmenám v licencii). To ma prinútilo zamyslieť sa nad tým, že v posledných rokoch som videl množstvo článkov o tom, aká je MongoDB hrozná a že by ju nikto nemal používať. Ale počas tejto doby sa MongoDB stala oveľa zrelším produktom. Čo sa stalo? Skutočne všetka nenávisť vyplýva z chýb na začiatku marketingu novej DBMS? Alebo ľudia jednoducho používajú MongoDB tam, kde by nemali?
Ak vám náhodou pripadá, že obhajujem MongoDB, prosím, prečítajte si na konci článku.
Nový trend
V softvérovej industrii pracujem dlhšie, než je slušné povedať, ale aj tak som zažil iba malú časť trendov, ktoré zasiahli našu oblasť. Bol som svedkom vzostupu 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchainu… zoznam je nekonečný. Každý rok vznikajú nové tendencie. Niektoré rýchlo zhasnú, iné zásadne menia spôsob vývoja softvéru.
Okolo každého nového trendu sa vytvára akési všeobecné vzrušenie: ľudia buď sami naskakujú do lode, alebo vidia hluk, ktorý generujú iní - a idú za davom. Tento proces kodifikovala spoločnosť Gartner v . Aj keď je to kontroverzné, tento graf približne opisuje, čo sa deje s technológiami, skôr ako sa nakoniec stávajú užitočnými na používanie.
Ale občas sa objaví (alebo nastane druhý príchod, ako v tomto prípade) nová inovácia, poháňaná iba jednou konkrétnou jej implementáciou. V prípade NoSQL bol hype silne podmienený vznikom a rýchlym vzostupom MongoDB. Nie MongoDB spustila tento trend: naozaj v veľkých internetových spoločnostiach začali problémy so spracovaním veľkých objemov dát, ktoré viedli k návratu nerelationalných DB. Celkové hnutie odštartovalo takými projektmi, ako je Bigtable od Google a Cassandra od Facebooku, ale práve MongoDB sa stala najznámejšou a najprístupnejšou implementáciou databázy NoSQL, ku ktorej mali prístup väčšina vývojárov.
Poznámka: môžete si myslieť, že zamieňam dokumentové databázy s stĺpcovými databázami, skladiskami kľúčov/hodnôt alebo akýmkoľvek z množstva iných typov skladísk dát, ktoré spadajú pod všeobecné definície NoSQL. A máte pravdu. Ale v tej dobe vládol chaos. Všetci boli posadnutí NoSQL, všetci na tom frčali. absolútne nevyhnutné, aj keď mnohí nevideli rozdiely v rôznych technológiách. Pre mnohých sa MongoDB stala synonymom NoSQL.
A vývojári sa na ňu vrhli. Myšlienka databázy bez schémy, ktorá sa mágicky škáluje na riešenie akéhokoľvek problému, bola veľmi lákavá. Okolo roku 2014 sa zdalo, že tam, kde pred rokom používali relačné databázy ako MySQL, Postgres alebo SQL Server, začali nasadzovať databázy MongoDB. Na otázku prečo, ste mohli dostať odpoveď od banálneho „to je škálovanie webu“ po premyslenejšiu „moje dáta sú veľmi slabo štruktúrované a dobre sa hodia do databázy bez schémy.“
Je dôležité si uvedomiť, že MongoDB a databázy dokumentov vo všeobecnosti riešia rad problémov s tradičnými relačnými databázami:
- Prísna schéma: s relačnou databázou, ak máte dynamicky generované dáta, musíte buď vytvoriť množstvo náhodných „rozdielnych“ stĺpcov, napchať tam blob dáta alebo použiť konfiguráciu … všetky tieto možnosti majú významné nevýhody.
- Ťažkosti s škálovaním: ak je dát tak veľa, že sa nezmestia na jeden server, MongoDB ponúkala mechanizmy, ktoré umožňovali ich škálovanie na viacerých strojoch.
- Zložitá modifikácia schémy: žiadne migrácie! V relačnej databáze môže byť zmena štruktúry DB obrovským problémom (najmä keď sa dát stáva veľmi veľa). MongoDB dokázala znateľne zjednodušiť proces. A urobila to tak jednoduché, že jednoducho môžete aktualizovať schému za chodu a veľmi rýchlo postúpiť ďalej.
- Výkon zápisu: výkon MongoDB bol dobrý, najmä pri správnom nastavení. Aj konfigurácia MongoDB priamo z krabice, za ktorú ju často kritizovali, ukazovala niektoré pôsobivé výkonnostné parametre.
Všetky riziká sú na vás
Potenciálne výhody MongoDB boli obrovské, najmä pre určité triedy problémov. Ak si prečítate vyššie uvedený zoznam bez porozumenia kontextu a nemáte skúsenosti, môže vzniknúť dojem, že MongoDB je naozaj revolučný RDBMS. Jediný problém spočíval v tom, že vyššie uvedené výhody boli sprevádzané radom upozornení, z ktorých niektoré sú uvedené nižšie.
Spravodlivosti radi, nikto v 10gen/MongoDB Inc. nepovie, že nasledujúce nie je pravda, to sú len kompromisy.
- Strata transakcií: transakcie sú základnou vlastnosťou mnohých relačných databáz (nie všetkých, ale väčšiny). Transakčnosť znamená, že môžete vykonávať niekoľko operácií atomicky a môžete zaručiť, že dáta zostanú konzistentné. Samozrejme, s databázou NoSQL môže byť transakčnosť v rámci jedného dokumentu alebo môžete použiť dvojfázové záväzky na získanie transakčnej sémantiky. Ale túto funkčnosť si budete musieť implementovať sami... čo môže byť zložitá a náročná úloha. Často si neuvedomíte problémy, kým neuvidíte, že dáta v DB sa dostanú do neprijateľných stavov, pretože nie je možné zaručiť atomickosť operácií. Poznámka: Mnohí mi povedali, že v minulom roku sa v MongoDB 4.0 objavili transakcie, ale s niekoľkými obmedzeniami. Záver z článku ostáva rovnaký: zhodnoťte, ako technológia vyhovuje vašim potrebám.
- Strata relačnej integritnej integrity (externé kľúče): ak máte vo svojich údajoch vzťahy, budete ich musieť implementovať v aplikácii. Mať DB, ktorá dodržiava tieto vzťahy, eliminuje značnú časť práce s aplikáciou a tým aj s vašimi programátormi.
- Nemožnosť aplikovať štruktúru údajov: prísne schémy sa niekedy stávajú veľkým problémom, ale sú tiež mocným mechanizmom dobrého štruktúrovania údajov, ak ich rozumne používate. Dokumentové DB, ako MongoDB, poskytujú neuveriteľnú flexibilitu schémy, ale táto flexibilita zbavuje zodpovednosti za udržanie údajov v čistote. Ak sa o ne nepostaráte, nakoniec budete musieť napísať v aplikácii veľa kódu na zohľadnenie údajov, ktoré sa ukladajú v forme, ktorú neočakávate. Ako sa často hovorí v našej spoločnosti Simple Thread... aplikáciu niekedy preprogramujú, ale dáta budú žiť navždy. Poznámka: MongoDB podporuje overovanie schémy; je to užitočné, ale neposkytuje rovnaké záruky ako relačná databáza. Predovšetkým, pridanie alebo zmena overovania schémy nemá vplyv na existujúce údaje v kolekcii. Musíte sa sami uistiť, že aktualizujete údaje v súlade s novou schémou. Rozhodnite sa sami, či je to dostatočné pre vaše potreby.
- Vlastný jazyk dopytov / strata ekosystému nástrojov: vznik SQL bol absolútnou revolúciou a odvtedy sa nič nezmenilo. Je to neuveriteľne mocný jazyk, ale tiež dosť zložitý. Potreba konštruovať dopyty do databázy v novom jazyku zloženom z fragmentov JSON je považovaná za veľký krok späť ľuďmi, ktorí majú skúsenosti s SQL. Existuje celá univerzita nástrojov, ktoré komunikujú s databázami SQL: od IDE až po nástroje na reporting. Prechod na databázu, ktorá nepodporuje SQL, znamená, že nemôžete používať väčšinu týchto nástrojov, alebo budete musieť previesť údaje do SQL, aby ste ich mohli použiť, čo môže byť zložitejšie, než si myslíte.
Mnohí vývojári, ktorí prešli na MongoDB, nepochopili veľmi kompromise a často sa vrhli po hlave, inštalujúc ju ako hlavné úložisko údajov. Po takomto kroku bolo často neuveriteľne ťažké sa vrátiť späť.
Čo by sa dalo urobiť inak?
Nie všetci sa vrhli po hlave a narazili na dno. Ale niekoľko projektov nainštalovalo databázu MongoDB tam, kde jednoducho nepasovala – a budú musieť s ňou žiť ešte mnoho rokov. Keby si tieto organizácie venovali čas a systematicky zvážili výber technológie, mnohí by urobili iný výber.
Ako si vybrať vhodnú technológiu? Existovalo niekoľko pokusov o vytvorenie systematického rámca na hodnotenie technológií, ako je a , ale myslím si, že je to zbytočná zložitosť.
Mnohé technológie je možné rozumne hodnotiť, ak si položíte len dve základné otázky. Problém spočíva v hľadaní ľudí, ktorí na ne môžu zodpovedne odpovedať, a ktorí strávia čas hľadaním odpovedí bez predsudkov.
Ak sa nestretávate s nejakým problémom, nový nástroj nepotrebujete. Bodka.
Otázka 1: Aké problémy sa snažím vyriešiť?
Ak sa nestretávate s nejakým problémom, nepotrebujete nový nástroj. Bodka. Netreba hľadať riešenie a potom si vymýšľať problém. Ak sa nestretávate s problémom, ktorý nová technológia nerieši výrazne lepšie ako vaša súčasná technológia, potom o tom nie je čo diskutovať. Ak zvažujete použitie tejto technológie, pretože ste videli, ako ju používajú iní, zamyslite sa nad tým, s akými problémami sa stretávajú, a spýtajte sa, či máte takéto problémy. Je ľahké prijať technológiu len preto, že ju používajú iní, ťažké je pochopiť, či sa stretávate s tými istými problémami.
Otázka 2: O čo prichádzam?
To je bezpochyby ťažšia otázka, pretože budete musieť hlboko skúmať a dobre pochopiť starú aj novú technológiu. Niekedy nemôžete naozaj pochopiť novú, kým si nepostavíte niečo s jej pomocou alebo nemáte zamestnanca s takými skúsenosťami.
Ak nemáte ani jedno, potom má zmysel zamyslieť sa nad minimálnymi možnými investíciami na určenie hodnoty tohto nástroja. A ak investujete, ako ťažké bude zrušiť to rozhodnutie?
Ľudia vždy všetko kazia
Keď sa snažíte odpovedať na tieto otázky čo najobjektívnejšie, pamätajte na jednu vec: budete sa musieť vyrovnávať s ľudskou prirodzenosťou. Existuje množstvo kognitívnych skreslení, ktoré musíte prekonať, aby ste efektívne zhodnotili technológiu. Tu je len niekoľko z nich:
- — všetci o ňom vedia, ale aj tak sa s ním ťažko bojuje. Uistite sa, že technológia naozaj vyhovuje vašim skutočným potrebám.
- — mnohí vývojári majú tendenciu podceňovať technológie, s ktorými pracovali dlhší čas, a nadhodnocovať prínosy novej technológie. Nie len programátori, všetci sú náchylní na toto kognitívne skreslenie.
- — máme tendenciu vidieť to, čo je, a prehliadať to, čo chýba. To môže spôsobiť chaos v kombinácii s efektom novosti, pretože nie len v podstate nadhodnocujete novú technológiu, ale aj ignorujete jej nedostatky..
Objektívne hodnotenie nie je jednoduché, ale porozumenie základným kognitívnym skresleniam pomôže prijať rozumnejšie rozhodnutia.
Zhrnutie
Keď sa objaví nejaká inovácia, je potrebné opatrne si položiť dve otázky:
- Rieši tento nástroj reálny problém?
- Dobre chápeme kompromisy?
Ak na tieto dve otázky nemôžete s istotou odpovedať, urobte niekoľko krokov späť a zamyslite sa.
Bola MongoDB naozaj správnou voľbou? Samozrejme, že áno; ako pri väčšine inžinierskych technológií závisí od mnohých faktorov. Mnohí, ktorí si na tieto dve otázky odpovedali, profitovali z MongoDB a naďalej z nej profitujú. Tí, ktorí nie, dúfam, že získali cennú a nie príliš bolestivú lekciu o pohybe v hype cykle.
Zrieknutie sa zodpovednosti
Chcem objasniť, že necítim ani lásku, ani nenávisť k MongoDB. Jednoducho sme nemali také problémy, na riešenie ktorých by bola MongoDB najlepšia. Viem, že 10gen/MongoDB Inc. na začiatku konala veľmi odvážne, nastavujúc nebezpečné predvolené hodnoty a propagujúc MongoDB všade (najmä na hackathonoch) ako univerzálne riešenie na prácu s akýmikoľvek údajmi. Pravdepodobne to bolo zlé rozhodnutie. Ale potvrdzuje to v tomto článku popísaný prístup: tieto problémy sa dali rýchlo odhaliť aj pri povrchovej analýze technológie.
Zdroj: habr.com
