Nemrég tudtam meg A Red Hat eltávolítja a MongoDB támogatást a Satellite-ről (mondják a licencmódosítások miatt). Ez elgondolkodtatott, mert az elmúlt néhány évben rengeteg cikket láttam arról, hogy a MongoDB milyen szörnyű, és hogy senkinek sem szabad használnia. De ez idő alatt a MongoDB sokkal érettebb termékké vált. Mi történt? Valóban az összes gyűlölet az új DBMS korai marketingjének hibáinak köszönhető? Vagy az emberek csak rossz helyen használják a MongoDB-t?

Ha úgy érzi, hogy megvédem a MongoDB-t, kérjük, olvassa el felelősségkizárás a cikk végén.

Új trend

Több éve dolgozom a szoftveriparban, mint amennyit elmondhatok, de még mindig csak egy kis részét ismerhettem meg az iparágunkat sújtó trendeknek. Tanúja voltam a 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain térnyerésének... a lista végtelen. Minden évben új trendek jelennek meg. Egyesek gyorsan elhalványulnak, míg mások alapvetően megváltoztatják a szoftverfejlesztés módját.

Minden új trend általános izgalmat kelt: az emberek vagy felugranak a fedélzetre, vagy látják a mások által keltett zajt, és követik a tömeget. Ezt a folyamatot a Gartner kódolta hype ciklus. Bár ellentmondásos, ez az idővonal nagyjából leírja, mi történik a technológiákkal, mielőtt azok végül hasznossá válnának.

De időről időre megjelenik egy-egy új innováció (vagy van egy második eljövetele, mint ebben az esetben), amit csak egy konkrét megvalósítás hajt. A NoSQL esetében a felhajtást nagymértékben a MongoDB megjelenése és meteorikus térnyerése okozta. A MongoDB nem indította el ezt a trendet: valójában a nagy internetes cégeknek gondjai voltak a nagy mennyiségű adat feldolgozásával, ami a nem relációs adatbázisok visszatéréséhez vezetett. Az általános mozgalom olyan projektekkel indult, mint a Google Bigtable és a Facebook Cassandra, de a MongoDB lett a legismertebb és legelérhetőbb NoSQL adatbázis-megvalósítás, amelyhez a legtöbb fejlesztő hozzáfért.

Megjegyzés: Azt gondolhatja, hogy összekeverem a dokumentumadatbázisokat az oszlopos adatbázisokkal, a kulcs-/értéktárolókkal vagy a számos más típusú adattárral, amelyek az általános NoSQL-definíció alá tartoznak. És igazad van. De akkoriban káosz uralkodott. Mindenki a NoSQL megszállottja, mindenki lett belőle teljesen szükséges, bár sokan nem látták a különbségeket a különböző technológiákban. Sokak számára a MongoDB lett szinonimája NoSQL.

A fejlesztők pedig lecsaptak rá. A séma nélküli adatbázis ötlete, amely varázslatosan méretezhető bármilyen probléma megoldására, meglehetősen csábító volt. 2014 körül úgy tűnt, hogy mindenhol, ahol egy évvel ezelőtt relációs adatbázisokat használtak, mint például a MySQL, a Postgres vagy az SQL Server, megkezdték a MongoDB adatbázisok telepítését. Arra a kérdésre, hogy miért, a banális „ez a web léptéke”-től az átgondoltabb „adataim nagyon laza szerkezetűek és jól illeszkednek egy séma nélküli adatbázisba” választ kaphat.

Fontos megjegyezni, hogy a MongoDB és általában a dokumentumadatbázisok számos problémát megoldanak a hagyományos relációs adatbázisokkal:

• Szigorú séma: Ha relációs adatbázissal rendelkezik dinamikusan generált adatokkal, akkor vagy véletlenszerű "vegyes" adatoszlopokat kell létrehoznia, adatfoltokat kell beraknia, vagy konfigurációt kell használnia. EAV...mindennek jelentős hátrányai vannak.
• Méretezési nehézség: Ha annyi adat van, hogy nem fér el egy szerveren, a MongoDB olyan mechanizmusokat kínált, amelyek lehetővé teszik több gépen való skálázását.
• Komplex áramköri módosítások: nincs migráció! Egy relációs adatbázisban óriási probléma lehet az adatbázis szerkezetének megváltoztatása (főleg, ha sok az adat). A MongoDB nagymértékben leegyszerűsítette a folyamatot. És ez annyira egyszerűvé tette, hogy menet közben frissítheti az áramkört, és nagyon gyorsan továbbléphet.
• Felvételi teljesítmény: A MongoDB teljesítménye jó volt, különösen, ha megfelelően konfigurálták. Még a MongoDB gyári konfigurációja is, amely miatt gyakran kritizálták, lenyűgöző teljesítményt mutatott.

Minden kockázat rajtad áll

