Jeg fant nylig ut det (sier de på grunn av lisensendringer). Dette fikk meg til å tenke fordi jeg de siste årene har sett massevis av artikler om hvor forferdelig MongoDB er og hvordan ingen noen gang skal bruke det. Men i løpet av denne tiden har MongoDB blitt et mye mer modent produkt. Hva skjedde? Skyldes egentlig alt hatet feil i den tidlige markedsføringen av et nytt DBMS? Eller bruker folk bare MongoDB på feil steder?
Hvis du føler at jeg forsvarer MongoDB, vennligst les på slutten av artikkelen.
Ny trend
Jeg har jobbet i programvareindustrien i flere år enn jeg kan si, men jeg har fortsatt bare blitt utsatt for en liten del av trendene som har rammet bransjen vår. Jeg har vært vitne til fremveksten av 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain ... listen er uendelig. Hvert år dukker det opp nye trender. Noen forsvinner raskt, mens andre fundamentalt endrer måten programvare utvikles på.
Hver ny trend skaper en generell spenning: folk hopper enten om bord, eller ser støyen som genereres av andre og følger mengden. Denne prosessen er kodifisert av Gartner i . Selv om den er kontroversiell, beskriver denne tidslinjen omtrent hva som skjer med teknologier før de til slutt blir nyttige.
Men fra tid til annen dukker det opp en ny innovasjon (eller kommer igjen, som i dette tilfellet) drevet av bare én spesifikk implementering. Når det gjelder NoSQL, var hypen sterkt drevet av fremveksten og den meteoriske økningen av MongoDB. MongoDB startet ikke denne trenden: faktisk begynte store internettselskaper å ha problemer med å behandle store mengder data, noe som førte til at ikke-relasjonelle databaser kom tilbake. Den generelle bevegelsen startet med prosjekter som Googles Bigtable og Facebooks Cassandra, men det var MongoDB som ble den mest kjente og tilgjengelige NoSQL-databaseimplementeringen som de fleste utviklere hadde tilgang til.
Merk: Du tror kanskje at jeg forveksler dokumentdatabaser med kolonnedatabaser, nøkkel-/verdilagre eller noen av de mange andre typene datalagre som faller inn under den generelle NoSQL-definisjonen. Og du har rett. Men på den tiden hersket kaos. Alle er besatt av NoSQL, det har blitt alle absolutt nødvendig, selv om mange ikke så forskjellene i ulike teknologier. For mange har MongoDB blitt synonymt med NoSQL.
Og utviklerne kastet seg over det. Ideen om en skjemaløs database som magisk skaleres for å løse ethvert problem var ganske fristende. Rundt 2014 så det ut til at overalt som for et år siden brukte en relasjonsdatabase som MySQL, Postgres eller SQL Server begynte å distribuere MongoDB-databaser. Når du blir spurt hvorfor, kan du få et svar fra det banale "dette er skalaen til nettet" til det mer gjennomtenkte "dataene mine er veldig løst strukturert og passer godt inn i en database uten et skjema."
Det er viktig å huske at MongoDB, og dokumentdatabaser generelt, løser en rekke problemer med tradisjonelle relasjonsdatabaser:
- Strengt opplegg: Med en relasjonsdatabase, hvis du har dynamisk generert data, er du tvunget til å enten lage en haug med tilfeldige "diverse" kolonner med data, skyve dataklatter inn der eller bruke konfigurasjon ...alt dette har betydelige ulemper.
- Vanskeligheter med å skalere: Hvis det er så mye data at det ikke passer på én server, tilbød MongoDB mekanismer for å tillate den å skalere på tvers av flere maskiner.
- Komplekse kretsendringer: ingen migrasjoner! I en relasjonsdatabase kan endring av databasestrukturen være et stort problem (spesielt når det er mye data). MongoDB var i stand til å forenkle prosessen betydelig. Og det gjorde det så enkelt at du bare kan oppdatere kretsen mens du går og gå videre veldig raskt.
- Opptak av ytelse: MongoDB-ytelsen var god, spesielt når den er riktig konfigurert. Til og med MongoDBs ut-av-boksen-konfigurasjon, som den ofte ble kritisert for, viste noen imponerende ytelsestall.
All risiko er på deg
De potensielle fordelene med MongoDB var enorme, spesielt for visse typer problemer. Hvis du leser listen ovenfor uten å forstå konteksten og uten erfaring, kan du få inntrykk av at MongoDB virkelig er et revolusjonerende DBMS. Det eneste problemet var at fordelene oppført ovenfor kom med en rekke forbehold, hvorav noen er oppført nedenfor.
For å være rettferdig, ingen hos 10gen/MongoDB Inc. vil ikke si at følgende ikke er sant, dette er bare kompromisser.
- Tapte transaksjoner: Transaksjoner er en kjernefunksjon i mange relasjonsdatabaser (ikke alle, men de fleste). Transaksjonelle betyr at du kan utføre flere operasjoner atomært og kan sikre at dataene forblir konsistente. Selvfølgelig, med en NoSQL-database, kan transaksjonalitet være innenfor et enkelt dokument, eller du kan bruke to-fase commits for å få transaksjonssemantikk. Men du må implementere denne funksjonaliteten selv... som kan være en vanskelig og tidkrevende oppgave. Ofte skjønner du ikke at det er et problem før du ser at dataene i databasen havner i ugyldige tilstander fordi atomiteten til operasjoner ikke kan garanteres. Merk: Mange fortalte meg at MongoDB 4.0 introduserte transaksjoner i fjor, men med noen begrensninger. Takeaway fra artikkelen forblir den samme: Vurder hvor godt teknologien oppfyller dine behov.
- Tap av relasjonsintegritet (fremmednøkler): Hvis dataene dine har relasjoner, må du bruke dem i applikasjonen. Å ha en database som respekterer disse relasjonene vil ta mye av arbeidet fra applikasjonen og dermed programmererne dine.
- Manglende evne til å anvende datastruktur: Strenge skjemaer kan noen ganger være et stort problem, men de er også en kraftig mekanisme for god datastrukturering hvis de brukes med omhu. Dokumentdatabaser som MongoDB gir utrolig skjemafleksibilitet, men denne fleksibiliteten fjerner ansvaret for å holde dataene rene. Hvis du ikke tar vare på dem, vil du ende opp med å skrive mye kode i applikasjonen din for å ta hensyn til data som ikke er lagret i den formen du forventer. Som vi ofte sier hos vårt firma Simple Thread... vil applikasjonen en dag bli skrevet om, men dataene vil leve evig. Merk: MongoDB støtter skjemakontroll: det er nyttig, men gir ikke de samme garantiene som i en relasjonsdatabase. Først av alt, å legge til eller endre en skjemasjekk påvirker ikke eksisterende data i samlingen. Det er opp til deg å sørge for at du oppdaterer dataene i henhold til det nye skjemaet. Bestem selv om dette er nok for dine behov.
- Native spørrespråk / tap av verktøyøkosystem: Fremkomsten av SQL var en absolutt revolusjon og ingenting har endret seg siden den gang. Det er et utrolig kraftig språk, men også ganske komplekst. Behovet for å konstruere databasespørringer på et nytt språk bestående av JSON-fragmenter blir sett på som et stort skritt tilbake av folk som har erfaring med å jobbe med SQL. Det finnes et helt univers av verktøy som samhandler med SQL-databaser, fra IDE-er til rapporteringsverktøy. Å flytte til en database som ikke støtter SQL betyr at du ikke kan bruke de fleste av disse verktøyene, eller du må oversette dataene til SQL for å bruke dem, noe som kan være vanskeligere enn du tror.
Mange utviklere som henvendte seg til MongoDB forsto egentlig ikke avveiningene, og dykket ofte med hodet først i å installere det som deres primære datalager. Etter dette var det ofte utrolig vanskelig å komme tilbake.
Hva kunne vært gjort annerledes?
Ikke alle hoppet med hodet først og traff bunnen. Men mange prosjekter har installert MongoDB på steder der det rett og slett ikke passet – og de må leve med det i mange år fremover. Hvis disse organisasjonene hadde brukt litt tid og metodisk tenkt gjennom sine teknologivalg, ville mange ha tatt andre valg.
Hvordan velge riktig teknologi? Det har vært flere forsøk på å lage et systematisk rammeverk for teknologivurdering, som f.eks и , men det virker for meg at dette er unødvendig kompleksitet.
Mange teknologier kan vurderes intelligent ved å stille to grunnleggende spørsmål. Problemet er å finne folk som kan svare dem på en ansvarlig måte, ta seg tid til å finne svarene og uten skjevhet.
Hvis du ikke har noe problem, trenger du ikke et nytt verktøy. Punktum.
Spørsmål 1: Hvilke problemer prøver jeg å løse?
Hvis du ikke har noe problem, trenger du ikke et nytt verktøy. Punktum. Det er ikke nødvendig å lete etter en løsning og deretter finne opp et problem. Med mindre du har støtt på et problem som den nye teknologien løser betydelig bedre enn din eksisterende teknologi, er det ingenting å diskutere her. Hvis du vurderer å bruke denne teknologien fordi du har sett andre bruke den, tenk på hvilke problemer de møter og spør om du har disse problemene. Det er lett å akseptere en teknologi fordi andre bruker den, utfordringen er å forstå om du møter de samme problemene.
Spørsmål 2: Hva går jeg glipp av?
Dette er definitivt et vanskeligere spørsmål fordi du må grave i og ha en god forståelse av både den gamle og nye teknologien. Noen ganger kan du egentlig ikke forstå en ny før du har bygget noe med den eller har noen med den erfaringen.
Hvis du ikke har noen av delene, er det fornuftig å tenke på minimum mulig investering for å bestemme verdien av dette instrumentet. Og når du først har gjort investeringen, hvor vanskelig vil det være å snu beslutningen?
Folk ødelegger alltid alt
Når du prøver å svare så upartisk som mulig på disse spørsmålene, husk én ting: du må kjempe mot menneskenaturen. Det er en rekke kognitive skjevheter som må overvinnes for å effektivt evaluere teknologi. Her er bare noen få:
- - Alle vet om ham, men det er fortsatt vanskelig å kjempe mot ham. Bare sørg for at teknologien faktisk samsvarer med dine faktiske behov.
- — Mange utviklere har en tendens til å undervurdere teknologier de har jobbet med lenge og overvurderer fordelene med ny teknologi. Det er ikke bare programmerere, alle er mottakelige for denne kognitive skjevheten.
- – Vi pleier å se hva som er der og miste av syne det som mangler. Dette kan føre til kaos når det kombineres med nyhetseffekten, ettersom du ikke bare overvurderer ny teknologi, men også ignorerer dens mangler.
Objektiv vurdering er ikke lett, men å forstå de underliggende kognitive skjevhetene vil hjelpe deg å ta mer rasjonelle beslutninger.
Oppsummering
Hver gang en innovasjon dukker opp, må to spørsmål besvares med stor forsiktighet:
- Løser dette verktøyet et reelt problem?
- Forstår vi avveiningene godt?
Hvis du ikke kan svare trygt på disse to spørsmålene, ta noen skritt tilbake og tenk.
Så var MongoDB til og med det riktige valget? Selvfølgelig ja; Som med de fleste ingeniørteknologier, avhenger dette av mange faktorer. Blant de som svarte på disse to spørsmålene, har mange hatt nytte av MongoDB og fortsetter å gjøre det. For de som ikke gjorde det, håper jeg du lærte en verdifull og ikke altfor smertefull leksjon om å gå gjennom hype-syklusen.
Ansvarsfraskrivelse
Jeg vil presisere at jeg verken har et kjærlighets- eller hatforhold til MongoDB. Vi har bare ikke hatt den typen problemer som MongoDB er best egnet til å løse. Jeg vet at 10gen/MongoDB Inc. var veldig dristig til å begynne med, satte usikre standardinnstillinger og promoterte MongoDB overalt (spesielt ved hackathons) som en universell løsning for å jobbe med alle data. Det var nok en dårlig avgjørelse. Men det bekrefter tilnærmingen som er beskrevet her: disse problemene kan oppdages veldig raskt selv med en overfladisk vurdering av teknologien.
Kilde: www.habr.com