Nyligen fick jag veta att Red Hat tar bort stödet för MongoDB från Satellite (det sägs bero på ändringar i licensen). Detta fick mig att fundera på att under de senaste åren har jag sett massor av artiklar om hur fruktansvärt MongoDB är och att ingen någonsin borde använda det. Men under denna tid har MongoDB blivit en mycket mer mogen produkt. Vad har hänt? Förklaras all denna hat verkligen av felen i början av marknadsföringen av den nya databashanteraren? Eller använder folk bara MongoDB på fel platser?

Om du plötsligt tycker att jag försvarar MongoDB, vänligen läs disclaimer i slutet av artikeln.

En ny trend

Jag har arbetat inom mjukvaruindustrin längre än vad som är passande att nämna, men ändå har jag bara upplevt en liten del av de trender som har påverkat vår bransch. Jag har bevittnat tillväxten av 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain... listan är oändlig. Varje år dyker nya tendenser upp. Vissa falnar snabbt, medan andra radikalt förändrar sättet att utveckla programvara.

Runt varje ny trend skapas det en slags allmän upphetsning: folk hoppar antingen själva på tåget, eller så ser de det väsen som skapas av andra - och följer strömmen. Denna process kodifierades av Gartner i hypecykeln. Även om den är kontroversiell, beskriver denna graf ganska bra vad som händer med teknologier innan de till slut blir användbara.

Men då och då dyker en (eller en andra kommande, som i det här fallet) ny innovation upp, drivet av en enda specifik implementering. När det gäller NoSQL var hypen starkt präglad av framväxten och den snabba uppgången av MongoDB. Det var inte MongoDB som satte igång denna trend: i själva verket började stora internetföretag få problem med att hantera stora datavolymer, vilket ledde till att icke-relationsdatabaser kom tillbaka. Den allmänna rörelsen startade med projekt som Bigtable från Google och Cassandra från Facebook, men det var MongoDB som blev den mest kända och tillgängliga NoSQL-databasen, till vilken de flesta utvecklare hade tillgång.

Notera: Du kanske tror att jag blandar dokumentdatabaser med kolumndatabaser, nyckel-värde-lager eller något av de många andra typerna av datalager som faller under den gemensamma termen NoSQL. Och du har rätt. Men vid den tiden rådde kaos. Alla var besatta av NoSQL, det blev fullständigt det är nödvändigt, även om många inte märkte några skillnader mellan de olika teknologierna. För många blev MongoDB synonymt med NoSQL.

Och utvecklare kastade sig över det. Idén om en schemalös databas som magiskt kan skalas för att lösa vilket problem som helst var ganska lockande. Runt 2014 verkade det som om överallt där det för ett år sedan användes en relationsdatabas som MySQL, Postgres eller SQL Server, så började man implementera MongoDB-databaser. På frågan varför kunde du få svar som sträckte sig från den banala "det handlar om webbs skala" till det mer genomtänkta "mina data är väldigt dåligt strukturerade och passar bra i en schemalös databas".

Det är viktigt att komma ihåg att MongoDB och dokumentdatabaser i allmänhet löser ett antal problem med traditionella relationsdatabaser:

• Strikt schema: i en relationsdatabas, om du har dynamiskt genererade data, tvingas du antingen skapa en massa slumpmässiga "olika" datakolumner, trycka in blobbar av data eller använda en konfiguration EAV… allt detta har betydande nackdelar.
• Svårighet att skala: om det finns så mycket data att den inte får plats på en server, erbjöd MongoDB mekanismer för att skala den över flera maskiner.
• Komplexa schemaändringar: inga migrationer! I en relationsdatabas kan förändringar i databasens struktur bli ett stort problem (särskilt när datamängden växer mycket). MongoDB lyckades förenkla processen avsevärt. Och gjorde den så enkel att du bara kan uppdatera schemat på språng och snabbt gå vidare.
• Skrivprestanda: MongoDB:s prestanda var bra, särskilt med rätt inställningar. Även MongoDB-konfigurationen ur lådan, som ofta kritiserades, visade upp en del imponerande prestandasiffror.

