For nylig fandt jeg ud af, at (siger de, på grund af ændringer i licensen). Dette fik mig til at tænke over, at jeg de seneste par år har set en masse artikler om, hvor forfærdelig MongoDB er, og at ingen nogensinde burde bruge den. Men i løbet af den tid er MongoDB blevet et langt mere modent produkt. Hvad er der sket? Forklarer al den had virkelig fejlene i begyndelsen af marketing for den nye DBMS? Eller bruger folk bare MongoDB de forkerte steder?
Hvis du pludselig synes, at jeg forsvarer MongoDB, så læs venligst for enden af artiklen.
Ny trend
Jeg har arbejdet i softwareindustrien i længere tid, end det er passende at nævne, men jeg har kun set en lille del af de tendenser, der har ramt vores branche. Jeg har været vidne til væksten af 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain... listen er uendelig. Nye tendenser dukker op hvert år. Nogle forsvinder hurtigt, mens andre fundamentalt ændrer måden, vi udvikler software på.
Rundt om hver ny trend opstår der en form for universel ophidselse: folk hopper selv ind i båden, eller de ser det støj, der genereres af andre – og følger mængden. Denne proces er blevet kodificeret af Gartner i . Selvom den er kontroversiel, beskriver denne graf nogenlunde, hvad der sker med teknologier, før de til sidst bliver nyttige at bruge.
Men fra tid til anden opstår der (eller sker der et andet komme, som i dette tilfælde) en ny innovation, drevet kun af en specifik implementering. I tilfælde af NoSQL var hypen stærkt betinget af fremkomsten og den hurtige stigning af MongoDB. Det var ikke MongoDB, der startede denne trend: faktisk begyndte store internetfirmaer at have problemer med at håndtere store datamængder, hvilket førte til genopblussen af ikke-relationelle databaser. Den generelle bevægelse startede med projekter som Googles Bigtable og Facebooks Cassandra, men det var netop MongoDB, der blev den mest kendte og tilgængelige NoSQL-database, som de fleste udviklere havde adgang til.
Bemærk: du kan tænke, at jeg blander dokumentdatabaser med kolonnebaserede databaser, nøgle/værdi-lagre eller nogen af de mange andre typer datalagre, der falder ind under den generelle definition af NoSQL. Og du har ret. Men på det tidspunkt herskede der kaos. Alle var besatte af NoSQL, det blev for dem absolut det er nødvendigt, selvom mange ikke har set forskelle i forskellige teknologier. For mange blev MongoDB lig med NoSQL.
Og udviklerne kastede sig over den. Ideen om en skemaløs database, der magisk kunne skaleres til at løse ethvert problem, var ret tiltalende. Omkring 2014 så det ud til, at hvor der før var blevet brugt en relationel database som MySQL, Postgres eller SQL Server, begyndte man at implementere MongoDB-databaser. På spørgsmålet om hvorfor kunne man få svar fra det banale "det er webskala" til det mere gennemarbejdede "mine data er meget svagt struktureret og passer godt ind i en skemaløs database."
Det er vigtigt at huske, at MongoDB og dokumentdatabaser generelt løser en række problemer med traditionelle relationelle databaser:
- Strenge skemaer: med en relationel database, hvis du har dynamisk genererede data, er du nødt til enten at lave en masse tilfældige "forskellige" datakolonner, presse blob-data ind eller bruge en konfiguration … alt dette har betydelige ulemper.
- Skalérbarhed: hvis dataene er så mange, at de ikke kan være på én server, tilbød MongoDB mekanismer, der gjorde det muligt at skalere dem på flere maskiner.
- Komplekse skemændringer: ingen migrationer! I en relationel database kan ændring af databasens struktur blive et kæmpe problem (især når dataene bliver meget store). MongoDB har været i stand til betydeligt at forenkle processen. Og de gjorde det så let, at du bare kan opdatere skemaet undervejs og hurtigt komme videre.
- Skriveydelse: MongoDB's ydelse var god, især med korrekt konfiguration. Selv en standardkonfiguration af MongoDB, som den ofte blev kritiseret for, viste nogle imponerende ydeevneindikatorer.
Alle risici er på dig
De potentielle fordele ved MongoDB var enorme, især for bestemte typer af problemer. Hvis man læser den ovenstående liste uden at forstå konteksten og uden erfaring, kan man få indtryk af, at MongoDB virkelig er en revolutionerende DBMS. Det eneste problem var, at de nævnte fordele blev ledsaget af en række forbehold, hvor nogle af dem er nævnt nedenfor.
For the sake of fairness, no one at 10gen/MongoDB Inc. will say that what follows is untrue; these are simply compromises.
- Tab af transaktioner: transaktioner er en grundlæggende egenskab ved mange relationsdatabaser (ikke alle, men de fleste). Transaktionalitet betyder, at du kan udføre flere operationer atomart og kan garantere, at dataene forbliver konsistente. Selvfølgelig kan transaktionalitet i en NoSQL-database være inden for ét dokument, eller du kan bruge to-fase commit for at opnå transaktionel semantik. Men du skal selv implementere denne funktionalitet... hvilket kan være en kompleks og tidskrævende opgave. Ofte opdager du ikke problemerne, før du ser, at data i databasen ender i uacceptable tilstande, fordi det er umuligt at garantere atomaritet i operationerne. Bemærk: mange har informeret mig om, at transaktioner blev tilføjet i MongoDB 4.0 sidste år, men med en række begrænsninger. Konklusionen fra artiklen forbliver den samme: vurder, hvor godt teknologien passer til dine behov.
- Tab af relationel integritet (fremmednøgler): hvis dine data har relationer, skal du anvende dem i applikationen. At have en database, der opretholder disse relationer, vil reducere en betydelig del af arbejdet med applikationen og dermed for dine programmører.
- Manglende evne til at anvende datastrukturen: strenge skemaer kan undertiden udgøre et stort problem, men det er også en kraftfuld mekanisme til god dataopbygning, hvis de bruges korrekt. Dokumentdatabaser som MongoDB giver utrolig fleksibilitet i skemaet, men denne fleksibilitet fralægger ansvaret for at holde dataene i orden. Hvis du ikke passer på dem, vil du ende med at skrive meget kode i applikationen for at håndtere data, der ikke opbevares i den form, du forventer. Som man ofte siger i vores virksomhed, Simple Thread... applikationen vil en dag blive omskrevet, men dataene vil leve for evigt. Bemærk: MongoDB understøtter skemavalidering; det er nyttigt, men giver ikke de samme garantier som en relationsdatabase. Først og fremmest påvirker tilføjelse eller ændring af skemavalidering ikke eksisterende data i samlingen. Du skal selv sikre dig, at du opdaterer dataene i overensstemmelse med det nye skema. Vurder selv, om dette er tilstrækkeligt til dine behov.
- Eget forespørgselssprog / tab af værktøjsøkosystem: fremkomsten af SQL var en absolut revolution, og siden da er intet ændret. Det er et utroligt magtfuldt sprog, men også temmelig komplekst. Behovet for at konstruere forespørgsler mod databasen på et nyt sprog, der består af JSON-fragmenter, ses som et stort skridt tilbage af personer med erfaring i SQL. Der findes et helt univers af værktøjer, der interagerer med SQL-databaser: fra IDE'er til rapporteringsværktøjer. Overgangen til en database, der ikke understøtter SQL, betyder, at du ikke kan bruge de fleste af disse værktøjer, eller du skal konvertere dataene til SQL for at bruge dem, hvilket kan vise sig at være sværere, end du tror.
Mange udviklere, der henvendte sig til MongoDB, havde ikke rigtig forstået kompromiserne og dykkede ofte hovedkuls ned, idet de installerede det som deres primære datalager. Efter det var det ofte utroligt svært at vende tilbage.
Hvad kunne have været gjort anderledes?
Ikke alle sprang hovedkuls frem og bragede ned. Men mange projekter installerede MongoDB, hvor det simpelthen ikke passede – og de må leve med det i mange år fremover. Hvis disse organisationer havde brugt lidt tid på systematisk at overveje teknologivalget, ville mange have truffet et andet valg.
Hvordan vælger man den rette teknologi? Der har været flere forsøg på at skabe et systematisk rammeværk til vurdering af teknologier, såsom og , men jeg mener, at dette er unødvendig kompleksitet.
Mange teknologier kan fornuftigt vurderes ved at stille bare to grundlæggende spørgsmål. Problemet ligger i at finde personer, der kan svare ansvarligt på dem, bruge tid på at finde svar og uden forudindtagethed.
Hvis du ikke står over for et bestemt problem, har du ikke brug for et nyt værktøj. Punktum.
Spørgsmål 1: Hvilke problemer forsøger jeg at løse?
Hvis du ikke står over for et problem, er der ikke behov for et nyt værktøj. Punktum. Der er ingen grund til at lede efter en løsning og derefter finde på et problem. Hvis du ikke har stødt på et problem, som den nye teknologi løser betydeligt bedre end din nuværende teknologi, er der ikke noget at diskutere. Hvis du overvejer at bruge denne teknologi, fordi du har set andre bruge den, skal du tænke over, hvilke problemer de står over for, og spørge, om du har de samme problemer. Det er let at tage teknologien til sig, fordi andre gør det; udfordringen ligger i at forstå, om du står over for de samme problemer.
Spørgsmål 2: Hvad går jeg glip af?
Dette er uden tvivl et sværere spørgsmål, fordi du skal grave dybt og forstå både den gamle og den nye teknologi godt. Nogle gange kan du ikke virkelig forstå det nye, før du bygger noget med det, eller før du har en medarbejder med den erfaring.
Hvis du ikke har det ene eller det andet, giver det mening at overveje de mindste mulige investeringer for at bestemme værdien af dette værktøj. Og hvis du foretager investeringer, hvor svært vil det så være at annullere beslutningen?
Mennesker ødelægger altid alt
Når du forsøger at besvare disse spørgsmål så objektivt som muligt, skal du huske én ting: du vil skulle kæmpe mod den menneskelige natur. Der er en række kognitive skævheder, som du skal overvinde for effektivt at kunne vurdere teknologien. Her er bare nogle få:
- — alle kender den, men den er stadig svær at håndtere. Sørg for, at teknologien virkelig matcher dine reelle behov.
- — mange udviklere har tendens til at undervurdere teknologier, de har arbejdet med i lang tid, og overvurdere fordelene ved ny teknologi. Det er ikke kun programmører, alle er udsat for denne kognitive skævhed.
- — vi har en tendens til at se, hvad der er, og overse, hvad der mangler. Dette kan føre til kaos i forbindelse med nyhedseffekten, da du ikke kun undervurderer den nye teknologi, men også ignorerer dens mangler..
Det er ikke nemt at give en objektiv vurdering, men forståelsen af de grundlæggende kognitive skævheder kan hjælpe os med at træffe mere rationelle beslutninger.
CV
Når der opstår en ny innovation, skal man forsigtigt besvare to spørgsmål:
- Løser dette værktøj et reelt problem?
- Forstår vi kompromisserne korrekt?
Hvis du ikke kan svare sikkert på disse to spørgsmål, så tag et skridt tilbage og tænk efter.
Var MongoDB overhovedet det rigtige valg? Selvfølgelig ja; ligesom med de fleste ingeniørteknologier afhænger det af mange faktorer. Blandt dem, der har besvaret disse to spørgsmål, har mange haft glæde af MongoDB og fortsætter med at have det. For dem, der ikke gjorde, håber jeg, at de fik en værdifuld og ikke alt for smertefuld lektion om at navigere i hype-cyklussen.
Fraskrivelse
Jeg vil gerne præcisere, at jeg hverken hader eller elsker MongoDB. Vi har bare ikke haft de problemer, hvor MongoDB ville være den bedste løsning. Jeg ved, at 10gen/MongoDB Inc. i starten handlede meget dristigt ved at sætte usikre standardværdier og promovere MongoDB overalt (især på hackathons) som en universalløsning til alle datatyper. Det var sandsynligvis en dårlig beslutning. Men det bekræfter den tilgang, der beskrives her: disse problemer kunne hurtigt opdages, selv ved en overfladisk vurdering af teknologien.
Kilde: habr.com