A MongoDB potenciális előnyei óriásiak voltak, különösen bizonyos problémaosztályok esetében. Ha elolvassa a fenti listát anélkül, hogy megértené a szövegkörnyezetet és tapasztalat nélkül, akkor az a benyomása támadhat, hogy a MongoDB valóban egy forradalmi DBMS. Az egyetlen probléma az volt, hogy a fent felsorolt ​​​​előnyök számos figyelmeztetéssel jártak, amelyek közül néhányat az alábbiakban sorolunk fel.

Az igazság kedvéért a 10gen/MongoDB Inc.-nél senki sem. nem fogja azt mondani, hogy az alábbiak nem igazak, ezek csak kompromisszumok.

• Elveszett tranzakciók: A tranzakciók sok relációs adatbázis (nem mindegyik, de a legtöbb) alapvető jellemzői. A tranzakció azt jelenti, hogy több műveletet is végrehajthat atomosan, és biztosíthatja, hogy az adatok konzisztensek maradjanak. Természetesen egy NoSQL-adatbázis esetén a tranzakciós kapcsolat lehet egyetlen dokumentumon belül, vagy kétfázisú véglegesítésekkel is megkaphatja a tranzakciós szemantikát. De ezt a funkciót magának kell megvalósítania... ami nehéz és időigényes feladat lehet. Gyakran nem veszi észre, hogy probléma van, amíg nem látja, hogy az adatbázisban lévő adatok érvénytelen állapotba kerülnek, mivel a műveletek atomitása nem garantálható. Megjegyzés: Sokan mondták nekem, hogy a MongoDB 4.0 tavaly bevezette a tranzakciókat, de bizonyos korlátozásokkal. A cikk lényege változatlan: értékelje, hogy a technológia mennyire felel meg az Ön igényeinek.
• A relációs integritás elvesztése (idegen kulcsok): Ha az adatok között vannak kapcsolatok, akkor ezeket alkalmaznia kell az alkalmazásban. Ha van egy adatbázis, amely tiszteletben tartja ezeket a kapcsolatokat, az sok munkát levesz az alkalmazásról, így a programozóiról is.
• Az adatstruktúra alkalmazásának képességének hiánya: A szigorú sémák néha nagy problémát jelenthetnek, de okosan használva hatékony mechanizmust jelentenek a jó adatstrukturáláshoz. Az olyan dokumentum-adatbázisok, mint a MongoDB, hihetetlen sémarugalmasságot biztosítanak, de ez a rugalmasság eltávolítja az adatok tisztántartásának felelősségét. Ha nem gondoskodik róluk, akkor a végén sok kódot fog írni az alkalmazásába, hogy figyelembe vegye azokat az adatokat, amelyek nem az elvárt formában tárolódnak. Ahogy a Simple Thread cégünknél szoktuk mondani... az alkalmazást egyszer átírják, de az adatok örökké élni fognak. Megjegyzés: A MongoDB támogatja a sémaellenőrzést: hasznos, de nem nyújt ugyanolyan garanciákat, mint egy relációs adatbázisban. Először is, egy sémaellenőrzés hozzáadása vagy módosítása nincs hatással a gyűjteményben lévő meglévő adatokra. Önnek kell gondoskodnia arról, hogy az adatokat az új séma szerint frissítse. Döntse el maga, hogy ez elég-e az Ön igényeinek.
• Natív lekérdezési nyelv / eszközökoszisztéma elvesztése: Az SQL megjelenése abszolút forradalom volt, és azóta sem változott semmi. Ez egy hihetetlenül erős nyelv, de egyben meglehetősen összetett is. Az adatbázis-lekérdezések JSON-töredékekből álló új nyelven való létrehozásának szükségességét nagy visszalépésnek tekintik az SQL-lel kapcsolatos tapasztalattal rendelkezők. Az SQL-adatbázisokkal kölcsönhatásba lépő eszközök egész világa létezik, az IDE-től a jelentéskészítő eszközökig. Az SQL-t nem támogató adatbázisra való áttérés azt jelenti, hogy nem tudja használni az eszközök többségét, vagy le kell fordítania az adatokat SQL-be ​​a használatukhoz, ami nehezebb lehet, mint gondolná.

Sok fejlesztő, aki a MongoDB-hez fordult, nem igazán értette a kompromisszumokat, és gyakran merült bele a telepítésbe, mint elsődleges adattárba. Ezek után sokszor hihetetlenül nehéz volt visszatérni.

Mit lehetett volna másképp csinálni?

Nem mindenki ugrott fejjel előre és találta el az alját. De sok projekt telepítette a MongoDB-t olyan helyekre, ahol egyszerűen nem illett – és még sok évig együtt kell élniük vele. Ha ezek a szervezetek eltöltöttek volna egy kis időt, és módszeresen átgondolták volna technológiai döntéseiket, sokan másképpen döntöttek volna.