All risk ligger på dig

De potentiella fördelarna med MongoDB var enorma, särskilt för vissa typer av problem. Om du läser listan ovan utan att förstå kontexten och utan erfarenhet kan det ge intryck av att MongoDB verkligen är en revolutionerande databashanterare. Det enda problemet var att de fördelar som nämndes ovan åtföljdes av ett antal förbehåll, varav några anges nedan.

För rättvisans skull, ingen på 10gen/MongoDB Inc. skulle säga att det som nämns nedan är osant, det är bara kompromisser.

• Förlust av transaktioner: transaktioner är en grundläggande funktion i många relationella databaser (inte alla, men de flesta). Transaktionalitet innebär att du kan utföra flera operationer atomärt och kan garantera att data förblir konsekventa. Naturligtvis kan transaktionalitet i en NoSQL-databas vara inom ett enda dokument, eller så kan du använda tvåfas-bekräftelser för att få transaktionell semantik. Men du måste implementera denna funktionalitet själv... vilket kan vara en komplicerad och tidskrävande uppgift. Ofta inser du inte problemen förrän du ser att data i databasen hamnar i ogiltiga tillstånd, eftersom det är omöjligt att garantera atomaritet av operationer. Notera: många har sagt till mig att transaktioner kom till MongoDB 4.0 förra året, men med ett antal begränsningar. Slutsatsen från artikeln förblir densamma: utvärdera hur väl teknologin passar dina behov.
• Förlust av relationell integritet (externa nycklar): om dina data har relationer, måste du tillämpa dem i applikationen. Att ha en databas som upprätthåller dessa relationer tar bort en betydande del av arbetet från applikationen och därmed från dina programmerare.
• Brist på möjlighet att tillämpa databasstruktur: strikta scheman kan ibland vara ett stort problem, men de är också en kraftfull mekanism för att strukturera data på ett bra sätt, om de används klokt. Dokumentbaserade databaser, såsom MongoDB, erbjuder otrolig schemaflexibilitet, men denna flexibilitet lägger ansvaret på att hålla data rena. Om du inte ser efter dem, så kommer det i slutändan att krävas mycket kod i applikationen för att hantera data som lagras i former som inte är vad du förväntar dig. Som det ofta sägs på vårt företag Simple Thread... applikationen kommer någon gång att skrivas om, men data kommer att leva för evigt. Obs: MongoDB stödjer schemakontroll: det är användbart, men ger inte samma garantier som en relationsdatabas. För det första påverkar tillägg eller ändring av schemakontroll inte befintliga data i samlingen. Du måste själv säkerställa att du uppdaterar data i enlighet med det nya schemat. Avgör själv om detta är tillräckligt för dina behov.
• Eget frågespråk / förlorad verktygsekosystem: introduktionen av SQL var en absolut revolution, och sedan dess har ingenting förändrats. Det är ett otroligt kraftfullt språk, men också ganska komplext. Behovet av att konstruera frågor till databasen på ett nytt språk bestående av JSON-fragment ses som ett stort steg tillbaka av dem med erfarenhet av SQL. Det finns ett helt universum av verktyg som interagerar med SQL-databaser: från IDE:er till rapporteringsverktyg. Att byta till en databas som inte stöder SQL betyder att du inte kan använda de flesta av dessa verktyg eller att du måste översätta data till SQL för att kunna använda dem, vilket kan vara svårare än du tror.

Många utvecklare som vände sig till MongoDB förstod inte riktigt kompromisserna, och ofta hoppade de huvudet först in i att installera den som sitt primära datalager. Efteråt var det ofta otroligt svårt att gå tillbaka.

Vad kunde ha gjorts annorlunda?

Inte alla hoppade huvudstupa och kraschade. Men många projekt installerade MongoDB på ställen där den helt enkelt inte passade - och de kommer att få leva med det i många år framöver. Om dessa organisationer hade tagit sig tid och metodiskt övervägt sitt teknikval skulle många ha gjort ett annat val.

