Jag fick nyligen reda på det Red Hat tar bort MongoDB-stöd från Satellite (säg på grund av licensändringar). Det fick mig att tänka på att jag under de senaste åren har sett en massa artiklar om hur hemskt MongoDB är och att ingen någonsin borde använda det. Men under den här tiden har MongoDB blivit en mycket mer mogen produkt. Vad hände? Beror verkligen allt hat på misstag i början av marknadsföringen av det nya DBMS? Eller använder folk bara MongoDB på fel ställe?

Om du plötsligt känner att jag försvarar MongoDB, läs gärna varning i slutet av artikeln.

ny trend

Jag har varit i mjukvarubranschen i fler år än det är rimligt att säga, men ändå har jag bara varit en del av trenderna som drabbat vår bransch. Jag har sett uppkomsten av 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain ... listan är oändlig. Varje år kommer nya trender. Vissa bleknar snabbt, medan andra i grunden förändrar hur mjukvara utvecklas.

Kring varje ny trend skapas en viss allmän spänning: folk hoppar antingen själva i båten, eller ser ljudet som genereras av andra – och följer folkmassan. Denna process har kodifierats av Gartner i Hypecykel. Även om det är diskutabelt, beskriver denna graf ungefär vad som händer med teknologier innan de så småningom blir användbara för användning.

Men från tid till annan kommer det (eller kommer en andra ankomst, som i det här fallet) en ny innovation, driven av endast en specifik implementering av den. I fallet med NoSQL var hypen starkt driven av MongoDB:s tillkomst och snabba uppgång. MongoDB startade inte denna trend: i själva verket började stora internetföretag ha problem med att bearbeta stora mängder data, vilket ledde till återkomsten av icke-relationella databaser. Den allmänna rörelsen började med projekt som Googles Bigtable och Facebooks Cassandra, men det var MongoDB som blev den mest kända och tillgängliga implementeringen av NoSQL-databasen som de flesta utvecklare hade tillgång till.

Obs: Du kanske tror att jag blandar ihop dokumentdatabaser med kolumndatabaser, nyckel-/värdelager eller någon av de många andra typerna av datalager som faller under den allmänna definitionen av NoSQL. Och du har rätt. Men på den tiden rådde kaos. Alla är besatta av NoSQL, det har blivit allt absolut nödvändigt, även om många inte såg skillnaderna i olika tekniker. För många har MongoDB blivit synonymt med NoSQL.

Och utvecklarna hoppade på det. Idén med en schemalös databas som magiskt skalas för att lösa alla problem var ganska frestande. Runt 2014 verkade det som att överallt där en relationsdatabas som MySQL, Postgres eller SQL Server användes för ett år sedan, distribuerades MongoDB-databaser. På frågan varför kan du få svar från det banala "det här är webbens skala" till det mer genomtänkta "min data är väldigt löst strukturerad och passar bra i en databas utan schema."

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

• Strikt schema: med en relationsdatabas, om du har dynamiskt genererad data, tvingas du antingen skapa ett gäng slumpmässiga "olika" datakolumner, trycka in datablobbar där eller använda en konfiguration EAV-förlängning… 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 tillåta den att skala ut över flera maskiner.
• Komplexa kretsmodifikationer: inga migrationer! I en relationsdatabas kan det vara ett stort problem att ändra strukturen på databasen (särskilt när det finns mycket data). MongoDB har kunnat förenkla processen avsevärt. Och gjort det så enkelt att du bara kan uppdatera schemat när du är på språng och gå vidare riktigt snabbt.
• Skriv prestanda: MongoDB-prestandan var bra, speciellt när den var rätt inställd. Till och med den out-of-the-box-konfigurationen av MongoDB, som den ofta kritiserades för, visade några imponerande prestandasiffror.

Alla risker 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å sammanhanget och inte har någon erfarenhet, kan du få intrycket att MongoDB verkligen är ett revolutionerande DBMS. Det enda problemet var att fördelarna som anges ovan kom med ett antal varningar, av vilka några är listade nedan.

För att vara rättvis, ingen på 10gen/MongoDB Inc. kommer inte att säga att följande inte är sant, det här är bara kompromisser.

• Förlust av transaktionerS: Transaktioner är en kärnfunktion i många relationsdatabaser (inte alla, men de flesta). Transaktionell innebär att du kan utföra flera operationer atomärt och kan säkerställa att data förblir konsekventa. Naturligtvis, med en NoSQL-databas kan transaktionaliteten finnas inom ett enda dokument, eller så kan du använda tvåfas-commits för att få transaktionssemantik. Men du måste implementera den här funktionen själv... vilket kan vara en svår och tidskrävande uppgift. Ofta inser man inte problemet förrän man ser att data i databasen hamnar i ogiltiga tillstånd eftersom det är omöjligt att garantera atomiciteten i operationerna. Obs: Jag har fått höra av många att transaktioner introducerades i MongoDB 4.0 förra året, men med vissa begränsningar. Slutsatsen från artikeln är densamma: bedöm hur tekniken passar dina behov.
• Förlust av relationsintegritet (främmande nycklar): om dina data har relationer måste du tillämpa dem i applikationen. Att ha en databas som respekterar dessa relationer kommer att ta mycket arbete från applikationen och därför på dina programmerare.
• Oförmåga att tillämpa datastrukturen: Strikta scheman kan ibland vara ett stort problem, men de är också en kraftfull mekanism för bra datastrukturering om de används på ett klokt sätt. Dokumentdatabaser som MongoDB ger otrolig schemaflexibilitet, men den flexibiliteten tar bort ansvaret för att hålla data ren. Om du inte tar hand om dem kommer du att skriva mycket kod i din ansökan för att ta hänsyn till data som inte lagras i den form du förväntar dig. Som de ofta säger i vårt företag Simple Thread ... applikationen kommer att skrivas om en dag, men data kommer att leva för evigt. Obs: MongoDB stöder schemavalidering, vilket är användbart men inte ger samma garantier som en relationsdatabas. Först och främst, att lägga till eller ändra schemavalidering påverkar inte befintliga data i samlingen. Du måste se till att du uppdaterar data enligt det nya schemat. Bestäm själv om detta är tillräckligt för dina behov.
• Eget frågespråk / förlust av verktygsekosystem: Tillkomsten av SQL var en absolut revolution, och ingenting har förändrats sedan dess. Det är ett otroligt kraftfullt språk, men också ganska komplext. Behovet av att konstruera databasfrågor på ett nytt språk, bestående av JSON-fragment, betraktas som ett stort steg tillbaka av personer som har erfarenhet av SQL. Det finns ett helt universum av verktyg som interagerar med SQL-databaser, från IDE:er till rapportverktyg. Att flytta till en databas som inte stöder SQL innebär att du inte kan använda de flesta av dessa verktyg, eller så måste du konvertera 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 dykte ofta med huvudet först i att ställa in det som sitt primära datalager. Efter det var det ofta otroligt svårt att gå tillbaka.

