MongoDB eller MySQL – så väljer du rätt

Under dotcombubblan runt år 2000 var det vanligt med mjukvarustacken LAMP för webbaserade applikationer. LAMP stod från början för Linux (operativsystem), Apache (webbserver), MySQL (relationsdatabas) och PHP (serverprogrammeringsspråk). Att MySQL valdes som databas berodde på stor del på att den var skriven som fri mjukvara med öppen källkod och hade goda läsprestanda. Det passade bra för applikationer typ ”webb 2.0”, som dynamiskt genererar webbsidor från en databas.

Senare kom MEAN-stacken i förgrunden. MEAN står för MongoDB (dokumentdatabas), Express (webbserver), AngularJS (ramverk för rendering av sidor) och Node.js (Javascriptprogram för drift av webbplatser). MEAN tilltalade många, bland annat för att man bara behövde behärska ett programspråk – Javascript. MEAN drar också mindre minne än en likvärdig LAMP-stack.

Vad är MySQL och MariaDB?

Det var Monty Widenius och David Axmark på MySQL AB som 1994 började utveckla MySQL. ”My” i namnet syftar på Monty Widenius dotter – det är inte engelska ”my”. MySQL utformades för att vara API-kompatibelt med mSQL (även känt som Mini SQL). Till det fogades kapacitet för SQL-frågor och en licens för öppen källkod. (I själva verket var det dubbla licenser, en GPL-licens och en företagsspecifik). Databashanteraren släpptes första gången 1996, och nya versioner kom med ett eller två års mellanrum. MySQL är för närvarande den mest spridda relationsdatabasen.

Dåvarande Sun Microsystems köpte MySQL AB år 2008 för en miljard dollar, och 2010 köpte Oracle i sin tur Sun. Det gav upphov till oro för vad Oracle tänkte göra med MySQL. Men just innan Oracle köpte Sun gjorde Monty Widenius en förgrening av MySQL 5.5 och kallade den för MariaDB. Han har sedan dess strävat efter att hålla MariaDB kompatibel med Oracles utföranden av MySQL.

MySQL var från början en rätt enkel relationsdatabashanterare i jämförelse med mer kraftfulla kommersiella relationsdatabaserhanterare som Oracle Database, IBM DB/2 och Microsoft SQL Server. Men den räckte för att backa upp dynamiska webbplatser. Under årens lopp har MySQL försetts med de flesta funktioner som man räknar med att finna i en relationsdatabas, såsom transaktionshantering, referensintegritet, lagrade procedurer, cursorer, fulltextindexering och sökning, geografisk indexering och klustring.

MySQL används fortfarande mest i små till mellanstora system, även om det numera klarar att vara “stor databas” med funktioner som master-slave, användning med Memcached och horisontell sharding. Uppskalning av MySQL med flera slavar förbättrar läsprestanda, men bara mastern tar emot skrivinstruktioner.

Amazons AWS erbjuder MySQL i två smaker, Amazon RDS och Amazon Aurora. Den senare har mycket bättre prestanda, kan hantera terabytevolymer av data och är snabbare på att uppdatera repliker. Det är en direkt konkurrent till Oracle Database och SQL Server.

Vad är MongoDB?

MongoDB är en mycket skalbar dokumentdatabas som finns både med öppen källkod och i en version för större företag. Den kan köras lokalt eller som molnbaserad funktionstjänst. Funktionstjänsten i molnet heter MongoDB Atlas.

MongoDB är utan konkurrens den mest populära NoSQL-databasen. Dokumentdatamodellen ger utvecklare mycket svängrum, och dess distribuerade arkitektur ger hög skalbarhet. Därför väljs MongoDB ofta för applikationer som måste hantera stora datavolymer, som fungerar bäst med horisontell skalbarhet och som arbetar med datastrukturer som inte passar in i den relationella modellen.

MongoDB är en dokumentbaserad databashanterare som också har en inbyggd grafdatabas. Mongo lagrar faktiskt inte JSON. Den lagrar BSON (binär JSON). Det innebär att JSON-representationen (teckensträngar) breddas och dessutom omfattar datatyper som int, long, data, flyttal, decimal128 och geospatiala koordinater.

MongoDB kan generera multimodala grafer, geospatialt, B-träd och kompletta textindex från ett enda exemplar av en datamängd. Datatypen avgör vilken typ av index som väljs. MongoDB ger möjlighet att skapa index för alla dokumentfält. MongoDB 4 klarar multidokumenttransaktioner, vilket innebär att du kan få ACID-egenskaper – även om du måste normalisera ditt dataupplägg.

