Nedávno jsem zjistil, že (říká se, že kvůli změnám v licenci). To mě přimělo přemýšlet, že v posledních několika letech jsem viděl spoustu článků o tom, jak je MongoDB hrozná a že ji nikdo nikdy neměl používat. Ale v průběhu času se MongoDB stala mnohem vyspělejším produktem. Co se tedy stalo? Opravdu je celý ten odpor důsledkem chyb na začátku marketingu nové databáze? Nebo lidé jen používají MongoDB na nesprávných místech?
Pokud byste měli pocit, že bráním MongoDB, prosím, přečtěte si na konci článku.
Nový trend
V softwarovém průmyslu pracuji déle, než by bylo slušné říkat, ale i tak mi připadla jen malá část trendů, které zasáhly náš obor. Byl jsem svědkem vzestupu 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchainu… seznam je nekonečný. Každý rok se objevují nové trendy. Některé rychle vyhasnou, zatímco jiné zásadně změní způsoby vývoje softwaru.
Kolem každého nového trendu se vytváří určité všeobecné vzrušení: lidé buď sami skáčou na loď, nebo vidí hluk, který vytvářejí ostatní – a jdou za davem. Tento proces kodifikovala společnost Gartner v . I když je sporný, tento graf přibližně popisuje, co se děje s technologiemi, než se nakonec stanou užitečnými pro použití.
Ale čas od času se objeví (nebo nastává druhý příchod, jako v tomto případě) nová inovace, motivovaná pouze jednou konkrétní její realizací. V případě NoSQL byl hyp silně podmíněný vznikem a rychlým vzestupem MongoDB. Ne MongoDB zahájila tento trend: ve velkých internetových společnostech začaly problémy se zpracováním velkých objemů dat, které vedly k návratu nerelačních databází. Hlavní hnutí začalo s projekty, jako je Bigtable od Googlu a Cassandra od Facebooku, ale právě MongoDB se stala nejznámějším a nejdostupnějším provedením databáze NoSQL, k níž měli přístup většina vývojářů.
Poznámka: můžete si myslet, že míchám dokumentové databáze s sloupcovými databázemi, úložišti klíč/hodnota nebo jakýmikoli z mnoha dalších typů datových úložišť, které spadají pod obecnou definici NoSQL. A máte pravdu. Ale v té době panoval chaos. Všichni byli blázni do NoSQL, všem se to stalo absolutně je třeba, i když mnozí neviděli rozdíly mezi různými technologiemi. Pro mnohé se MongoDB stala synonymem NoSQL.
A vývojáři se na ni vrhli. Myšlenka databáze bez schématu, která se kouzlem škáluje pro řešení jakéhokoli problému, byla velmi lákavá. Kolem roku 2014 se zdálo, že všude tam, kde se ještě před rokem používala relační databáze, jako je MySQL, Postgres nebo SQL Server, se začaly implementovat databáze MongoDB. Na otázku proč, jste mohli dostat odpověď od banálního „to je měřítko webu“ po promyšlenější „moje data jsou velmi málo strukturovaná a dobře se hodí do databáze bez schématu“.
Je důležité si uvědomit, že MongoDB a dokumentové databáze obecně řeší řadu problémů s tradičními relačními databázemi:
- Přísné schéma: s relační databází, pokud máte dynamicky utvářená data, musíte buď vytvořit spoustu náhodných „různých“ sloupců dat, nacpat tam blob data nebo použít konfiguraci … všechno to má významné nedostatky.
- Obtížnost škálování: pokud je dat tolik, že se nevejdou na jeden server, MongoDB nabízela mechanismy, které umožnily škálování na více strojích.
- Složitost úprav schématu: žádné migrace! Ve relační databázi může být změna struktury databáze obrovským problémem (zejména když je dat velmi mnoho). MongoDB dokázala tento proces výrazně zjednodušit. A udělala ho tak snadným, že můžete jednoduše aktualizovat schéma za chodu a velmi rychle pokračovat dál.
- Výkon zápisu: výkon MongoDB byl dobrý, zvláště při správném nastavení. I konfigurace MongoDB z krabice, za kterou byla často kritizována, vykazovala některé působivé výkonnostní ukazatele.
Všechna rizika na vás
Potenciální výhody MongoDB byly obrovské, zejména pro určité třídy problémů. Pokud si přečtete výše uvedený seznam bez pochopení kontextu a bez zkušeností, může se zdát, že MongoDB je opravdu revoluční DBMS. Jediný problém spočíval v tom, že výše uvedené výhody byly provázeny řadou výjimek, z nichž některé jsou uvedeny níže.
Abychom byli spravedliví, nikdo v 10gen/MongoDB Inc. neřekne, že to, co následně uvedeme, je nepravda; jsou to prostě kompromisy.
- Ztráta transakcí: transakce jsou základní funkcí mnoha relačních databází (ne všech, ale většiny). Transakční vlastnost znamená, že můžete provádět několik operací atomicky a můžete zaručit, že data zůstanou konzistentní. Samozřejmě, v NoSQL databázi může být transakčnost v rámci jednoho dokumentu, nebo můžete použít dvoufázové potvrzení k získání transakčního významu. Ale budete si muset tuto funkčnost implementovat sami… což může být složitý a časově náročný úkol. Často si nepřipouštíte problémy, dokud neuvidíte, že data v databázi se dostávají do neplatných stavů, protože není možné zaručit atomaritu operací. Poznámka: mnozí mi řekli, že v loňském roce v MongoDB 4.0 byly přidány transakce, ale s řadou omezení. Závěr článku zůstává stejný: zvažte, jak technologie odpovídá vašim potřebám.
- Ztráta relační integrity (cizí klíče): pokud máte v údajích vztahy, budete muset tyto vztahy implementovat v aplikaci. Mít databázi, která tyto vztahy dodržuje, uvolní značnou část práce v aplikaci a tím pádem i vašim programátorům.
- Nemožnost použít datovou strukturu: přísné schémy mohou někdy představovat velký problém, ale mohou být také mocným nástrojem pro dobré strukturování dat, pokud jsou správně použity. Dokumentové databáze, jako je MongoDB, poskytují neuvěřitelnou flexibilitu schématu, ale tato flexibilita přenáší odpovědnost za udržování dat v pořádku. Pokud se o to nepostaráte, nakonec budete muset napsat v aplikaci hodně kódu na zohlednění dat, která jsou uchovávána v jiném tvaru, než jaký očekáváte. Jak často říkáme v naší společnosti Simple Thread… aplikaci někdy přepíšou, ale data budou žít navždy. Poznámka: MongoDB podporuje schématickou kontrolu; ta je užitečná, ale neposkytuje stejné záruky jako relační databáze. Za prvé, přidání nebo změna schématické kontroly nemá vliv na existující data v kolekci. Musíte se ujistit, že aktualizujete data v souladu s novým schématem. Rozhodněte se sami, zda je to dostatečné pro vaše potřeby.
- Vlastní dotazovací jazyk / ztráta ekosystému nástrojů: vznik SQL byl absolutní revolucí a od té doby se nic nezměnilo. Je to neuvěřitelně silný jazyk, ale také poměrně složitý. Potřeba konstruovat dotazy na databázích v novém jazyce složeném z fragmentů JSON je pro lidi se zkušenostmi se SQL považována za velký krok zpět. Existuje celá univerzita nástrojů, které interagují s SQL databázemi: od IDE po reportovací nástroje. Přechod na databázi, která SQL nepodporuje, znamená, že nemůžete používat většinu těchto nástrojů nebo musíte data převést na SQL, abyste je mohli používat, což se může ukázat jako složitější, než si myslíte.
Mnoho vývojářů, kteří přešli na MongoDB, si nebylo plně vědomo kompromisů a často skákali po hlavě, aby ji nastavili jako hlavní úložiště dat. Po tom bylo často neuvěřitelně obtížné se vrátit zpět.
Co by bylo možné udělat jinak?
Ne všichni skákali po hlavě a narazili na dno. Ale mnohé projekty instalovaly MongoDB tam, kde prostě nevyhovovala - a budou s ní muset žít ještě mnoho let. Kdyby si tyto organizace daly čas a systematicky promyslely volbu technologií, mohly by se mnohé rozhodnout jinak.
Jak vybrat vhodnou technologii? Bylo několik pokusů vytvořit systematický rámec pro hodnocení technologií, jako jsou a , ale zdá se mi, že je to zbytečná komplikace.
Mnohé technologie lze rozumně hodnotit, když si položíte pouze dvě základní otázky. Problém spočívá v nalezení lidí, kteří na ně mohou odpovědně odpovědět, strávit čas hledáním odpovědí a bez předsudků.
Pokud se s nějakým problémem nesetkáváte, nepotřebujete nový nástroj. Tečka.
Otázka 1: Jaké problémy se snažím vyřešit?
Pokud se nesetkáváte s nějakým problémem, nepotřebujete nový nástroj. Tečka. Není třeba hledat řešení a poté vymýšlet problém. Pokud se nesetkáváte s problémem, který nová technologie neřeší výrazně lépe než vaše stávající technologie, není o čem diskutovat. Pokud zvažujete použití této technologie, protože jste viděli, jak ji používají ostatní, zamyslete se nad tím, s jakými problémy se potýkají, a zeptejte se, zda máte stejné problémy. Je snadné přijmout technologii, protože ji používají jiní, obtížné je pochopit, zda se potýkáte se stejnými problémy.
Otázka 2: O co přicházím?
To je určitě obtížnější otázka, protože budete muset proniknout a dobře porozumět jak staré, tak nové technologii. Někdy nelze skutečně pochopit novou technologii, dokud s ní něco nepostavíte nebo nemáte zaměstnance, který má takové zkušenosti.
Pokud nemáte ani jedno, má smysl uvažovat o minimálních investicích k určení hodnoty tohoto nástroje. A pokud uděláte investice, jak obtížné bude zrušit rozhodnutí?
Lidé to vždy zkazí
Při snaze odpovědět na tyto otázky co nejobjektivněji si pamatujte jednu věc: budete se muset vypořádat s lidskou přirozeností. Existuje řada kognitivních zkreslení, která je třeba překonat, aby bylo možné technologii efektivně vyhodnotit. Zde je jen několik:
- — všichni o něm vědí, ale je s ním stále těžké bojovat. Jen se ujistěte, že technologie skutečně odpovídá vašim skutečným potřebám.
- — mnozí vývojáři mají tendenci podceňovat technologie, se kterými pracovali dlouho, a nadhodnocovat výhody nové technologie. Nejen programátoři, všichni jsou pod tímto kognitivním zkreslením.
- — máme tendenci vidět to, co existuje, a přehlížet to, co chybí. To může vést k chaosu v kombinaci s efektem novosti, protože nejenže v podstatě nadhodnocujete novou technologii, ale také ignorujete její nedostatky..
Objektivní hodnocení není snadné, ale porozumění základním kognitivním zkreslením pomůže přijímat racionálnější rozhodnutí.
Shrnutí
Když se objeví nějaká inovace, je třeba s velkou opatrností odpovědět na dvě otázky:
- Řeší tento nástroj skutečný problém?
- Rozumíme dobře kompromisům?
Pokud na tyto dvě otázky nemůžete s jistotou odpovědět, udělejte několik kroků zpět a zamyslete se.
Byla MongoDB vůbec správnou volbou? Samozřejmě, že ano; jako u většiny inženýrských technologií to závisí na mnoha faktorech. Mnozí z těch, kdo odpověděli na tyto dvě otázky, získali z MongoDB výhody a pokračují v tom. Ti, kdo ne, doufám, že dostali cennou a příliš bolestnou lekci o pohybu v hype cyklu.
Vyloučení odpovědnosti
Chci objasnit, že necítím ani lásku, ani nenávist k MongoDB. Prostě jsme neměli takové problémy, pro jejichž řešení by byla MongoDB nejvhodnější. Vím, že 10gen/MongoDB Inc. asi působilo velmi odvážně, když nastavilo nebezpečné výchozí hodnoty a propagovalo MongoDB všude (zejména na hackathonech) jako univerzální řešení pro práci s jakýmiikoli daty. Pravděpodobně to bylo špatné rozhodnutí. Ale potvrzuje to zde popsaný přístup: tyto problémy bylo možné odhalit velmi rychle i při povrchním hodnocení technologie.
Zdroj: habr.com