Vad kunde ha gjorts annorlunda?

Alla hoppade inte med huvudet först och kraschade i botten. Men många projekt har installerat MongoDB-basen där den helt enkelt inte passade – och de kommer att få leva med den i många år till. Om dessa organisationer hade tagit lite tid på sig att metodiskt överväga sina 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 ett systematiskt ramverk för teknikbedömning, som t.ex "Ramverk för implementering av teknik i mjukvaruorganisationer" и "Framefork för utvärdering av mjukvaruteknik", men det verkar för mig att detta är en onödig komplexitet.

Många tekniker kan värderas intelligent genom att bara ställa två grundläggande frågor. Problemet ligger i att hitta människor som kan svara på ett ansvarsfullt sätt, ta sig tid att hitta svar och utan fördomar.

Om du inte har 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 har något problem behöver du inte ett nytt verktyg. Punkt. Du behöver inte leta efter en lösning och sedan komma på ett problem. Om du inte står inför ett problem som den nya tekniken inte löser nämnvärt bättre än din befintliga teknik, så finns det inget att diskutera här. Om du funderar på att använda den här tekniken för att du har sett andra använda den, tänk på problemen de har och fråga om du har de problemen. Det är lätt att ta till sig teknik eftersom andra använder den, svårigheten är att veta om du står inför samma problem.

Fråga 2: Vad saknar jag?

Detta är säkert en svårare fråga, eftersom man måste gräva och förstå både den gamla och den nya tekniken väl. Ibland kan man inte riktigt förstå en ny förrän man har byggt något med den eller har en kollega med den erfarenheten.

Om du inte har någondera, är det vettigt att tänka på minsta möjliga investering för att bestämma värdet på detta instrument. Och om du gör en investering, hur svårt blir det att vända beslutet?

Folk förstör alltid allt

När du försöker svara på dessa frågor så opartiskt som möjligt, kom ihåg en sak: du måste bekämpa den mänskliga naturen. Det finns ett antal kognitiva fördomar som måste övervinnas för att effektivt kunna utvärdera teknik. Här är bara några:

• Effekten av att gå med i majoriteten Alla vet om honom, men det är fortfarande svårt att slåss mot honom. Se bara till att tekniken verkligen passar dina verkliga behov.
• nyhetseffekt Många utvecklare tenderar att underskatta tekniker som de har arbetat med under lång tid och överskattar fördelarna med en ny teknik. Inte bara programmerare, alla är föremål för denna kognitiva fördom.
• Positiv attributeffekt Vi tenderar att se vad som är och tappa det som inte är det. Detta kan leda till kaos, kombinerat med nyhetseffekten, eftersom du inte bara i sig övervärderar den nya tekniken, utan också ignorerar dess brister..

Objektiv bedömning är inte lätt, men att förstå de underliggande kognitiva fördomarna kommer att hjälpa dig att fatta mer rationella beslut.

Sammanfattning

När en innovation dyker upp måste två frågor besvaras med stor omsorg:

• Löser detta verktyg ett verkligt problem?
• Är vi bra på att förstå avvägningar?

Om du inte med säkerhet kan svara på dessa två frågor, ta några steg tillbaka och tänk efter.

Så var la MongoDB generellt sett rätt val? Såklart ja; som med de flesta ingenjörstekniker beror det på många faktorer. Bland de som svarat på dessa två frågor har många haft nytta av MongoDB och fortsätter att göra det. För er som inte har det, hoppas jag att ni har lärt er en värdefull och inte alltför smärtsam läxa om att gå igenom hypecykeln.

varning

Jag vill förtydliga att jag inte älskar eller hatar MongoDB. Vi hade helt enkelt inte den typen av problem som MongoDB är bäst lämpad att lösa. Jag känner till 10gen/MongoDB Inc. agerade väldigt djärvt till en början, satte osäkra standardinställningar och främjade MongoDB överallt (särskilt vid hackathons) som en enda lösning för att arbeta med alla data. Det var nog ett dåligt beslut. Men det bekräftar det tillvägagångssätt som beskrivs här: dessa problem kunde upptäckas mycket snabbt även med en ytlig bedömning av tekniken.

Källa: will.com