Det fandt jeg for nylig ud af (siger de på grund af licensændringer). Dette fik mig til at tænke, fordi jeg i de sidste par år har set et væld af artikler om, hvor forfærdeligt MongoDB er, og hvordan ingen nogensinde bør bruge det. Men i løbet af denne tid er MongoDB blevet et meget mere modent produkt. Hvad skete der? Skyldes alt hadet virkelig fejl i den tidlige markedsføring af et nyt DBMS? Eller bruger folk bare MongoDB de forkerte steder?
Hvis du føler, at jeg forsvarer MongoDB, så læs venligst i slutningen af artiklen.
Ny tendens
Jeg har arbejdet i softwarebranchen i flere år, end jeg kan sige, men jeg har stadig kun været udsat for en lille del af de trends, der har ramt vores branche. Jeg har været vidne til fremkomsten af 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain ... listen er uendelig. Hvert år dukker nye trends op. Nogle forsvinder hurtigt, mens andre fundamentalt ændrer måden, software udvikles på.
Hver ny trend skaber en generel spænding: Folk hopper enten ombord eller ser støjen, der genereres af andre og følger mængden. Denne proces er kodificeret af Gartner i . Selvom den er kontroversiel, beskriver denne tidslinje groft, hvad der sker med teknologier, før de til sidst bliver nyttige.
Men fra tid til anden dukker en ny innovation op (eller kommer igen, som i dette tilfælde) drevet af kun én specifik implementering. I tilfældet med NoSQL var hypen stærkt drevet af fremkomsten og den voldsomme stigning af MongoDB. MongoDB startede ikke denne tendens: Faktisk begyndte store internetvirksomheder at have problemer med at behandle store mængder data, hvilket førte til tilbagevenden af ikke-relationelle databaser. Den overordnede bevægelse startede med projekter som Googles Bigtable og Facebooks Cassandra, men det var MongoDB, der blev den mest kendte og tilgængelige NoSQL-databaseimplementering, som de fleste udviklere havde adgang til.
Bemærk: Du tror måske, at jeg forveksler dokumentdatabaser med kolonnebaserede databaser, nøgle-/værdilagre eller en af de mange andre typer datalagre, der falder ind under den generelle NoSQL-definition. Og du har ret. Men på det tidspunkt herskede kaos. Alle er besat af NoSQL, det er blevet til alle absolut nødvendigt, selvom mange ikke så forskellene i forskellige teknologier. For mange er MongoDB blevet synonymt NoSQL.
Og udviklerne kastede sig over det. Ideen om en skemaløs database, der på magisk vis skaleres for at løse ethvert problem, var ret fristende. Omkring 2014 så det ud til, at overalt, der for et år siden brugte en relationsdatabase som MySQL, Postgres eller SQL Server, begyndte at implementere MongoDB-databaser. Når du bliver spurgt hvorfor, kunne du få et svar fra det banale "dette er nettets skala" til det mere betænksomme "mine data er meget løst struktureret og passer godt ind i en database uden et skema."
Det er vigtigt at huske, at MongoDB og dokumentdatabaser generelt løser en række problemer med traditionelle relationsdatabaser:
- Strenge ordning: Med en relationsdatabase, hvis du har dynamisk genereret data, er du tvunget til enten at oprette en masse tilfældige "diverse" kolonner af data, skubbe klatter af data derind eller bruge konfiguration ...alt dette har betydelige ulemper.
- Besvær med at skalere: Hvis der er så mange data, at det ikke passer på én server, tilbød MongoDB mekanismer, der gør det muligt at skalere på tværs af flere maskiner.
- Komplekse kredsløbsmodifikationer: ingen migrationer! I en relationel database kan det være et stort problem at ændre databasestrukturen (især når der er mange data). MongoDB var i stand til i høj grad at forenkle processen. Og det gjorde det så nemt, at du bare kan opdatere kredsløbet, mens du går, og komme videre meget hurtigt.
- Optagelse af ydeevne: MongoDB-ydelsen var god, især når den var korrekt konfigureret. Selv MongoDB's out-of-the-box-konfiguration, som den ofte blev kritiseret for, viste nogle imponerende præstationstal.
Alle risici er på dig
De potentielle fordele ved MongoDB var enorme, især for visse typer problemer. Hvis du læser ovenstående liste uden at forstå sammenhængen og uden erfaring, kan du få det indtryk, at MongoDB virkelig er et revolutionerende DBMS. Det eneste problem var, at fordelene nævnt ovenfor kom med en række forbehold, hvoraf nogle er anført nedenfor.
For at være retfærdig er der ingen hos 10gen/MongoDB Inc. vil ikke sige, at følgende ikke er sandt, det er blot kompromiser.
- Tabte transaktioner: Transaktioner er en kernefunktion i mange relationelle databaser (ikke alle, men de fleste). Transaktionel betyder, at du kan udføre flere operationer atomært og kan sikre, at dataene forbliver konsistente. Med en NoSQL-database kan transaktionalitet naturligvis være inden for et enkelt dokument, eller du kan bruge to-fasede commits til at få transaktionssemantik. Men du bliver nødt til selv at implementere denne funktionalitet... hvilket kan være en vanskelig og tidskrævende opgave. Ofte indser du ikke, at der er et problem, før du ser, at dataene i databasen ender i ugyldige tilstande, fordi atomiciteten af operationer ikke kan garanteres. Bemærk: Mange mennesker fortalte mig, at MongoDB 4.0 introducerede transaktioner sidste år, men med nogle begrænsninger. Takeaway fra artiklen forbliver den samme: Vurder, hvor godt teknologien opfylder dine behov.
- Tab af relationel integritet (fremmednøgler): Hvis dine data har relationer, bliver du nødt til at anvende dem i applikationen. At have en database, der respekterer disse relationer, vil tage meget af arbejdet fra applikationen og derfor dine programmører.
- Manglende evne til at anvende datastruktur: Strenge skemaer kan nogle gange være et stort problem, men de er også en kraftfuld mekanisme til god datastrukturering, hvis de bruges fornuftigt. Dokumentdatabaser som MongoDB giver en utrolig skemafleksibilitet, men denne fleksibilitet fjerner ansvaret for at holde dataene rene. Hvis du ikke passer på dem, ender du med at skrive en masse kode i din ansøgning for at tage højde for data, der ikke er gemt i den form, du forventer. Som vi ofte siger hos vores virksomhed Simple Thread... vil applikationen en dag blive omskrevet, men dataene vil leve evigt. Bemærk: MongoDB understøtter skemakontrol: det er nyttigt, men giver ikke de samme garantier som i en relationsdatabase. Først og fremmest påvirker tilføjelse eller ændring af et skematjek ikke eksisterende data i samlingen. Det er op til dig at sikre, at du opdaterer dataene i henhold til det nye skema. Afgør selv, om dette er nok til dine behov.
- Native forespørgselssprog / tab af værktøjsøkosystem: Fremkomsten af SQL var en absolut revolution, og intet har ændret sig siden da. Det er et utroligt stærkt sprog, men også ret komplekst. Behovet for at konstruere databaseforespørgsler i et nyt sprog bestående af JSON-fragmenter betragtes som et stort skridt tilbage af folk, der har erfaring med at arbejde med SQL. Der er et helt univers af værktøjer, der interagerer med SQL-databaser, fra IDE'er til rapporteringsværktøjer. At flytte til en database, der ikke understøtter SQL, betyder, at du ikke kan bruge de fleste af disse værktøjer, eller du skal oversætte dataene til SQL for at bruge dem, hvilket kan være sværere, end du tror.
Mange udviklere, der henvendte sig til MongoDB, forstod ikke rigtigt afvejningerne og dykkede ofte med hovedet i at installere det som deres primære datalager. Herefter var det ofte utrolig svært at komme tilbage.
Hvad kunne have været gjort anderledes?
Ikke alle hoppede med hovedet først og ramte bunden. Men mange projekter har installeret MongoDB på steder, hvor det simpelthen ikke passede – og det skal de leve med i mange år fremover. Hvis disse organisationer havde brugt lidt tid og metodisk gennemtænkt deres teknologivalg, ville mange have truffet andre valg.
Hvordan vælger man den rigtige teknologi? Der har været flere forsøg på at skabe en systematisk ramme for teknologivurdering, som f.eks и , men det forekommer mig, at dette er unødvendig kompleksitet.
Mange teknologier kan intelligent vurderes ved blot at stille to grundlæggende spørgsmål. Problemet er at finde folk, der kan besvare dem ansvarligt, tage sig tid til at finde svarene og uden fordomme.
Hvis du ikke står over for noget problem, behøver du ikke et nyt værktøj. Prik.
Spørgsmål 1: Hvilke problemer forsøger jeg at løse?
Hvis du ikke står over for noget problem, behøver du ikke et nyt værktøj. Prik. Der er ingen grund til at lede efter en løsning og derefter opfinde et problem. Medmindre du er stødt på et problem, som den nye teknologi løser væsentligt bedre end din eksisterende teknologi, er der ikke noget at diskutere her. Hvis du overvejer at bruge denne teknologi, fordi du har set andre bruge den, så overvej hvilke problemer de står over for og spørg, om du har disse problemer. Det er nemt at acceptere en teknologi, fordi andre bruger den, udfordringen er at forstå, om du står over for de samme problemer.
Spørgsmål 2: Hvad mangler jeg?
Dette er bestemt et sværere spørgsmål, fordi du bliver nødt til at grave i og have en god forståelse af både den gamle og nye teknologi. Nogle gange kan man ikke rigtig forstå en ny, før man har bygget noget med den eller har nogen med den erfaring.
Hvis du hverken har nogen af dem, er det fornuftigt at tænke på den mindst mulige investering for at bestemme værdien af dette instrument. Og når først du har foretaget investeringen, hvor svært vil det så være at omgøre beslutningen?
Folk ødelægger altid alt
Mens du forsøger at besvare disse spørgsmål så upartisk som muligt, så husk én ting: du bliver nødt til at bekæmpe den menneskelige natur. Der er en række kognitive skævheder, der skal overvindes for effektivt at kunne evaluere teknologi. Her er blot nogle få:
- - alle ved om ham, men det er stadig svært at bekæmpe ham. Bare sørg for, at teknologien rent faktisk matcher dine faktiske behov.
- — Mange udviklere har en tendens til at undervurdere teknologier, de har arbejdet med i lang tid, og overvurderer fordelene ved ny teknologi. Det er ikke kun programmører, alle er modtagelige for denne kognitive bias.
- - Vi har en tendens til at se, hvad der er der, og miste overblikket over, hvad der mangler. Dette kan føre til kaos, når det kombineres med nyhedseffekten, da du ikke kun i sagens natur overvurderer ny teknologi, men også ignorerer dens mangler.
Objektiv vurdering er ikke let, men at forstå de underliggende kognitive skævheder vil hjælpe dig med at træffe mere rationelle beslutninger.
Resumé
Når en innovation dukker op, skal to spørgsmål besvares med stor omhu:
- Løser dette værktøj et reelt problem?
- Forstår vi kompromiserne godt?
Hvis du ikke sikkert kan besvare disse to spørgsmål, så tag et par skridt tilbage og tænk.
Så var MongoDB overhovedet det rigtige valg? Selvfølgelig ja; Som med de fleste ingeniørteknologier afhænger dette af mange faktorer. Blandt dem, der besvarede disse to spørgsmål, har mange nydt godt af MongoDB og fortsætter med at gøre det. For dem, der ikke gjorde det, håber jeg, at du har lært en værdifuld og ikke alt for smertefuld lektion om at bevæge dig gennem hype-cyklussen.
Ansvarsfraskrivelse
Jeg vil gerne præcisere, at jeg hverken har et kærligheds- eller hadforhold til MongoDB. Vi har bare ikke haft den slags problemer, som MongoDB er bedst egnet til at løse. Jeg ved, at 10gen/MongoDB Inc. var meget modig til at begynde med, satte usikre standardindstillinger og promoverede MongoDB overalt (især ved hackathons) som en universel løsning til at arbejde med alle data. Det var nok en dårlig beslutning. Men det bekræfter den fremgangsmåde, der er beskrevet her: Disse problemer kunne opdages meget hurtigt selv med en overfladisk vurdering af teknologien.
Kilde: www.habr.com