Ett digitalt biljettsystem kan återspegla en analog motsvarighet relativt bra då ett biljettsy- stem i sig är relativt simplistiskt vilket innebär att respektive metod är lik den andra. Det finns dock aspekter som inte går att digitalisera utan att dessa ändras och beroende på vilket perspektiv man tar kan dessa utgöra för- eller nackdelar.
En möjlig nackdel med ett digitalt system är att studenterna går miste om den sociala upp- levelsen som fysiskt köande innebär. Ännu en möjlig nackdel är att användarna, i detta fall, inte ges möjligheten att säkra biljetter genom att gå till kön tidigt. Huruvida detta är en nack- del eller ej beror dock på vilket perspektiv man tar, ur kundens perspektiv är detta en av de största fördelarna då kunden tror att man, genom att minska den tid studenter spenderar i kö, kan minska deras stress. Ur en students perspektiv kan detta dock vara en nackdel om denne vill garantera biljetter till ett visst evenemang.
Ett digitalt system kommer dock även med stora fördelar där en av de största för studenterna är att inte behöva köa fysiskt. Ett annat är att det underlättar vid försäljning av biljetter då
7.4. Vilka för- och nackdelar har ett digitalt- jämfört med ett fysiskt biljettsystem?
man inte behöver mötas för att utbyta biljetten. Med ett digitalt biljettsystem kan man över- föra biljetten direkt via applikationen och sköta betalning via nätet. Det är även en fördel för arrangörerna då det underlättar för det administrativa. Man kan specificera antal biljetter i systemet och enkelt fördela dessa mellan studentgrupper. Man behöver heller inte skriva ut fysiska biljetter vilket både är bra för miljön och för arrangören då denna sparar både tid och resurser.
användningsområden och analys
av framtiden för SQL jämfört
med NoSQL av André Willquist
A.1
Inledning
Redan 1987 blev SQL en standard för databaser världen över [20]. Sedan dess så har da- tabashanteringssystem baserade på SQL varit marknadsdominerande. När detta dokument skrivs är de fyra mest populära databassystemen fortfarande baserade på SQL [19]. På sena- re tid har dock NoSQL, som står för Not only SQL, ökat väldigt i populäritet och används nu inom många områden där SQL brukade användas. De fyra största databassystemen må vara baserade på SLQ, men utav de tio högst rankade är endast sex SQL och fyra är NoSQL. Vad är dock detta NoSQL? Vad är NoSQLs för och nackdelar? När lämpar sig NoSQL bättre än SQL? Hur ser prestandan hos NoSQL ut jämfört med den hos SQL? Detta är de frågor som ämnas behandlas i denna rapport.
A.1.1
Motivering
Då NoSQL är teknologi som har blivit populär först relativt nyligen är det viktigt att förstå när den är lämplig att använda. Det är även viktigt att undersöka vilka uppoffringar som görs när NoSQL nyttjas istället för SQL för att kunna undvika dyra och onödiga misstag där fel teknologi initialt används. På grund av felaktigt teknikval kan ett dyrt byte behöva utföras senare i projektets livscykel.
A.1.2
Syfte
Rapportens syfte är att undersöka NoSQL och jämföra denna på ett lättöverskådligt sätt med den etablerade standarden SQL. Detta görs primärt relaterat till de bådas användningsområ- den och prestanda, med fokus på vad i ett projekt som bidrar till att bestämma vilken av de två teknikerna som bör användas eller om de möjligtvis kan användas tillsammans.
A.2. Bakgrund
A.1.3
Frågeställningar
Denna rapport ämnar primärt att besvara följande frågeställningar:
1. Vad är de huvudsakliga egenskaper hos ett projekt som talar för att använda en NoSQL databas gentemot att använda en SQL databas?
2. Vilka övergripande tendenser kan ses för den framtida utvecklingen av de två tekniker- na?
A.1.4
Avgränsningar
Detta arbete begränsas i flera avseenden. En av de största begränsningarna som görs är att för NoSQL fokuseras primärt på delteknologierna nyckel-värde lagring och dokumentlag- ring, detta är endast två av de stora kategorierna hos NoSQL men är de som primärt rör den projekttyp som undersöks i detta projekt [30]. I och med denna begränsning görs ytter- ligare en begränsning i form av att i diskussion och slutsatser diskuteras endast en specifik implementation av NoSQL, MongoDB.
En annan avgränsning som görs är att de spekulationer som görs gällande framtiden endast görs som en generell extrapolering av relativt ny funktionalitet som har presenterats i rela- terade rapporter eller hemsidor. Ingen djupare efterforskning görs gällande alla aspekter av nuvarande utvecklingar inom SQL och NoSQL. Denna avgränsning är nödvändig då att ut- föra djupare efterforskningar är ett enormt arbete som är utanför tidsramen för detta projekt. Ytterligare en avgränsning för detta projekt är att teknologin som behandlas i denna rapport är relativt ny och utvecklas fortfarande snabbt, detta betyder att teknologin kan ha ändrats både sen källorna som arbetet baserar sig på skrevs samt sen denna rapport i sig är skriven.
A.2
Bakgrund
Alla dagens mer komplexa dataprogram har behov av att kunna spara data. I allt från spel, till sociala media, till forskningsutrustning blir den mesta mjukvara som idag används värdelös om inte relaterad data sparas. För att effektivt spara, lagra, söka och manipulera denna data utvecklades databaser. En mycket tidig standard för dessa databaser var SQL, som sedan utvecklats till att bli den absolut dominerande standarden på dagens marknad. SQL som står för Structured Query Language är ett språk som primärt refererar till hur data hämtas ur databasen snarare än hur data lagras och struktureras. SQL påverkar dock i hög grad hur den datastruktur som användaren interagerar med ser ut, om än inte hur data lagras på disk. SQL är en standard som många företag, som Oracle och Microsoft, samt många öppna källkods projekt, som PostgreSQL, har baserat sina egna system på [31, 32, 23] .
SQL har använts mycket länge och ytterst framgångsrikt i många olika mjukvaruprojekt. Det är dock så att i och med den explosionsartade utvecklingen på internet och med all den da- ta som har gjorts tillgänglig har nya krav och problem ställts på databassystemen. Ett av de största av dessa krav är att kunna hantera enormt stora datamängder, redan 2014 hade Face- book datavaruhus som lagrade 300 Peta Byte data med ungefär 600 Terra Byte ny data som kom in om dagen [33]. Ett annat krav som ställdes var att kunna hantera ostrukturerad data, till exempel vill man kunna spara Facebook inlägg där man inte vet om det finns bilder, video eller bara text. För nya utvecklare att snabbt kunna komma igång samt att snabbt kunna få
en fungerande produkt är också väldigt viktigt i en värld av prototyper och marknadsföns- ter. Till sist är det också viktigt att kunna distribuera databaserna väl över mer hårdvara för att lätt kunna utvidga kapaciteten vid behov. Under dessa förutsättningar och krav gavs en utmanare till SQL sin chans, NoSQL.
A.3
Teori
I detta stycke kommer den teori som används i denna rapport tas upp. De områden som primärt kommer behandlas är SQL och NoSQL för läsare som inte har någon tidigare känne- dom gällande databaser. Utöver detta så behandlas även för läsarens skull MapReduce som är en teknologi starkt kopplad till NoSQL då den struktur som presenteras för NoSQL passar väldigt väl för en senare applikation av MapReduce på datan.
A.3.1
SQL
SQL är ett så kallat relationsbaserat språk. Detta betyder att mycket av informationen som sparas i databasen sparas i form av relationer i datan snarare än i form av datan i sig. Ett exempel på detta från det gjorda projektet skulle kunna vara relationen att varje biljett som säljs ägs av en användare. Datan i databasen sparas i tabeller där varje tabell motsvarar ett föremål som ska representeras av databasen, varje kolumn representerar ett attribut som fö- remålet antas ha och varje rad representerar en instans av föremålet (se figur A.1).
Figur A.1: Exempel på SQL tabell
För att kunna skapa tabellerna och på så sätt spara datan och dessa relationer i databasen behövs ett schema. Detta definierar vilka tabeller som ska finnas i databasen inklusive attribut och relationer och behöver därför skapas innan någon data sparas. För att databasen ska fungera väl måste schemat vara väl genomtänkt eftersom det kan vara väldigt svårt att ändra på hur det ser ut i efterhand [34]. Att ändra på schemat blir ännu svårare då det redan finns data sparad i databasen eftersom den existerande datan kan behöva modifieras för att passa det nya schemat. Scheman har vissa standarder för hur de bör designas för att de ska bli bra. Att applicera dessa standarder på databasen kallas för att normalisera databasen och kan vara en tidskrävande åtgärd som kan medföra att databasen behöver designas om.
Är schemat dock väl designat så innehåller databasen mycket lättillgänglig information. När ett schema finns ger det användaren tillgång till många kraftfulla verktyg, till exempel låter den användaren på ett enkelt sätt kombinera data från flera olika tabeller. Detta gör att även
A.3. Teori
operationer som vanligtvis kan vara komplicerade kan utföras av programmeraren på en eller ett fåtal rader och kompilatorn kan även se till att uppgiften utförs effektivt.
SQL är dock primärt en definition av språket som används för att hämta och lägga till data till databasen, hur datan lagras på disk och vilken extra funktionalitet som finns varierar myc- ket mellan implementationer av standarden. Olika implementationer kommer ofta i form av databashanteringssystem. Databassystem är den mjukvara som tar hand om databasen i sin helhet, både att spara data på disk och att låta användaren använda SQL eller modifierad SQL för att interagera med databasen. Det finns många databassystem, både de som utveck- las och ägs av företag samt de som har öppen källkod. Det finns de som kostar pengar och de som är gratis, de som håller sig nära SQL standarden och de som tar sig friheter [23, 31, 32]. Trots alla dessa skillnader så finns det många saker som gäller för i stort sett alla SQL databaser. Till exempel har de samtidighetssäkerhet i form av ACID, som presenteras vidare i nästa stycke [22].
A.3.2
ACID
ACID är, som tidigare nämnt, samtidighetssäkerhet som garanteras av nära nog alla SQL im- plementationer. Samtidighetssäkerhet betyder att även när flera användare modifierar data i databasen hålls den i ett konsekvent tillstånd. Ett konsekvent tillstånd betyder att all data i databasen är sådan att tillståndet kunde ha uppkommit på något sätt genom att alla använ- dare hade utfört sina aktiviteter i databasen en i taget istället för alla samtidigt. Ett exempel på detta är biljettköp där man vill undvika att saker som att sälja samma biljett till två perso- ner händer, man vill istället att det för användaren ska se det som en faktisk kö där biljetterna säljs till en person i taget.
Att databasen är samtidighetssäkrad betyder alltså att om det finns fler än en användare beter sig systemet som man skulle förvänta sig som användare. Detta är viktigt i många sammanhang, speciellt då olyckor kan kosta mycket pengar, till exempel hos banker eller i ett biljettsystem. ACID gör det dock svårare att distribuera databasen, detta då för att uppfylla ACID kraven måste alla tabeller alltid vara uppdaterade med all information. Detta betyder mycket kommunikation mellan servrar och att en transaktion på en server ofta kan behöva vänta på en transaktion på en annan server [22, 35].
A.3.3
Samanfattning
Sammanfattningsvis är SQL system på det hela robusta och designade för att i yttersta mån förhindra fel. Det kan dock vara mycket jobb med att sätta upp och underhålla dem när förutsättningar förändras. Det är även inte speciellt effektivt att distribuera SQL databaser över flera servrar.
A.3.4
NoSQL
NoSQL står för Not only SQL och fanns redan så tidigt som i slutet av 1960-talet. Det är dock först på senare tid, i och med den explosionsartade utvecklingen av internet, som NoSQL har fått någon större allmän uppmärksamhet inom datavärlden. NoSQL är egentligen ett samlingsnamn för flera olika sorters databaser, i denna rapport fokuseras endast på två av dessa, nyckel-värdes lagring- samt dokumentlagring databaser. Nyckel-värdes lagringen går ut på att användaren kan lagra data i form av en nyckel och sen ett eller flera dataelement kopplat till denna nyckel. Nyckel-värdes lagring tillåter sen användaren att hämta ut datan
Nyckel: Användare 1 Värde: “André”
Nyckel: Användare 2 Värde: “Daniel”
Figur A.2: Exempel på nyckel värde-lagring
igen baserat på vilken nyckel som anges (se figur A.2). Detta en extremt enkel metod för att lagra data, det är dock även grunden för mer komplexa datalagringsstrukturer, i detta fall dokumentlagring.
A.3.5
Dokumentlagrings baserad NoSQL
Dokumentlagrings baserad NoSQL vad många av de populära NoSQL databaserna använ- der. En av dessa är MongoDB1, vilket även är den som majoriteten av rapporterna funna under denna undersökning handlar om samt den som rapporten kommer fokusera mest på. Mongo DB är det femte mest populära databashanterings systemet i världen och den mest populära NoSQL databasen [19]. Dokument lagring har många likheter med Nyckel-Värdes databassystem med vissa stora skillnader, en av dessa är att dokument baserade databas- system förlitar sig på metadata som lagras samt struktur i datan för att kunna optimera databasoperationer [30]. En annan skillnad, troligtvis den största, är att dokumentlagrings databassystem kan lagra flera olika typer av objekt, till exempel användare och biljetter, där nyckel-värde databaser primärt endast sparar en sorts objekt.
Dokumentlagrings databassystem sparar i stort sett alltid data i någon sorts serialiserbar form, betydande att de kan skrivas i form av textsträngar [36]. Det finns även nyare format som datan kan sparas i, till exempel OSON som presenteras som ett alternativ med högre sök- hastighet än alternativen [37]. De flesta NoSQL systemet ger upp ACID till fördel för BASE vilket står för “Basically Available, Soft state, Eventually consistent”, vilket behandlas vidare i nästa stycke [38].
A.3.6
BASE
BA (Basically available) i BASE betyder att datan ska vara tillgänglig och därför ska datan va- ra replikerad över flera servrar för ökad åtkomlighet. Detta medför att större volymer data sparas totalt i systemet än om bara en kopia av datan sparas vilket kan bli ett problem vid stora datamängder. S (Soft state) i BASE betyder att det inte finns ett globalt tillstånd för al- la servrar utan att tillståndet kan ändras över tid även om ingen ny data läggs till. Detta händer när servrarna delar data med varandra. E (Eventually consistent) är starkt kopplat till S:et och betyder att inte alla noder måste vara fullständigt uppdaterade vid alla tidpunkter utan att det kan finnas olika information på olika servrar. I detta ingår även att om syste- met får vara nog länge utan att mer information läggs till kommer all information till slut spridas till alla servrar [39]. Dessa krav är inte i närheten av lika omfattande som de ACID ställer. Den data användaren får kan vara utdaterad om någon information nyligen lagts till. En annan skillnad är att om servrar kraschar kan nyligen gjorda uppdateringar försvinna ur systemet. Detta ges dock upp för att istället kunna åstadkomma bättre partioneringsmöjlig-
1https://www.mongodb.com/
A.3. Teori
heter. I enlighet med CAP teoremet gäller det att ett system endast väl kan stödja två av tre utav Konsekvens (Consistency), Tillgänglighet (Availability) och Partitionstålighet (Partition Tolerance). ACID stödjer Konsekvens och Tillgänglighet men ger därför upp en del av sin Partitionstålighet. BASE väljer istället att ge upp på Konsekvensen och stödja Tillgänglighet och Partitionstålighet. NoSQL partioneras primärt genom att nycklarna och datan helt enkelt sprids över fler servrar. Den första servern som har information gällande en förfrågan svarar sedan, även om detta betyder att datan som fås är utdaterad [40].
A.3.7
Scheman i NoSQL
En annan stor skillnad mellan NoSQL och SQL är att det inte krävs några fördefinierade scheman i dokumentbaserad NoSQL. Det går istället att börja lagra data direkt, sedan går det även att dynamiskt ändra till exempel vilka attribut som lagras allt eftersom. Detta eliminerar risken att schemat inte är väl designat från början och att det sen blir dyrt och väldigt svårt att ändra som är ett problem i SQL.
NoSQLs schemalösa struktur anses ofta även som en fördel eftersom den tillåter utvecklare börja arbeta med applikationen direkt. Utan schema gäller det dock att databasen inte kan ta hand om relationer mellan olika dataelement som SQL kan göra. Detta gör förvisso att datan som sätts in och tas bort inte behöver kontrolleras så att den följer schemat vilket kan tillåta dessa operationer att utföras snabbare än i en SQL databas men det förlorar den information som i SQL sparas i relationerna. Detta medför att det blir svårare att utföra komplexa analyser av datan, till exempel i datavaruhus som de Facebook eller Google äger. Det finns dock en algoritm kallad MapReduce som passar väldigt väl för den struktur som NoSQL har, den är distribuerad och fungerar på ostrukturerad data, även om även den endast utför simplare dataanalys [41, 42].
A.3.8
Frågesätt för NoSQL
Till skillnad från SQL databser har NoSQL databaser ofta sina egna API som varierar från implementation till implementation. Detta betyder att ingen kunskap om SQL behövs för att utvecklarna ska kunna börja komma igång med databasen. De API som används är ofta dock väldigt grundläggande och stödjer aldrig mer komplicerade och kraftfulla uttryck likt de SQL stödjer. Detta betyder att om användaren vill kombinera data från flera olika tabel- ler för att dra mer komplicerade slutsatser behöver detta göras i applikationen istället för i databasen. Detta bidrar även till problemet med att dra komplicerade slutsatser med NoSQL jämfört med SQL som nämndes i föregående stycket. Mer grundläggande funktionalitet som att filtrera och sortera data finns det dock nästan alltid funktionalitet för i NoSQL implemen- tationers API. [43]
A.3.9
MapReduce
MapReduce började som en teknologi utvecklad och ägd av Google. Den utvecklades för att förbättra parallelliserbarheten hos Googles processer som till exempel skapar sökindexet över internet. Sen introduktionen av MapReduce har många andra implementationer skapats, bå- de såna ägda av företag samt implementationer med öppen källkod som alla får använda och utveckla på. På grund av detta är MapReduce sen sitt skapande blivit ett så kallat varumär- kesord, betydande att det är för generiskt för att kunna tas patent på [41].
På grund av detta räknas det snarare som att MapReduce är ett namn på ett implementations- mönster eller på en algoritm för att skapa en speciell typ av process som är parallelliserbar. Denna process kan beskrivas på olika sätt och kan anses vara tre-, fem- eller sjustegig. Trestegs förklaringen är den som anses lättast att överblicka och är därför den som beskrivs primärt i denna rapport, detta för att göra läsningen lättare då detta inte är rapportens primära fokus. För mer information om ämnet hänvisas läsaren till detta avsnitts källor.
De tre steg som beskrivs i denna rapport är:
• Mappning (Map) • Omflyttning (Shuffle) • Minskning (Reduce)
Det första steget går ut på att en mappning skapas mellan indata och utdata, till exempel om målet är att räkna ord kan en mappning vara från ett ord till ett tal för hur många av det ordet som hittills har funnits. Det andra steget är att denna data som mappats sen flyttas omkring för att relaterad data ska finnas på samma fysiska dator. Det tredje steget gör till sist en sammanställning av all den data som har extraherats från indatan och sen flyttats runt. Detta ger till exempel en slutgiltig räkning av hur många ord som alla de olika servrarna hittade var och en för sig [41].
Den största fördelen med MapReduce är hur väl den går att distribuera, detta är även vad som gör att den passar väl med NoSQL. Då NoSQL redan har distribuerat data över flera servrar är det sen relativt enkelt att göra en mappning från den data till vilken metrik som önskas mätas. Efter detta utförs varje uträkning individuellt av alla servrar för att sedan sam-