Nedávno jsem to zjistil (říkají kvůli změnám licence). To mě přivedlo k zamyšlení, protože za posledních pár let jsem viděl spoustu článků o tom, jak hrozný MongoDB je a jak by ho nikdo nikdy neměl používat. Ale během této doby se MongoDB stal mnohem vyspělejším produktem. Co se stalo? Je veškerá nenávist skutečně způsobena chybami v raném marketingu nového DBMS? Nebo lidé jen používají MongoDB na nesprávných místech?
Pokud máte pocit, že MongoDB bráním, přečtěte si to na konci článku.
Nový trend
Pracuji v softwarovém průmyslu více let, než mohu říci, ale stále jsem byl vystaven pouze malé části trendů, které zasáhly naše odvětví. Byl jsem svědkem vzestupu 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... seznam je nekonečný. Každý rok se objevují nové trendy. Některé rychle mizí, zatímco jiné zásadně mění způsob vývoje softwaru.
Každý nový trend vyvolává všeobecné vzrušení: lidé buď skočí na palubu, nebo vidí hluk generovaný ostatními a následují dav. Tento proces je kodifikován společností Gartner v . Ačkoli je tato časová osa kontroverzní, zhruba popisuje, co se stane s technologiemi, než se nakonec stanou užitečnými.
Ale čas od času se objeví nová inovace (nebo přijde druhá, jako v tomto případě) poháněná pouze jednou konkrétní implementací. V případě NoSQL byl humbuk silně ovlivněn vznikem a meteorickým vzestupem MongoDB. MongoDB tento trend nenastartoval: ve skutečnosti velké internetové společnosti začaly mít problémy se zpracováním velkého množství dat, což vedlo k návratu nerelačních databází. Celkový pohyb začal projekty jako Bigtable od Googlu a Cassandra od Facebooku, ale nejznámější a nejdostupnější implementací databáze NoSQL, ke které měla přístup většina vývojářů, se stala MongoDB.
Poznámka: Můžete si myslet, že si pletu databáze dokumentů se sloupcovými databázemi, úložišti klíč/hodnota nebo některým z mnoha jiných typů úložišť dat, které spadají pod obecnou definici NoSQL. A máš pravdu. V té době však vládl chaos. Každý je posedlý NoSQL, stal se každým absolutně nutné, i když mnozí neviděli rozdíly v různých technologiích. Pro mnohé se stal MongoDB synonymní s NoSQL.
A vývojáři se na to vrhli. Myšlenka databáze bez schémat, která se magicky škáluje, aby vyřešila jakýkoli problém, byla docela lákavá. Kolem roku 2014 se zdálo, že všude tam, kde se před rokem používala relační databáze jako MySQL, Postgres nebo SQL Server, se začaly nasazovat databáze MongoDB. Na otázku proč jste mohli dostat odpověď od banálního „toto je rozsah webu“ až po promyšlenější „moje data jsou velmi volně strukturovaná a dobře zapadají do databáze bez schématu“.
Je důležité si uvědomit, že MongoDB a databáze dokumentů obecně řeší řadu problémů s tradičními relačními databázemi:
- Přísné schéma: Pokud máte u relační databáze dynamicky generovaná data, jste nuceni buď vytvořit hromadu náhodných „různých“ sloupců dat, strčit tam bloby dat nebo použít konfiguraci. ...to vše má značné nevýhody.
- Škálování obtížnosti: Pokud existuje tolik dat, že se nevejdou na jeden server, MongoDB nabídl mechanismy, které jim umožní škálovat na více počítačích.
- Komplexní úpravy obvodů: žádné migrace! V relační databázi může být změna struktury databáze obrovský problém (zvláště když je tam hodně dat). MongoDB dokázal tento proces značně zjednodušit. A bylo to tak snadné, že můžete okruh jednoduše aktualizovat za pochodu a velmi rychle pokračovat.
- Výkon nahrávání: Výkon MongoDB byl dobrý, zvláště když byl správně nakonfigurován. Dokonce i přednastavená konfigurace MongoDB, za kterou byl často kritizován, vykazovala některá působivá výkonová čísla.
Všechna rizika jsou 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ůžete nabýt dojmu, že MongoDB je skutečně revoluční DBMS. Jediným problémem bylo, že výše uvedené výhody přicházely s řadou upozornění, z nichž některé jsou uvedeny níže.
Abychom byli spravedliví, nikdo z 10gen/MongoDB Inc. neřekne, že následující není pravda, jsou to jen kompromisy.
- Ztracené transakce: Transakce jsou základním prvkem mnoha relačních databází (ne všech, ale většiny). Transakční znamená, že můžete atomicky provádět více operací a můžete zajistit, že data zůstanou konzistentní. Samozřejmě, že u databáze NoSQL může být transakčnost v rámci jednoho dokumentu, nebo můžete použít dvoufázové potvrzení pro získání transakční sémantiky. Tuto funkci však budete muset implementovat sami... což může být obtížný a časově náročný úkol. Často si neuvědomíte, že je problém, dokud neuvidíte, že data v databázi skončí v neplatných stavech, protože nelze zaručit atomicitu operací. Poznámka: Mnoho lidí mi řeklo, že MongoDB 4.0 zavedlo transakce minulý rok, ale s určitými omezeními. Závěr z článku zůstává stejný: zhodnoťte, jak dobře technologie vyhovuje vašim potřebám.
- Ztráta vztahové integrity (cizí klíče): Pokud vaše data mají vztahy, budete je muset použít v aplikaci. Mít databázi, která tyto vztahy respektuje, ubere aplikaci a tedy i vašim programátorům spoustu práce.
- Nedostatek schopnosti aplikovat datovou strukturu: Přísná schémata mohou být někdy velkým problémem, ale jsou také mocným mechanismem pro dobré strukturování dat, pokud jsou používána moudře. Databáze dokumentů, jako je MongoDB, poskytují neuvěřitelnou flexibilitu schémat, ale tato flexibilita odstraňuje odpovědnost za udržování dat v čistotě. Pokud se o ně nebudete starat, skončíte tím, že ve své aplikaci napíšete spoustu kódu, který zohlední data, která nejsou uložena v očekávané podobě. Jak často říkáme v naší společnosti Simple Thread... aplikace bude jednou přepsána, ale data budou žít navždy. Poznámka: MongoDB podporuje kontrolu schématu: je to užitečné, ale neposkytuje stejné záruky jako v relační databázi. Za prvé, přidání nebo změna kontroly schématu neovlivní existující data v kolekci. Je na vás, abyste zajistili aktualizaci dat podle nového schématu. Rozhodněte se sami, zda to pro vaše potřeby stačí.
- Nativní dotazovací jazyk / ztráta ekosystému nástrojů: Nástup 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 databázové dotazy v novém jazyce sestávajícím z fragmentů JSON je lidmi, kteří mají zkušenosti s prací s SQL, považována za velký krok zpět. Existuje celá řada nástrojů, které spolupracují s databázemi SQL, od IDE po nástroje pro vytváření sestav. Přechod do databáze, která nepodporuje SQL, znamená, že nemůžete používat většinu těchto nástrojů nebo musíte data přeložit do SQL, abyste je mohli používat, což může být obtížnější, než si myslíte.
Mnoho vývojářů, kteří se obrátili na MongoDB, ve skutečnosti nerozumělo kompromisům a často se vrhli po hlavě do jeho instalace jako svého primárního úložiště dat. Poté bylo často neuvěřitelně obtížné se vrátit.
Co se dalo udělat jinak?
Ne všichni skočili po hlavě a narazili na dno. Mnoho projektů ale nainstalovalo MongoDB na místa, kam se prostě nevešlo – a budou s ním muset žít ještě mnoho let. Pokud by tyto organizace strávily nějaký čas a metodicky promyslely své technologické volby, mnohé by se rozhodly jinak.
Jak vybrat správnou technologii? Proběhlo několik pokusů o vytvoření systematického rámce pro hodnocení technologií, jako např и , ale zdá se mi, že je to zbytečná složitost.
Mnoho technologií lze inteligentně posoudit položením pouhých dvou základních otázek. Problém je najít lidi, kteří na ně dokážou zodpovědně odpovědět, najít si čas na odpovědi a nezaujatě.
Pokud se nesetkáte s žádným problémem, nepotřebujete nový nástroj. Tečka.
Otázka 1: Jaké problémy se snažím vyřešit?
Pokud se nesetkáte s žádným problémem, nepotřebujete nový nástroj. Tečka. Není potřeba hledat řešení a pak vymýšlet problém. Pokud jste nenarazili na problém, který nová technologie řeší výrazně lépe než vaše stávající technologie, není zde o čem diskutovat. Pokud zvažujete použití této technologie, protože jste ji viděli používat jiní, zvažte, jakým problémům čelí, a zeptejte se, zda tyto problémy máte. Je snadné přijmout technologii, protože ji používají ostatní, výzvou je pochopit, zda čelíte stejným problémům.
Otázka 2: Co mi chybí?
To je rozhodně složitější otázka, protože se budete muset ponořit a dobře rozumět staré i nové technologii. Někdy nemůžete skutečně pochopit nový, dokud s ním něco nevybudujete nebo nemáte někoho, kdo s tím má zkušenosti.
Pokud nemáte ani jedno ani druhé, pak má smysl přemýšlet o minimální možné investici pro určení hodnoty tohoto instrumentu. A jakmile investujete, jak těžké bude rozhodnutí zvrátit?
Lidé vždycky všechno zkazí
Až se budete snažit na tyto otázky odpovědět co možná nestranně, pamatujte na jednu věc: budete muset bojovat s lidskou přirozeností. Existuje řada kognitivních předsudků, které je třeba překonat, aby bylo možné efektivně vyhodnotit technologii. Zde je jen několik:
- - každý o něm ví, ale je stále těžké s ním bojovat. Jen se ujistěte, že technologie skutečně odpovídá vašim skutečným potřebám.
- — Mnoho vývojářů má tendenci podceňovat technologie, se kterými pracovali dlouhou dobu, a přeceňovat přínosy nových technologií. Nejsou to jen programátoři, každý je náchylný k této kognitivní zaujatosti.
- - Máme tendenci vidět, co tam je, a ztrácet ze zřetele to, co chybí. To může vést k chaosu v kombinaci s efektem novosti, protože nejenže ze své podstaty nadhodnocujete novou technologii, ale také ignorujete její nedostatky..
Objektivní hodnocení není snadné, ale pochopení základních kognitivních předsudků vám pomůže učinit racionálnější rozhodnutí.
Shrnutí
Kdykoli se objeví inovace, je třeba pečlivě zodpovědět dvě otázky:
- Řeší tento nástroj skutečný problém?
- Chápeme dobře kompromisy?
Pokud na tyto dvě otázky nedokážete s jistotou odpovědět, udělejte pár kroků zpět a zamyslete se.
Byl tedy MongoDB vůbec správnou volbou? Samozřejmě ano; Stejně jako u většiny strojírenských technologií to závisí na mnoha faktorech. Mezi těmi, kteří odpověděli na tyto dvě otázky, mnozí těžili z MongoDB a pokračují v tom. Pro ty, kteří to neudělali, doufám, že jste se naučili cennou a ne příliš bolestivou lekci o průchodu cyklem humbuku.
Zřeknutí se odpovědnosti
Chci objasnit, že s MongoDB nemám ani milostný, ani nenávistný vztah. Jen jsme neměli takové problémy, pro jejichž řešení je MongoDB nejvhodnější. Vím, že 10gen/MongoDB Inc. byl zpočátku velmi odvážný, nastavoval nezabezpečené výchozí hodnoty a všude propagoval MongoDB (zejména na hackathonech) jako univerzální řešení pro práci s jakýmikoli daty. Asi to bylo špatné rozhodnutí. Potvrzuje to však zde popsaný přístup: tyto problémy lze velmi rychle odhalit i při povrchním posouzení technologie.
Zdroj: www.habr.com