Hogyan válasszuk ki a megfelelő technológiát? Számos kísérlet történt a technológiaértékelés szisztematikus keretének megteremtésére, mint pl "A technológiák szoftverszervezetekbe történő bevezetésének keretrendszere" и "Szoftvertechnológiák értékelésének keretrendszere", de számomra úgy tűnik, hogy ez felesleges bonyolultság.

Számos technológia intelligensen értékelhető, ha csupán két alapvető kérdést teszünk fel. A probléma az, hogy megtaláljuk azokat az embereket, akik felelősségteljesen tudnak válaszolni rájuk, időt szánva a válaszok megtalálására, elfogultság nélkül.

Ha nincs problémája, nincs szüksége új eszközre. Pont.

1. kérdés: Milyen problémákat próbálok megoldani?

Ha nincs problémája, nincs szüksége új eszközre. Pont. Nem kell megoldást keresni, majd kitalálni egy problémát. Hacsak nem találkozott olyan problémával, amelyet az új technológia lényegesen jobban megold, mint a meglévő technológiája, nincs miről beszélni. Ha fontolgatja ennek a technológiának a használatát, mert látta, hogy mások is használják, gondolja át, milyen problémákkal kell szembenézniük, és kérdezze meg, hogy Önnek is vannak-e ilyen problémái. Könnyű elfogadni egy technológiát, mert mások is használják, a kihívás az, hogy megértsd, te is szembesülsz-e ugyanazokkal a problémákkal.

2. kérdés: Mit hiányolok?

Ez minden bizonnyal nehezebb kérdés, mert bele kell mélyednie, és jól ismernie kell mind a régi, mind az új technológiát. Néha nem igazán érthetsz meg egy újat, amíg nem építettél fel vele valamit, vagy ha valaki nem rendelkezik ezzel a tapasztalattal.

Ha egyikkel sem rendelkezik, akkor érdemes átgondolni a lehetséges minimális befektetést az eszköz értékének meghatározásához. És ha egyszer végrehajtja a befektetést, mennyire lesz nehéz megfordítani a döntést?

Az emberek mindig mindent elrontanak

Amikor megpróbál a lehető legelfogulatlanabb választ adni ezekre a kérdésekre, ne feledjen egy dolgot: meg kell küzdenie az emberi természettel. Számos kognitív torzítást kell leküzdeni a technológia hatékony értékeléséhez. Íme néhány:

• A többséghez való csatlakozás hatása - Mindenki tud róla, de még mindig nehéz harcolni vele. Csak győződjön meg arról, hogy a technológia valóban megfelel az Ön tényleges igényeinek.
• Újdonság hatás — Sok fejlesztő hajlamos alábecsülni azokat a technológiákat, amelyekkel régóta dolgozott, és túlbecsüli az új technológia előnyeit. Nem csak a programozók, mindenki érzékeny erre a kognitív elfogultságra.
• Pozitív jellemzők hatása - Hajlamosak vagyunk látni, hogy mi van, és szem elől tévesztjük azt, ami hiányzik. Ez káoszhoz vezethet, ha az újdonság hatásával párosul, mivel nemcsak eredendően túlértékeli az új technológiát, hanem figyelmen kívül hagyja annak hiányosságait is..

Az objektív értékelés nem könnyű, de a mögöttes kognitív torzítások megértése segít racionálisabb döntéseket hozni.

Összegzés

Amikor egy újítás megjelenik, két kérdésre kell nagy gonddal választ adni:

• Ez az eszköz valódi problémát old meg?
• Jól értjük a kompromisszumokat?

Ha nem tud magabiztosan válaszolni erre a két kérdésre, tegyen néhány lépést hátra, és gondolkodjon.

Tehát a MongoDB a megfelelő választás volt? Természetesen igen; Mint a legtöbb mérnöki technológia, ez is sok tényezőtől függ. Azok közül, akik válaszoltak erre a két kérdésre, sokan részesültek a MongoDB-ből, és továbbra is ezt teszik. Azok számára, akik nem, remélem, értékes és nem túl fájdalmas leckét kaptak a hype-cikluson való áthaladásról.

Jogi nyilatkozat

Szeretném tisztázni, hogy a MongoDB-vel nincs sem szerelmi, sem gyűlölet-kapcsolatom. Egyszerűen nem voltak olyan problémák, amelyek megoldására a MongoDB a legalkalmasabb. Tudom, hogy a 10gen/MongoDB Inc. eleinte nagyon merész volt, nem biztonságos alapértelmezéseket állított be, és mindenhol (főleg hackathonokon) népszerűsítette a MongoDB-t, mint univerzális megoldást bármilyen adattal való munkavégzésre. Valószínűleg rossz döntés volt. De megerősíti az itt leírt megközelítést: ezek a problémák a technológia felületes értékelésével is nagyon gyorsan észlelhetők.

Forrás: will.com