Hur väljer man rätt teknik? Det har gjorts flera försök att skapa en systematisk ram för att utvärdera teknologier, såsom «Ramverket för införande av teknologier i mjukvaruorganisationer» och «Ramverk för utvärdering av mjukvaruteknologier», men jag tycker att det är onödig komplexitet.

Många teknologier kan rimligt utvärderas genom att ställa bara två grundläggande frågor. Problemet ligger i att hitta personer som kan svara på dem ansvarsfullt, ta sig tid att leta efter svar och vara objektiva.

Om du inte står inför något problem behöver du inte ett nytt verktyg. Punkt.

Fråga 1: Vilka problem försöker jag lösa?

Om du inte står inför något problem behöver du inte ett nytt verktyg. Punkt. Du behöver inte leta efter en lösning och sedan påhitta ett problem. Om du inte har stött på ett problem som den nya teknologin löser betydligt bättre än din befintliga teknologi, så är det inget att diskutera. Om du överväger att använda denna teknik för att andra gör det, tänk på vilka problem de står inför och fråga om du har sådana problem. Det är lätt att acceptera teknologi eftersom andra använder den, utmaningen ligger i att förstå om du står inför samma problem.

Fråga 2: Vad går jag miste om?

Detta är utan tvekan en svårare fråga, eftersom det kräver grävande och en god förståelse av både den gamla och den nya teknologin. Ibland kan du inte riktigt förstå den nya tills du har byggt något med den eller har en medarbetare med sådan erfarenhet.

Om du varken har det ena eller det andra är det rimligt att tänka på minimala investeringar för att fastställa värdet av detta verktyg. Och om du gör investeringar, hur svårt blir det att ångra beslutet?

Folk förstör alltid saker

När du försöker svara på dessa frågor så objektivt som möjligt, kom ihåg en sak: du kommer att behöva kämpa mot den mänskliga naturen. Det finns en rad kognitiva förvrängningar som måste övervinnas för att effektivt kunna bedöma teknologin. Här är bara några:

• Majoritetseffekt — alla känner till det, men det är fortfarande svårt att motverka. Se bara till att teknologin verkligen uppfyller dina verkliga behov.
• Nyhetseffekt — många utvecklare tenderar att underskatta teknologier de har arbetat med under lång tid och överskatta fördelarna med ny teknologi. Inte bara programmerare, alla är benägna att drabbas av denna kognitiva förvrängning.
• Positiva egenseffekt — vi tenderar att se det som finns och missar det som saknas. Detta kan leda till kaos i kombination med nyhetseffekten, eftersom du inte bara tenderar att överskatta den nya teknologin utan också ignorerar dess brister..

En objektiv bedömning är inte lätt att göra, men förståelse för grundläggande kognitiva förvrängningar kan hjälpa till att fatta mer rationella beslut.

Sammanfattning

När en innovation uppstår, behöver man med stor försiktighet svara på två frågor:

• Löser det här verktyget ett verkligt problem?
• Förstår vi kompromisserna väl?

Om du inte kan svara på dessa två frågor med självförtroende, ta ett par steg tillbaka och fundera.

Var MongoDB verkligen rätt val? Absolut; precis som med de flesta ingenjörsteknologi, beror det på många faktorer. Många som svarade på dessa två frågor har dragit fördel av MongoDB och fortsätter att göra det. De som inte gjorde det hoppas jag har fått en värdefull och inte alltför smärtsam läxa om att navigera genom hype-cykeln.

Disclaimer

Jag vill klargöra att jag varken har någon kärlek eller hat mot MongoDB. Vi hade helt enkelt inte de problem som MongoDB är bäst lämpat att lösa. Jag vet att 10gen/MongoDB Inc. från början agerade mycket djärvt genom att sätta osäkra standardinställningar och marknadsföra MongoDB överallt (särskilt på hackathons) som en universallösning för att hantera alla typer av data. Det var förmodligen ett dåligt beslut, men det bekräftar det method som beskrivs här: dessa problem kunde snabbt upptäckas även vid en ytliga bedömning av teknologin.

Källa: habr.com