Nedávno som to zistil (povedzme kvôli zmenám licencií). Priviedlo ma to k myšlienke, že za posledných pár rokov som videl veľa článkov o tom, aké hrozné je MongoDB a že by ho nikto nikdy nemal používať. Počas tejto doby sa však MongoDB stal oveľa vyspelejším produktom. Čo sa stalo? Je všetka nenávisť naozaj kvôli chybám na začiatku marketingu nového DBMS? Alebo ľudia len používajú MongoDB na nesprávnom mieste?
Ak máte zrazu pocit, že obhajujem MongoDB, prečítajte si na konci článku.
Nový trend
V softvérovom priemysle sa pohybujem viac rokov, než je fér povedať, no stále som bol len súčasťou trendov, ktoré zasiahli náš priemysel. Bol som svedkom vzostupu 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain... zoznam je nekonečný. Každý rok prichádzajú nové trendy. Niektoré rýchlo miznú, zatiaľ čo iné zásadne menia spôsob vývoja softvéru.
Okolo každého nového trendu sa vytvára určité všeobecné vzrušenie: ľudia buď sami naskočia do člna, alebo uvidia hluk, ktorý vytvárajú ostatní – a idú za davom. Tento proces kodifikoval Gartner v r . Hoci je to diskutabilné, tento graf zhruba popisuje, čo sa deje s technológiami predtým, ako sa nakoniec stanú užitočnými na použitie.
Ale z času na čas príde (alebo príde druhý, ako v tomto prípade) nová inovácia, poháňaná iba jednou jej špecifickou implementáciou. V prípade NoSQL bol humbuk silne poháňaný príchodom a meteorickým vzostupom MongoDB. MongoDB tento trend nenaštartovalo: v skutočnosti veľké internetové spoločnosti začali mať problémy so spracovaním veľkého množstva dát, čo viedlo k návratu nerelačných databáz. Všeobecné hnutie začalo projektmi ako Bigtable od Google a Cassandra od Facebooku, no bol to MongoDB, ktorý sa stal najznámejšou a najdostupnejšou implementáciou databázy NoSQL, ku ktorej mala prístup väčšina vývojárov.
Poznámka: Možno si myslíte, že si mýlim databázy dokumentov so stĺpcovými databázami, skladmi kľúč/hodnota alebo ktorýmkoľvek z mnohých iných typov dátových skladov, ktoré spadajú pod všeobecnú definíciu NoSQL. A máš pravdu. V tom čase však vládol chaos. Každý je posadnutý NoSQL, stalo sa všetkým absolútne potrebné, aj keď mnohí nevideli rozdiely v rôznych technológiách. Pre mnohých sa stal MongoDB synonymom pre NoSQL.
A vývojári na to skočili. Myšlienka databázy bez schém, ktorá sa magicky mení, aby vyriešila akýkoľvek problém, bola celkom lákavá. Okolo roku 2014 sa zdalo, že všade, kde sa pred rokom používala relačná databáza ako MySQL, Postgres alebo SQL Server, sa nasadzovali databázy MongoDB. Na otázku prečo ste mohli dostať odpovede od banálneho „toto je rozsah webu“ až po premyslenejšie „moje údaje sú veľmi voľne štruktúrované a dobre zapadajú do databázy bez schémy“.
Je dôležité si uvedomiť, že MongoDB a databázy dokumentov vo všeobecnosti riešia množstvo problémov s tradičnými relačnými databázami:
- Prísna schéma: v prípade relačnej databázy, ak máte dynamicky generované údaje, ste nútení buď vytvoriť veľa náhodných „rôznych“ údajových stĺpcov, vložiť tam dátové guličky alebo použiť konfiguráciu ... to všetko má značné nevýhody.
- Náročnosť škálovania: Ak je toľko údajov, že sa nezmestia na jeden server, MongoDB ponúkol mechanizmy, ktoré im umožnia škálovať na viacerých počítačoch.
- Komplexné úpravy obvodov: žiadne migrácie! V relačnej databáze môže byť zmena štruktúry databázy obrovským problémom (najmä ak je údajov veľa). MongoDB dokázal tento proces výrazne zjednodušiť. A je to tak jednoduché, že stačí aktualizovať schému na cestách a ísť ďalej naozaj rýchlo.
- Napíšte výkon: Výkon MongoDB bol dobrý, najmä keď bol správne vyladený. Dokonca aj predpripravená konfigurácia MongoDB, za ktorú bol často kritizovaný, vykazovala niektoré pôsobivé výkonové čísla.
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 toho, aby ste pochopili kontext a nemali žiadne skúsenosti, potom by ste mohli nadobudnúť dojem, že MongoDB je skutočne revolučný DBMS. Jediným problémom bolo, že vyššie uvedené výhody prichádzali s množstvom upozornení, z ktorých niektoré sú uvedené nižšie.
Aby sme boli spravodliví, nikto v 10gen/MongoDB Inc. nepovie, že to nie je pravda, sú to len kompromisy.
- Strata transakciíOdpoveď: Transakcie sú základnou črtou mnohých relačných databáz (nie všetkých, ale väčšiny). Transakčné znamená, že môžete vykonávať viaceré operácie atomicky a môžete zabezpečiť, aby údaje zostali konzistentné. Samozrejme, s databázou NoSQL môže byť transakcia v rámci jedného dokumentu alebo môžete použiť dvojfázové príkazy na získanie transakčnej sémantiky. Túto funkciu však budete musieť implementovať sami... čo môže byť náročná a časovo náročná úloha. Často si problém neuvedomíte, kým neuvidíte, že sa údaje v databáze dostanú do neplatných stavov, pretože nie je možné zaručiť atomicitu operácií. Poznámka: Mnohí mi povedali, že transakcie boli zavedené v MongoDB 4.0 minulý rok, ale s určitými obmedzeniami. Záver z článku zostáva rovnaký: posúďte, ako technológia vyhovuje vašim potrebám.
- Strata vzťahovej integrity (cudzie kľúče): ak vaše údaje majú vzťahy, budete ich musieť použiť v aplikácii. Mať databázu, ktorá rešpektuje tieto vzťahy, uberie aplikácii, a teda aj vašim programátorom, veľa práce.
- Neschopnosť použiť dátovú štruktúru: Prísne schémy môžu byť niekedy veľkým problémom, ale sú tiež účinným mechanizmom na dobré štruktúrovanie údajov, ak sa používajú rozumne. Databázy dokumentov, ako je MongoDB, poskytujú neuveriteľnú flexibilitu schém, ale táto flexibilita odstraňuje zodpovednosť za udržiavanie údajov v čistote. Ak sa o ne nestaráte, skončíte tak, že vo svojej aplikácii napíšete veľa kódu, aby ste zohľadnili údaje, ktoré nie sú uložené vo forme, ktorú očakávate. Ako sa často hovorí v našej spoločnosti Simple Thread... aplikácia bude jedného dňa prepísaná, ale dáta budú žiť navždy. Poznámka: MongoDB podporuje overenie schémy, čo je užitočné, ale neposkytuje rovnaké záruky ako relačná databáza. Po prvé, pridanie alebo zmena overenia schémy neovplyvní existujúce údaje v kolekcii. Musíte sa uistiť, že aktualizujete údaje podľa novej schémy. Rozhodnite sa sami, či to pre vaše potreby stačí.
- Vlastný dopytovací jazyk / strata ekosystému nástrojov: Príchod SQL bol absolútnou revolúciou a odvtedy sa nič nezmenilo. Je to neuveriteľne silný jazyk, ale aj dosť zložitý. Potrebu konštruovať databázové dotazy v novom jazyku, ktorý pozostáva z JSON fragmentov, považujú ľudia, ktorí majú skúsenosti s SQL, za veľký krok späť. Existuje celý rad nástrojov, ktoré interagujú s databázami SQL, od IDE až po nástroje na vytváranie prehľadov. Presun do databázy, ktorá nepodporuje SQL, znamená, že nemôžete použiť väčšinu týchto nástrojov, alebo ak ich chcete použiť, musíte údaje skonvertovať na SQL, čo môže byť zložitejšie, než si myslíte.
Mnoho vývojárov, ktorí sa obrátili na MongoDB, v skutočnosti nerozumelo kompromisom a často sa vrhli po hlave do nastavenia ako svojho primárneho úložiska údajov. Potom bolo často neuveriteľne ťažké vrátiť sa späť.
Čo sa dalo urobiť inak?
Nie všetci skočili hlavou a vrazili dnu. Ale pomerne veľa projektov nainštalovalo základňu MongoDB tam, kde sa jednoducho nezmestila – a budú s ňou musieť žiť ešte mnoho rokov. Ak by tieto organizácie venovali nejaký čas metodickému zváženiu svojich technologických rozhodnutí, mnohé by sa rozhodli inak.
Ako si vybrať správnu technológiu? Prebehlo niekoľko pokusov o vytvorenie systematického rámca pre hodnotenie technológií, ako napr и , ale zdá sa mi, že je to zbytočná zložitosť.
Mnohé technológie možno inteligentne oceniť položením dvoch základných otázok. Problém spočíva v hľadaní ľudí, ktorí na ne vedia zodpovedne odpovedať, nájsť si čas na nájdenie odpovedí a bez zaujatosti.
Ak sa nestretnete s nejakým problémom, nepotrebujete nový nástroj. Bodka.
Otázka 1: Aké problémy sa snažím vyriešiť?
Ak sa nestretnete s nejakým problémom, nepotrebujete nový nástroj. Bodka. Netreba hľadať riešenie a potom prísť s problémom. Pokiaľ sa nestretnete s problémom, ktorý nová technológia nerieši výrazne lepšie ako vaša existujúca technológia, potom tu nie je o čom diskutovať. Ak uvažujete o použití tejto technológie, pretože ste videli, ako ju používajú iní, zamyslite sa nad problémami, ktoré majú, a opýtajte sa, či máte tieto problémy aj vy. Je ľahké prijať technológiu, pretože ju používajú iní, problémom je vedieť, či čelíte rovnakým problémom.
Otázka 2: Čo mi chýba?
Toto je určite ťažšia otázka, pretože sa musíte dobre prehrabať a pochopiť starú aj novú technológiu. Niekedy nemôžete skutočne pochopiť nový, kým s ním niečo nevybudujete alebo nemáte kolegu s touto skúsenosťou.
Ak nemáte ani jedno, potom má zmysel uvažovať o minimálnej možnej investícii na určenie hodnoty tohto nástroja. A ak investujete, aké ťažké bude zvrátiť rozhodnutie?
Ľudia vždy všetko pokazia
Pri snahe odpovedať na tieto otázky čo najnestrannejšie, pamätajte na jednu vec: musíte bojovať s ľudskou prirodzenosťou. Existuje množstvo kognitívnych predsudkov, ktoré je potrebné prekonať, aby bolo možné efektívne vyhodnotiť technológiu. Tu je len niekoľko:
- Každý o ňom vie, no bojovať s ním je stále ťažké. Len sa uistite, že technológia skutočne vyhovuje vašim skutočným potrebám.
- Mnoho vývojárov má tendenciu podceňovať technológie, s ktorými už dlho pracujú, a preceňovať výhody novej technológie. Nielen programátori, všetci podliehajú tejto kognitívnej zaujatosti.
- Máme tendenciu vidieť, čo je, a strácať zo zreteľa to, čo nie je. To môže viesť k chaosu v kombinácii s efektom novosti, pretože nielenže vo svojej podstate preceňujete novú technológiu, ale ignorujete aj jej nedostatky..
Objektívne hodnotenie nie je jednoduché, ale pochopenie základných kognitívnych predsudkov vám pomôže robiť racionálnejšie rozhodnutia.
Zhrnutie
Keď sa objaví inovácia, je potrebné veľmi opatrne odpovedať na dve otázky:
- Rieši tento nástroj skutočný problém?
- Sme dobrí v chápaní kompromisov?
Ak neviete s istotou odpovedať na tieto dve otázky, urobte pár krokov späť a zamyslite sa.
Bola teda la MongoDB vo všeobecnosti správnou voľbou? Samozrejme áno; ako pri väčšine strojárskych technológií závisí od mnohých faktorov. Medzi tými, ktorí odpovedali na tieto dve otázky, mnohí profitovali z MongoDB a pokračujú v tom. Pre tých z vás, ktorí nie, dúfam, že ste sa naučili cennú a nie príliš bolestivú lekciu o prechode cez cyklus humbuku.
Vylúčenie zodpovednosti
Chcem objasniť, že MongoDB ani nemilujem, ani neznášam. Jednoducho sme nemali také problémy, na ktoré je MongoDB najvhodnejší. Poznám 10gen/MongoDB Inc. sa spočiatku správal veľmi odvážne, nastavil neisté predvolené nastavenia a všade propagoval MongoDB (najmä na hackathonoch) ako komplexné riešenie pre prácu s akýmikoľvek údajmi. Asi to bolo zlé rozhodnutie. Potvrdzuje to však tu opísaný prístup: tieto problémy sa dajú veľmi rýchlo odhaliť aj pri povrchnom posúdení technológie.
Zdroj: hab.com