Som förval använder MongoDB dynamiska scheman. Det kallas ibland för schemalöst. Dokumenten i en samling måste inte ha samma uppsättning fält, och datatypen i ett fält kan variera mellan dokumenten i en samling. Du kan ändra dokumentstrukturer med dynamiska scheman när som helst.

Schemastyrning finns också att tillgå. Med början med MongoDB 3.6 stöder MongoDB schemavalidering med JSON, vilket man kan slå på i valideringsuttrycket.

LAMP- och MEAN-stackarna

Det finns många varianter av LAMP och MEAN. I stället för Linux kan man köra på Windows (WAMP) eller MacOS (MAMP). Och med Windows kan man välja bort Apacheservern och i stället köra IIS (WIMP).

I stället för MySQL-databasen i LAMP kan man köra PostgreSQL eller SQL Server. Om man behöver global distribution kan man köra CockroachDB eller Google Cloud Spanner. Och i stället för PHP kan man välja att koda i Perl eller Python. Vill du i stället koda i Java eller C# finns det andra stackar att välja bland.

I stället för MongoDB i MEAN kan man köra Couchbase eller Azure Cosmos DB och få bättre global distribution. I stället för Express kan du välja bland ett dussin ramverk baserade på Node.js. Och i stället för AngularJS kan du köra Angular 2 eller React.

Att välja rätt databas för din applikation

Viktigaste frågorna när du ska välja databashanterare är:

• Hur mycket data räknar du med att lagra när applikationen är mogen?
• Hur många användare räknar du med att behöva hantera samtidigt vid toppbelastning?
• Hur mycket tillgänglighet, skalbarhet, latens, genomflöde och datakonsistens behöver din applikation
• Hur ofta kommer dina databasscheman att ändras?
• Hur ser den geografiska spridningen av dina användare ut?
• Vad har dina data för naturlig ”form”?
• Har din applikation behov av online transaction processing (OLTP), analytiska frågor (OLAP) – eller båda?
• Vilken fördelning av läsningar och skrivningar räknar du med i full drift?
• Behöver databashanterare klara geografiska frågor och / eller fulltextfrågor?
• Vilka programspråk föredrar du?
• Har du en budget? I så fall, täcker den licenser och supportavtal?

Flera av dessa frågor reducerar antalet tänkbara alternativ, men det finns mycket mer att välja på nu än när LAMP-stacken kom. Om du bygger en applikation som ska vara tillgänglig 99,999 procent av tiden för användare i hela världen och med snabb konsistens är det bara ett fåtal databashanterare som duger. Men om din databas ska användas i ett enda land mellan 09.00 och 18.00 fem dagar i veckan, och långsam konsistens kan accepteras, går det bra med nästan vilken databashanterare som helst. Några av dem är mer lätthanterliga för utvecklarna, andra ger högre prestanda för det tänkta användningsområdet.

Och även om LAMP och MEAN var bra lösningar för webbapplikationer när de kom är ingen av dem optimal nu. I stället för att blint satsa på den ena eller den andra bör du gå igenom dina användningsfall och välja en arkitektur som passar din applikation under överskådlig framtid.

SQL eller NoSQL?

När är en relationsdatabas som MySQL rätt val för en ny applikation? Bortsett från det uppenbara, stödet för standard-SQL, så tvingar relationsdatabaser definitionsmässigt in data i ett tabellupplägg med stark typning av fälten. Du slipper datadubblering om du ser till att normalisera ordentligt.

Om du behöver undvika att sakna data kan du förklara fält som NOT NULL när du skapar eller ändrar tabeller. Om du behöver klara geografiska frågor, så som de definieras av Open Geospatial Consortium, erbjuder de flesta relationsdatabaser en robust implementering. Och om du behöver göra fulltextsökningar låter de flesta relationsdatabashanterare dig definiera inverterade index för textfält. De kallas för FULLTEXT-index i MySQL.

Men om du också emellanåt behöver dokument i fritt format så stöder MySQL och många andra relationsdatabashanterare också JSON-data, så som de definieras i RFC 7159. Och om du också vill använda XML-dokument och XPath eller XSLT så klarar de flesta relationsdatabashanterare det också.

Varför skulle man då hellre vilja ha en dokumentdatabas som MongoDB. Om ditt främsta användningsområde förutsätter data i fritt format, fält som ändrar datatyp från dokument till dokument, scheman som förändras med tiden eller nästlade dokument, då är det NoSQL-databashanterare som du behöver. Och om din applikation dessutom är skriven i Javascript kommer dokumentdatabasernas JSON-format att passa perfekt.

Läs också: MySQL och Twitter rensar ut termer som kan väcka anstöt