NoSQL!787545/... · 2015. 2. 10. · NoSQL databaser i Web 2.0 applikationer hos etablerade företag såsom Google, Amazon och Facebook (Moniruzzaman & Hossain, 2013). Enligt (Parker,

Örebro Universitet

Handelshögskolan - Informatik

Informatik med systemvetenskaplig inriktning C, IK3001, 30 hp

Handledare: Mathias Hatakka

Examinator: Johan Aderud

HT14 / 2015-01-26

NoSQL!

Med rätt att finnas?

Författare:

Linda Nguyen 88 10 24

Jan-Halvard Bergquist 83 02 01

Fredrik Lindgren 90 01 05

Sammanfattning

I och med att det just nu inom databasteknologin pågår en omfattande utveckling för att kunna

hantera informationstillväxten, behövs det en databas som svarar mot de kraven (Atzeni et al.,

2013). Uppsatsen fokuserar på att hitta egenskaper som kan ligga till grund i beslutsfattande

för systemutvecklare eller företagen vid val av databas. Därför är frågeställningarna:

I vilka situationer NoSQL databaser är lämpligt respektive olämpligt att använda?

Vilka för- och nackdelar har NoSQL databaserna?

För att kunna svara på dessa frågeställningar utfördes en systematisk artikelsökning till vår

litteraturstudie. Det första urvalet resulterade i 96 artiklar. Efter individuella granskningar av

artiklarna sorterades 24 artiklar bort vilket resulterade i att 72 artiklar återstod. Under den

gemensamma granskningen av artiklarna från urval 2, exkluderades 14 artiklar vilket

resulterade i de 58 artiklarna som användes i den konceptbaserade mappningen.

Utifrån mappningens resultat kunde slutsatsen att NoSQL databasens fördelar är skalbarhet,

prestanda, tillgänglighet, kostnadseffektivitet, anpassningsbarhet och kapacitet. Nackdelarna

hos NoSQL är: säkerhet, ingen språkstandard, bristande stöd för aggregatfunktioner och

framtagning av affärsdata, support och administration samt kräver hög expertis. Därför är

NoSQL mindre lämpligt i till exempel bank-, handel- eller sjukvårdsverksamheter då NoSQL

databasen inte kan garantera hög säkerhet. Däremot kan NoSQL databaser vara passande för

sökmotorer, sociala nätverk eller webbshoppar eftersom sådana applikationer prioriterar bland

annat skalbarhet och prestanda.

Nyckelord: NoSQL databas, relationsdatabas, skalbarhet, prestanda, säkerhet, kostnad,

kapacitet.

Innehållsförteckning 1 Inledning ............................................................................................................................. 1

1.1 Syfte ............................................................................................................................. 2 1.2 Frågeställning .............................................................................................................. 2 1.3 Avgränsning ................................................................................................................. 2

1.4 Intressenter ................................................................................................................... 3 2 Teori ................................................................................................................................... 3

2.1.1 Big Data ................................................................................................................ 4 2.1.2 NoSQL databasens mognad ................................................................................. 5 2.1.3 Databasschema ..................................................................................................... 6

2.1.4 Skalbarhet ............................................................................................................. 7 2.1.5 ACID .................................................................................................................... 8

2.1.6 BASE .................................................................................................................... 9

3 Metod ................................................................................................................................. 9 3.1 Metodutformning ....................................................................................................... 10

3.1.1 Strategi ............................................................................................................... 10 3.2 Litteraturstudie ........................................................................................................... 11

3.2.1 Dataanalys .......................................................................................................... 11

3.3 Källkritik .................................................................................................................... 14

3.4 Etik ............................................................................................................................. 15 3.5 Begränsningar med studien ....................................................................................... 15

4 Resultat ............................................................................................................................. 16 4.1 Mappning ................................................................................................................... 19

5 Analys ............................................................................................................................... 21

5.1.1 Koncept A, Horisontell skalbarhet ..................................................................... 21

5.1.2 Koncept B, Säkerhet ........................................................................................... 22 5.1.3 Koncept C, Prestanda ......................................................................................... 24 5.1.4 Koncept D, Tillgänglighet .................................................................................. 26

5.1.5 Koncept E, Anpassningsbar ............................................................................... 28 5.1.6 Koncept F, Consistency ...................................................................................... 28

5.1.7 Koncept G, Kapacitet ......................................................................................... 29 5.1.8 Koncept H, Bearbeta data ................................................................................... 31 5.1.9 Koncept I, Expertis ............................................................................................. 33 5.1.10 Koncept J, Support/administration ..................................................................... 33

5.1.11 Koncept K, Språkstandard .................................................................................. 35 5.1.12 Koncept L, Kostnad ............................................................................................ 36

5.2 NoSQL databasernas för- och nackdelar ................................................................... 37 5.2.1 NoSQL databasernas fördelar ............................................................................ 37 5.2.2 NoSQL databasernas nackdelar ......................................................................... 38

6 Diskussion ........................................................................................................................ 38 6.1 När är NoSQL lämplig respektive olämplig? ............................................................ 39

6.2 Framtiden ................................................................................................................... 42 7 Slutsats ............................................................................................................................. 43

7.1 Teorietiska och praktiska bidraget ............................................................................. 44 Referenslista enligt APA .......................................................................................................... 45 Bilagor ...................................................................................................................................... 53

Bilaga 1 ................................................................................................................................ 53 Bilaga 2 ................................................................................................................................ 55

Begreppslista

Begrepp Förklaring

Affärsdata Data som kan användas till att utvinna affärsnyttig information för ett

företag.

Concurrency Term inom datavetenskapen som betyder att flera beräkningar ska

kunna utföras och samarbeta samtidigt (Wikipedia, 2014).

Datalager

En informationssamling av flera källor, så som analyser och modeller.

Samlingen har hjälpmedel och en struktur vilket underlättar för de

personer utan genomgripande IT-kunskaper att läsa informationen

(Svenska datatermgruppen, n.d.).

Deadlocks

När två eller fler uppgifter permanent blockerar varandras utförande. I

fallet med databaser kan det handla om uppdateringar av samma data

som utförs av två eller flera personer samtidigt (Microsoft Technet,

n.d.).

Distribuerad miljö Är ett kluster av sammankopplade datorer via internet eller andra

typer av nätverk för lagring av data (BuissnessDictionary.com, n.d.).

Molnet Innebär att data lagras och hämtas över internet (Helmersson, Dicte,

n.d.). Ett exempel på en sådan tjänst är Microsoft Azure.

Skalbarhet Förmågan hos ett system som kan utöka genomströmningen med hjälp av att

lägga till resurser för att klara den ökade belastningen (Tiwari, 2011).

SQL

Structured Query Language är det frågespråket som är standard för

relationsdatabaser. De olika relationsdatabaserna som existerar har

skillnader i sina frågespråk men de följer alla en gemensam ISO-

standard från 2003, den så kallade SQL:2003 (Padron-McCarthy &

Risch, 2005a).

Web 2.0

Ett samlingsbegrepp för internettjänster, så som bloggar, wikis

(användarberoende internetbaserade uppslagsverk) sociala medier

med mera (BuissnessDictionary.com, n.d.).

NoSQL! Med rätt att finnas?

1

1 Inledning

Just nu sker en omfattande förändring inom databasteknologin. Eftersom allt mer information

blir tillgänglig för en växande mängd människor, måste hanteringen och åtkomsten av data

snabbt utvecklas. I den utvecklingen måste hänsyn tas till vilken typ och volym av data det är

samt de framtida användarna (Atzeni et al., 2013).

Datatillväxten har ökat i en exponentiell hastighet senaste tiden, nästan 90 procent av världens

data genererades de senaste två åren (Zvarevashe & Gotora, 2014). Mycket av det som lagras

är ostrukturerad och semistrukturerad data som exempelvis video, audio, blogginlägg med

mera (Zaki, 2014). Program som inte klarar av marknadsutvecklingen av stor datalagring

kommer snabbt att hamna efter enligt Zaki (2014). Figur 1 visar hur tillväxten av strukturerad,

ostrukturerad och semistrukturerad data har ökat från år 2000 till 2011.

Figur 1. Datatillväxten av ostrukturerad, semistrukturerad och strukturerad data från år 2000 till 2011 (Zaki, 2014)

På grund av detta har förslag på okonventionella sätt för hantering och åtkomst av data

uppkommit, vilket har utmanat och omvärderat de koncept, tekniker och verktyg som

utformades för datalagring under de senaste 40 åren (Atzeni et al., 2013). Eftersom

datatillväxten har blivit så stor att traditionella tekniker såsom relationsdatabasen inte klarar

av den (Zvarevashe & Gotora, 2014), så har nya generationens datahanteringssystem

utvecklats. Det är mest databaser utan relationer vilket går under samlingsnamnet Not only

Structured Query Language (NoSQL) databaser (Atzeni et al., 2013).

Under systemvetenskapliga utbildningen vid Örebro universitet lärs kunskaper om

relationsdatabaser ut dock inte alternativa databastekniker som NoSQL databaser. NoSQL

som databas är ett ungt område då termen dök upp 1998 men utvecklingen tog inte fart förrän


2

runt 2007 (Naheman & Wei, 2013; Hammes, Medero, & Mitchell, 2014). Trots det användes

NoSQL databaser i Web 2.0 applikationer hos etablerade företag såsom Google, Amazon och

Facebook (Moniruzzaman & Hossain, 2013).

Enligt (Parker, Poe & Vrbsky 2013) är det en stor diskussion i databasvärlden om huruvida

NoSQL databaser kommer att ersätta relationsdatabaser. På grund av övergången mot NoSQL

databaser och tillgången till öppen källkod (engelska open source), blir det naturligt att många

utvecklare ställer sig frågan om de ska välja NoSQL databasen eller inte (Parker et al., 2013).

1.1 Syfte

Syftet med denna litteraturstudie är att utreda NoSQL databasernas för- respektive nackdelar

för att sedan kunna avgöra när det är lämpligt eller olämpligt att välja NoSQL databas.

1.2 Frågeställning

Uppsatsen är uppbyggd utifrån utvecklarens och företagens perspektiv. Vilket innebär att

uppsatsen fokuserar på att hitta egenskaper som kan ligga till grund i beslutsfattande för

systemutvecklare eller företagen. Därför är frågeställningarna:

I vilka situationer NoSQL databaser är lämpliga respektive olämpliga att använda?

Vilka för- och nackdelar har NoSQL databaserna?

1.3 Avgränsning

Uppsatsens fokus ligger hos NoSQL, vilket innebär att det inte står något ingående om

relationsdatabasen dock är det svårt att helt undvika att nämna relationsdatabasen då alla

koncept går ut på att göra en jämförelse mellan NoSQL databasen och relationsdatabasen.

Något som inte heller tas upp är de olika subtyperna av NoSQL databaser som finns, till

exempel dokumentlagringsdatabas, graf databas, key-value databas med mera (Tudorica &

Bucur, 2011) eller skillnaderna mellan de 150 olika NoSQL databaserna som idag finns

(Özcan et al., 2014). Orsaken är att uppsatsen riskerar att bli för stor och dessutom blir det

svårt att förhålla sig till en abstrakt nivå. En annan sak som inte heller ligger inom

ämnesområdet är hur en NoSQL databas skapas eller implementeras. Eftersom intresset

endast ligger i att utreda hur NoSQL databasernas egenskaper klarar sig i förhållande till

relationsdatabaserna.


3

Ett perspektiv som skulle vara intressant men som vi1 inte kommer att skriva utifrån, är

slutanvändarens eller utbildningens perspektiv. Utifrån slutanvändarens perspektiv kan det

vara intressant att ta reda på om de märker någon skillnad mellan att använda en applikation

med en NoSQL databas och en applikation med en relationsdatabas. Från

utbildningsperspektivet kan det vara nyttigt att göra en undersökning över vad som lärs ut i

programmeringsutbildningarna och om utbildningen känner till NoSQL.

Ett annat perspektiv som skulle vara intresseväckande är studenternas åsikter om NoSQL

databaser. Där skulle det gå att göra en enkätundersökning för att ta reda på hur många som

känner till NoSQL databaser. Samma undersökning skulle gå att göra med olika företag som

är i kontakt med databaser eller yrkesverksamma personers inom IT2.

1.4 Intressenter

De primära intressenterna av denna uppsats är systemutvecklare och databasadministratörer

som vill veta när det är lämpligt att lagra data i en NoSQL databas. Andra intressenter kan

vara universitet som är intresserade av att utveckla sina utbildningar. Övriga intressenter kan

vara universitetslärare, universitetsstudenter inom datateknik, dataingenjör med mera, delar av

forskarvärlden samt verksamheter som behöver underlag för beslutsfattande.

2 Teori

International Data Corporation gjorde en analys över hur datatillväxten har ökat från 2007 till

2010, vilket visar att datatillväxten 2010 är cirka 25 gånger större än vad det var 2007. Även

samtidiga uppkopplingar har ökat under de senaste decennierna i takt med Web 2.0 och Web

3.0’s framfart (se Figur2) (Tauro & Aravindh, 2012).

Figur 2. Tillväxten av samtidiga uppkopplingar under senaste decennierna (Tauro & Aravindh, 2012).

1 På de platser i denna uppsats som det står vi syftar det på författarnas egna åsikter.

2 IT, Informationsteknik är ett samlingsbegrepp för tillämpningen av datorer och telekommunikation för att

sända, lagra och bearbeta data. Oftast i samband med företag och verksamheter (Henriksson, n.d.).


4

Relationsdatabaser har svårt att hantera den snabba datatillväxten medan NoSQL databaser är

framtagna för att snabbt kunna klara av en utökning av lagringskapaciteten. En anledning till

varför många stora företag som Facebook, Amazon och Google använder NoSQL databaser är

för att det lättare att skala horisontellt med NoSQL databaser i molnet eller till datalager än

med relationsdatabaser (Zahid, Masood, & Shibli, 2014; Tiwari, 2011; Nayak, Poriya, &

Poojary, 2013). Dessutom har relationsdatabaser svårt att hantera semistrukturerad och

ostrukturerad data, då sådana data har få obligatoriska attribut och istället många valfria

(Tauro & Aravindh, 2012).

2.1.1 Big Data

Den mängd data som lagras i terabyte eller petabyte (1 125 899 906 842 624 byte) nivå kallas

för stor data (engelska Big Data). För bearbetning och lagring av Big Data finns två

egenskaper som föredras: skalbarhet och snabba åtkomst till ofantliga mängder data (Pokorný,

2014). Figur 3 visar vad Big Data består av.

Det var inte länge sedan som tusen användare av en applikation ansågs som mycket och

tiotusen användare var extremfall. Idag är ser det annorlunda ut, i och med framväxten av

molntjänster kan applikationer vara tillgängliga alla tider på dygnet året runt och kan på så

sätt globalt stödja många användare samtidigt. Det finns en studie som visar att mer än två

miljarder människor i världen har tillgång till Internetanslutning och tiden som spenderas på

nätet ökar successivt, därför ställs det krav på att tillgängligheten är hög (Zaki, 2014).

Dessutom bearbetas nästan alla affärstransaktioner via nätet och sociala nätverk behandlar,

lagrar och skapar enorma mängder data (Zvarevashe & Gotora, 2014).

Figur 3. Big data storlek och vad som lagras (Zaki, 2014).


5

2.1.2 NoSQL databasens mognad

NoSQL databasernas framfart har genererat stor entusiasm men det finns fortfarande många

hinder att överkomma innan de kan slå igenom hos många verksamheter. Det finns fem

problemområden som NoSQL databaserna måste tackla: mognad, analytisk och

affärsintelligens (engelska Business Intelligence), expertis, administration och support (se

Figur4) (Zvarevashe & Gotora, 2014; Huang & Luo, 2014).

Figur 4. NoSQL databasernas fem främsta utmaningar (Zvarevashe & Gotora, 2014).

I och med att NoSQL databaser inte har funnits lika länge som relationsdatabaser är inte

NoSQL databaserna lika tillförlitliga för företagen att använda (Zvarevashe & Gotora, 2014;

Huang & Luo, 2014). För det mesta är relationsdatabaserna stabila och har många funktioner,

vilket NoSQL databaserna brister i eftersom de flesta NoSQL databaser fortfarande inte är

färdigutvecklade. Att vara i den tekniska framkanten är lockande för många utvecklare men

företag är försiktiga med att testa NoSQL databaser (Zvarevashe & Gotora, 2014). Enda sättet

att uppnå företagets förtroende är att göra flera tester på flera områden (Huang & Luo, 2014).

Mognad är faktorn som NoSQL databaserna endast kan övervinna genom att höja de övriga

faktorerna såsom support. Eftersom support spelar en stor roll i att försäkra företagen om att

det finns ett trovärdigt stöd att tillgå om något går fel. De flesta relationsdatabasleverantörerna

lägger stor vikt på sin support men för NoSQL leverantörerna är det svårare att erbjuda

samma kvalité på supporten då NoSQL företagen brukar vara små med open source projekt

(Zvarevashe & Gotora, 2014; Huang & Luo, 2014).

Eftersom NoSQL databaser har utvecklas för att möta de skalningskrav som Web 2.0 kräver,

så har fokuset legat där. Medan andra områden som att utvinna affärsdata, som kan vara

betydelsefull för verksamhetens utveckling och konkurrenskraftighet har åsidosatts

(Zvarevashe & Gotora, 2014).


6

Designmålet för NoSQL databaserna var att de inte ska behöva administreras men

verkligheten är en annan. Dagens NoSQL databaser kräver expertis och skicklighet för

installation och mycket ansträngning att upprätthålla (Zvarevashe & Gotora, 2014). En annan

aspekt som också påverkar mognaden är säkerhetsbristerna hos NoSQL databaserna

(Mohamed, Altarfi, & Ismail, 2014). Några av de största säkerhetsbristerna NoSQL databaser

har är: bristfällig datakryptering, svag autentisering både mellan klienten och servern samt

sinsemellan servrarna, enkel auktorisation och sårbar för injektion och

överbelastningsattacker (Zvarevashe & Gotora, 2014).

2.1.3 Databasschema

Ett databasschema är en statisk beskrivning av databasen enligt en datamodell. Datamodell i

sin tur är en del av verkligheten som avbildas när en databas designas. Databasschema

innehåller även beskrivningar av vilken data som kan finnas i en databas. I schemat ingår

bland annat vilka fält som finns, vilka värden de kan innehålla och vilka nycklar det finns

(Padron-McCarthy & Risch, 2005a).

NoSQL databasernas scheman har inte strikta relationsscheman som relationsdatabaserna.

Data organiseras därmed inte i tabeller och har inte relationer via vissa kolumner. NoSQL

databasen tillhandahåller istället en mekanism för lagring och hämtning av data i olika former,

exempelvis som nyckel-värde (engelska key-value), graf, dokument med mera som gör

NoSQL databasschemat mer flexibelt och anpassningsbart (Shalini & Dhamodharan, 2014).

På olika sätt är dessa NoSQL databastyper schemalösa (engelska schema-less), exempelvis

key-value databasen sparar data genom att para ihop ett nyckelvärde med datavärdet. Detta

möjliggör att stora sökningar går snabbare att söka igenom än hos relationsdatabasen.

Dokument databaser består av flera uppsättningar av dokument, vilka var och en innehåller

fält av data i ett format som Extensible Markup Language (XML) eller JavaScript Object

Notation (JSON). Detta gör det möjligt för data att lagras på ett schemalöst sätt (Barmpis &

Kolovos, 2012).

Det finns strukturerad, semistrukturerad och ostrukturerad data. Strukturerad data är data som

är organiserad på ett sätt som både datorer och människor kan läsa (Rosengren, 2012),

exempelvis som relationsdatabasens tabeller (Vangie, 2015). Det vill säga att data finns i ett

fält inom en fil som har fördefinierade datatyper (Vangie, 2015). Semistrukturerad data saknar

en formell struktur men separerar ändå semantiska elementet, exempel på semistrukturerad

data är XML och mejl. Ostrukturerad data kan vara av vilken typ som helst, exempelvis som


7

video, audio, bilder med mera, som inte är en del av en databas (Rosengren, 2012). En av de

viktigaste egenskaperna NoSQL databaserna har är att de kan hantera semistrukturerad och

ostrukturerad data (Nance, Losser, Iype, & Harmon, 2013; Parker et al., 2013).

2.1.4 Skalbarhet

Förmågan hos ett system som kan utöka genomströmningen med hjälp av att lägga till

resurser för att klara den ökade belastningen är skalbarhet, vilket kan uppnås antingen via

vertikal skalning eller horisontell skalning (Tiwari, 2011).

I och med att tillväxten av användare ökade, ökade även tillväxten av data vilket förhöjde

belastningen på webbsidorna. Det krävdes mer dataresurser för att kunna klara av den ökade

datatrafiken, därmed måste företagen välja att antingen skala horisontellt eller vertikalt.

Vertikal skalning innebär större maskiner med flera processorer, minnen och disklagring

(Sadalage & Fowlar, 2013).

Andra alternativet är horisontell skalning, vilket innebär att ha många små maskiner i ett

kluster som arbetar som en enhet (Tiwari, 2011; Sadalage & Fowlar, 2013). Horisontell

skalning möjliggör att det totala klustret fortfarande kan fungera fastän en del av klustret är

bortkopplat, vilket ger hög tillförlitlighet (Sadalage & Fowlar, 2013). Figur5 visar skillnaden

mellan horisontell skalning och vertikal skalning vid tillägg av mera lagringsutrymme.

Figur 5. Horisontell skalning versers Vertikal skalning (Monger, Mata-Toledo, & Gupta, 2012).

Vertikal skalning

Traditionellt har vertikal skalning varit det som föredras för att bevara consistency (Tiwari,

2011), vilket gjorde att relationsdatabaser var det föredragna alternativet dock måste


8

replikering3 användas för att kunna hantera relationsdatabaser som är placerade på mer än en

server. Att använda replikering för synkronisering krävdes fragmentering4 av databasen för

vertikalt skalning, vilket innebär att databaser måste delas upp i olika tabeller och den

processen anses vara komplicerad (Pokorny, 2013; Lai, 2009; Couchbase, 2014). I och med

de utmaningar som förknippas med vertikal skalning så har horisontell skalning under de

senaste åren blivit det föredragna strategiska valet för skalning (Tiwari, 2011).

Horisontell skalning

Horisontell skalning innebär att om kapaciteten når sin maxgräns kan ytterligare noder läggas

till i klustret för att klara behovet. Att välja en horisontell skalbarhetsstrategi har blivit

vanligare på grund av tillkomsten av big data och behovet att parallellt kunna bearbeta data

effektivt. Några företag som använder sig av horisontella skalningslösningar är Google, eBay

och Yahoo (Tiwari, 2011). En fördel med horisontell skalning är att den kan klara av höga

transaktionsbelastningar (Sadalage & Fowlar, 2013).

2.1.5 ACID

ACID är ett begrepp som är viktigt inom databasteorin och tillämpas inom relationsdatabaser.

ACID står för: Atomicity, Consistency, Isolation och Durability. Dessa egenskaper ska

garantera att transaktionerna sker tillförlitligt (Padron-McCarthy & Risch, 2005a).

Atomicity eller odelbarhetsegenskapen innebär att transaktionen måste följa allt eller inget

regeln. Det betyder att antingen genomförs hela transaktionen eller så genomförs inget alls.

Om en del av transaktionen misslyckas ska hela transaktionen backas tillbaka till innan

transaktionen påbörjades (Padron-McCarthy & Risch, 2005a; Pritchett, 2008).

Consistency5 eller konsistensbevarande betyder att endast giltig data skrivs till databasen. Om

en transaktion bryter med consistencyregeln måste hela transaktionen backa tillbaka och

databasen återställs till statusen den var innan transaktionen (Padron-McCarthy & Risch,

2005a).

3 Är en automatisk kopiering och delning av information mellan olika resurser. Med andra ord så ligger samma

data på flera diskar och platser. Replikering görs för att öka tillförlitligheten, feltoleransen och tillgängligheten (CS Språkwebb, n.d.). 4 Fragmentering innebär att en tabell delas upp och lagras på olika ställen. Vid horisontell fragmentering

placeras hela rader på olika lagringsplatser. Vid vertikal fragmentering placeras kolumnerna på olika platser (Padron-McCarthy, 2005b). 5 Vi väljer att använda det engelska ordet consistency eftersom det är svårt att hitta en lämplig översättning på

svenska. Consistency betyder ungefär "överrensstämmelse".


9

Isolation eller isolering innebär om olika transaktioner sker samtidigt ska de inte påverka

varandras genomförande (Padron-McCarthy & Risch, 2005a; Pritchett, 2008).

Durability eller hållbarhet säkerställer att transaktioner och dess förändringar som är

fullbordad och avslutade aldrig ska försvinna ur databasen (Padron-McCarthy & Risch,

2005a; Pritchett, 2008).

2.1.6 BASE

BASE är en motsvarighet till ACID. Skillnaden är att BASE accepterar att data i systemet kan

vara inkonsekvent en kort tid efter en förändring, därefter blir systemet så småningom

konsekvent (engelska eventual concistency) medan ACID kräver consistency vid slutet av

varje transaktion (Pritchett, 2008). BASE står för: Basically available, Soft state och

Eventually consistent.

Basically available innebär att systemet verka fungera hela tiden. Soft state betyder att

systemet inte behöver vara i överrensstämmelse jämt och eventual consistency är att det blir

konsekvent vid senare tidpunkt. Då inga uppdateringar sker på ett tag, så kommer alla

uppdateringar att röra sig igenom systemet och alla kopior kommer så småningom att uppnå

consistency (Pritchett, 2008). Exempelvis, för en facebookanvändare A som ska kommentera

ett inlägg av facebookanvändare B ser facebookanvändare A inte alla nya kommentarer som

kan ha tillkommit under tiden facebookanvändare A skriver sitt inlägg. Utan det är efter

facebookanvändare A skicka in sin kommentar som denne kan se att flera andra ha skickats in

före.

3 Metod

Första delen av metodavsnittet består av en översiktlig beskrivning av processen för

litteraturstudien. Därefter följer en mer utförlig beskrivning av varje del i processen.

Först utformades en metodstrategi. Efter metodutformningen påbörjades litteraturstudien där

första sökningen genomfördes. Fas 1 i litteraturstudien bestod av sökningar efter artiklar,

identifiering av koncept samt urval ett och två. Fas 2 bestod av att mappa artiklarna utifrån

koncepten samt resultat och analysskrivning. Under fas 2 utfördes urval tre. Fas 3 bestod av

att sammanfatta och dra slutsatser utifrån analysen (se Fel! Hittar inte referenskälla.6). I

urval ett och två utfördes artikelgranskningen individuellt medan den utfördes gemensamt i

urval tre.


10

Figur 6. Uppsatsens metodprocess.

3.1 Metodutformning

Frågan i vilka situationer som NoSQL databaserna är mest lämpliga att använda, är en fråga

som kan ge vägledande kunskap. Enligt Goldkuhl (2011) resulterar kunskap av vägledande

karaktär i råd om hur man bör gå tillväga beroende på situation, vilket vår litteraturstudie

kommer att göra då den kommer att kunna användas som underlag vid beslutsfattande av

vilken databas man bör välja.

3.1.1 Strategi

Tidigt i projektet är det viktigt att förbereda och utarbeta fram en metodik för arbetet eftersom

det är essentiellt att få den teoretiska och praktiska bakgrunden som är grundstenen för att

svara på frågeställningarna. Det finns olika typer av metoder att använda exempelvis

kvalitativt och/eller kvantitativt. Vi använder inte den kvantitativa metoden då den går ut på

att omvandla information till siffror samt mängder och sedan dra samband mellan olika

variabler, vilket vi inte har behov av (Oates, 2010).

Däremot används kvalitativa metoder att för att uppnå mer nyanserade insikter eftersom

denna typ av metod kan ge ett mer omfattande svar på forskningsfrågan. Detta görs genom att

studera texter istället för siffror, vilket vi har gjort genom systematisk litteraturstudie inriktad

på NoSQL. Valet av att göra en litteraturstudie gjordes utifrån uppsatsens frågeställning och

de resurser som finns tillgängliga (Oates, 2010). Grovt kan arbetsprocessen delas in i delar

som informationssökning, analys och inlärning. Informationssökningen gick ut på att hitta

information om huvudämnet i böcker och artiklar. Sedan analyserades all material för att

skapa en djupare förståelse för att identifiera, syntetisera och värdera ämnesområdet NoSQL.

Detta omfattade sökningar i vetenskapliga databaser med relevanta nyckelord som exempelvis

NoSQL och relationsdatabas med mera (se Bilaga 1). Inlärningen gick ut på att studera böcker


11

och artiklar relevanta för huvudämnet (Oates, 2010). Alla källor granskades noggrant och

validerades. Informationen mappades och en kort sammanfattning skrevs i artikelmallen (se

Figur 8) för varje källa för att göra det lättare att läsa, analysera och bearbeta.

En anledning till varför litteraturstudien valdes är för att den kan ge ett mindre subjektiv

resultat än intervjuer. Enligt Oates (2010) har intervjuundersökningar vanligtvis en agenda

och personen som intervjuar vill oftast rikta in respondenten till att prata om ett specifikt

ämnesområde. En litteraturstudie är en god grund för att utveckla kunskap eftersom den ger

en effektiv översyn. Detta i sin tur underlättar teoriutvecklingen och stänger områden där det

finns stora mängder forskning samt bidrar till att nya forskningsområden upptäcks menar

Webster och Watson (2002). Även Marrelli (2005) nämner att en litteraturstudie är ett

effektivt sätt att utöka sin kunskap och förståelse vilket i sin tur leder till att relevanta

frågeställningar upptäcks i en uppsats.

3.2 Litteraturstudie

I urval 1 valdes de antal artiklar vars abstrakt ansågs lämplig till litteraturstudien. Alla artiklar

vars abstrakter berörde NoSQL och relationsdatabaser valdes ut. Urval 2 är de artiklar som i

första hand ansågs vara lämpliga till mappningen efter granskning av hela artikeln. Urval 3 är

det antalet artiklar som mappningen slutligen landade i (se Figur7). De artiklar som

exkluderades från urvalen, hade antingen inte någon jämförelse mellan relationsdatabasen och

NoSQL databasen eller berörde inte koncepten. Några få källor uteslöts för att de inte var

artiklar som till exempel gästredaktörsintroduktionen ”The CAP Therorem’s Growing

Impact” av Shim (2012). Ett annat exempel är artikeln "A fast and high throuhput SQL Query

System for Big Data" av Zhu, Lie och Xu (2012) som exkluderas på grund av att artikeln inte

handlade om någon jämförelse utan den handlade om systemtester på ett egenskapat program

som baserades på NoSQL databasens arkitektur.

Figur 7. Urvalsprocessen.

3.2.1 Dataanalys

Litteraturstudien inleddes med att söka i artikelbibliotek som Scopus, Google Scholar och

Summon. I de första sökningarna användes bland annat nosql, sql, compare som sökord vilket

resulterade i 31 utvalda artiklar (se Bilaga 1). Därefter påbörjades artikelgranskningen. Efter

96 Urval 1 72 Urval

2 58 Urval 3


12

varje granskad artikel utfördes en sammanställning där artikelns titel, samtliga författare,

tidpunkt för publicering, syfte, resultat och slutsats listades upp i en artikelmall. Även

huvudgranskare samt dess egna tankar och kritik noterades (se Figur).

Figur 8. Förslag på hur artikelmallen kan se ut.

Som Webster och Watson (2002) förespråkar har mappning utförts genom att först läsa

artiklarna sedan identifiera centrala begrepp och koncept för att därefter använda de som

koncept i mappningen. Mappning ger en klarare bild av vad ett stort antal källor säger samt

gör det enkelt att dra slutsatser.

Genom granskning av de första artiklarna kunde det identifieras ett antal nya koncept som

artiklarna tog upp vilket användes som sökord i ytterligare sökningar. Dessa sökningar

resulterade i att ytterligare 53 artiklar valdes ut för granskning. Efter den första

artikelgranskningen kunde vi hitta återkommande egenskaper som togs upp i artiklarna där

NoSQL databaser jämfördes med relationsdatabaser, vilket vi använder som koncept. Dessa

koncept är: horisontell skalning, säkerhet, prestanda, tillgänglighet, anpassningsbar,

consistency och kapacitet. Anledningen till att litteraturstudien är konceptcentrerad är för att

ett författarcentrerat tillvägagångssätt har problem med att åstadkomma en helhetssyn enligt

Webster och Watson (2002) och Oates (2010). Genom att alla artiklar mappats efter de

koncept som identifierats efter granskningen istället för att mappats efter författare blir det

konceptcentrerat (Webster & Watson, 2002).

Med ett konceptcentrerat tillvägagångssätt underlättar det för oss och för läsarna att snabbt

kunna ta del av resultatet på ett översiktligt plan samt att det underlättar vid

analyssammanfattningen. Vi har valt att arbeta utifrån vår konceptmatris, vilket också är vad


13

Webster och Watson (2002) och Oates (2010) rekommenderar för att enkelt och kreativt

presentera våra nyckelkoncept.

Sedan identifierades ytterligare fem egenskaper som också återkom ofta i artiklarna vid

jämförelse mellan NoSQL databaser och relationsdatabaser. Dessa egenskaper valdes att

användas som koncept eftersom vi ansåg att de kunde medföra värde till slutsatsen. De

koncept som tillkom var: bearbeta data, expertis, support/administration, språkstandard och

kostnad. Precis som i enlighet med vad Webster och Watson (2002) säger, för att få mer och

bättre underlag för analys kan nya koncept läggas till och existerande ändras.

I mappningen valdes att utreda huruvida artiklarna ställde sig positivt eller negativt i

respektive koncept som ingick i mappningen. Indirekt går det även svara på i vilken situation

som NoSQL databaserna inte är lämpliga. Underlaget från litteraturstudien svarade även på

vilka fördelar samt nackdelar som NoSQL databaserna har.

Efter att mappningen av de första 84 artiklarna var utförd kunde det utläsas att vissa av

koncepten hade ett litet antal artiklar som berörde NoSQL databaserna i jämförelse med

relationsdatabaserna. Dessa koncept var säkerhet och bearbeta data. Därför utfördes

ytterligare sökningar riktade mot just dessa koncept. Dessa sökningar resulterade i tolv

artiklar, därav resulterade urval 1 i 96 artiklar.

Eftersom inga fler nya koncept påträffades i de sista artiklarna bestämdes det att avsluta

artikelsökningen och därefter påbörjades granskningen av resultatet. Under den individuella

granskningen uteslöts 24 artiklar eftersom de inte berörde koncepten. I urval tre utfördes en

gemensam artikelgranskning vilket resulterade i att artiklar som inte var lämpliga för

mappningen valdes bort. Vid den gemensamma granskningen upptäcktes det även att vissa

artiklars koncept i mappningen inte skulle vara markerade eller var felaktigt märkta. På detta

sätt reducerades antalet artiklar i mappningen ned från 72 stycken till 58. I och med att den

slutgiltiga granskningen utförts gemensamt säkerställer det att alla artiklar som inkluderades i

mappningen verkligen är relevanta.

Utläsning av mappningen

Figur 9 visar ett exempel på hur mappningen ser ut. Om en artikel har notationen (+) i

kolumnen A betyder det att artikeln säger att NoSQL databasen har bättre skalbarhet än

relationsdatabas. Om cellen istället har (-)-notation betyder det att artikeln säger att NoSQL

databasen presterar sämre än relationsdatabasen i den kategorin. Där det finns en (+ & -)


14

betyder det att artikel tycker att NoSQL databasen kan vara bättre än relationsdatabasen i

vissa avseenden i konceptet men sämre i andra.

Figur 9. Mappningsexempel.

3.3 Källkritik

Enligt Avdic (2011) så bör författaren alltid ställa sig kritisk till de källor som de använder sig

av i en undersökning då detta skapar en stark hållbarhet. Vidare nämner Avdic (2011) fyra

kriterier för källkritik:

Äkthet, att källan är den faktiska källan som är given i texten.

Tidssamband, att källan blir mer tveksam ju längre tid det är mellan källan och

händelsen.

Oberoende, att källan ska vara autentisk och ska inte refereras från en annan källa.

Tendensfrihet, innebär att källan kan ge en falsk bild av verkligheten på grund av

personliga åsikter.

Dessa punkter är grunden i bedömningen av våra källor. Eftersom uppsatsen är byggd på en

litteraturstudie är det viktigt att källornas trovärdighet alltid kontrolleras. Det är särskilt viktigt

att veta att källorna har gått igenom någon form av kvalitetsgranskningsprocess.

Alla kurslitteraturer, vetenskapliga skrifter och artiklar som är tillgängliga från ett forsknings-

eller akademisk bibliotek antas ha utvärderats av forskare, förläggare och bibliotekarier samt

är accepterade inom den vetenskapliga kretsen (Elizabeth, 2013).

Följande kriterier utgick vi från vid kvalitetsgranskning av resurserna (Elizabeth, 2013):

Resurslämpligheten kontrollerades genom att säkerställa att material är inriktad på vårt

ämnesområde, att informationen är gällande och aktuellt, att se till att resursen

kommer från rätt tidsperiod, att det finns datum på hemsidan samt att informationen är

tydligt daterad.


15

Auktoritet granskades genom att resursen har en abstrakt, författare med akademiska

meriter, position, status samt uppgifter i form av postadress, yrkesbakgrund,

institutionsinformation och adress.

Publiceringen inspekterades genom att kontrollera att det finns sidhuvud, sidfot eller

en distinkt stämpel som visar att materialet är en del av ett officiellt akademisk eller

vetenskaplig hemsida samt att materialet är utarbetad som en del av författarnas

yrkesuppgifter.

Alla kurslitteraturer värderades enligt följande:

En subjektiv bedömning av hur textkvalitén är, om den är välskriven eller inte.

Kontrollerar författaren, att materialet är publicerad av experter inom ämnet.

3.4 Etik

En etisk aspekt i en litteraturstudie är att sökningen efter vetenskaplig litteratur sker i linje

med utarbetad sökstrategi samt att granskning och sammanställning av resultat genomförts

metodologiskt och systematiskt, vilket vi har förhållit oss till. Vår sökstrategi var att

dokumentera alla våra sökningar, genom att skriva upp alla sökningar som gjordes, vilka

sökord som användes, i vilken sökmotor/artikelbibliotek sökningen utfördes, hur många

resultat varje sökning genererade, vilka begränsningar och sorteringar som gjordes med mera.

Andra saker som dokumenterades var vilka artiklar som hämtades och dess ursprungskälla.

Genom att visa på ett transparent arbetssätt under hela studien kan kravet på uppsatsens

relevans säkerställas.

3.5 Begränsningar med studien

En svaghet i vår studie kan vara vår individuella granskning av artiklarna eftersom den kan ha

bidragit till att relevanta artiklar inte kom med i mappningen. Enligt Marrelli (2005) krävs det

stor skicklighet av granskaren vid analysering av källor samt identifiering av relevant

information. För att förhindra och förebygga att relevanta artiklar exkluderas har vi innan

granskningen diskuterat och kommit överens om vad vi ska titta efter i artiklarna. Under den

individuella granskningsprocessen fanns det alltid möjlighet till att diskutera med varandra

om det skulle uppstå någon fundering. Dessutom användes även artikelmallen för att skriva

ner egna anteckningar och kommentarer om artiklarna. Vi anser att genom att arbeta på detta

sätt minimerar vi risken att exkludera relevanta artiklar.


16

Marrelli (2005) nämner i sin artikel att litteraturstudie är en samling av information av vad

som har hänt och kan därför inte tillhandahålla data om det som sker just nu. Trots att vi vet

att relevanta artiklar kan ha sållats bort på grund av till exempel tidsbegränsningar i

sökningen, så utfördes det för att erhålla så aktuella artiklar som möjligt. Detta val har

möjliggjort att vi har fått den senaste informationen inom NoSQL.

Vi är även medvetna om att det finns andra sökord som kunde ha resulterat i andra artiklar

som skulle kunna ha varit relevanta för vår litteraturstudie. Däremot hade vi vid sista

sökningen tillräckligt med underlag för att svara på våra frågeställningar och valde därmed att

inte söka vidare.

4 Resultat

Detta kapitel börja med att presentera mappningens koncept och sedan redovisas

litteraturstudiens artikelmappning i tabellform.

Koncept A, Horisontell skalning

Horisontell skalbarhet är den skalning som föredras för att kostnadseffektivt kunna lägga till

mera lagringsutrymme. Det är även den strategin som föredras för att tackla dagens

efterfrågan av effektiv och lätthanterlig lagringsutökning (Tiwari, 2011).

I mappningen är det 46 av 58 artiklar som påpekar att NoSQL är bättre än

relationsdatabaserna när det kommer till horisontell skalning. Däremot är det ingen artikel

som påvisar att NoSQL databaser är sämre än relationsdatabaser vid horisontell skalning.

Koncept B, Säkerhet

I och med att NoSQL databasmiljön är distribuerad resulterar detta i stora mängder parallella

anslutningar och beräkningar. Detta förhöjer potentiellt risken att bli attackerad över flera

distribuerande noder vilket gör det komplext att säkra upp ett NoSQL system (Kadebu &

Mapanga, 2014; Osawaru & Ahamed, 2014). Säkerhet är ett stort område med många olika

aspekter men för att förhålla oss på en abstrakt nivå så kommer säkerhet att granskas som en

helhet.

Sexton av mappningens källor ställer sig negativt till NoSQL databasernas säkerhet.

Majoriteten av de artiklar som berör säkerhet säger att NoSQL har sämre säkerhetsegenskaper

än relationsdatabaserna.


17

Koncept C, Prestanda

Konceptet prestanda syftar på hur snabb databasens responstid är vid läsning, lagring,

uppdatering och borttagning. I och med den växande mängden data som Web 2.0 medför

måste även databaserna kunna söka och ändra snabbt vid förfrågningar (Zvarevashe &

Gotora, 2014).

Utifrån mappningen visar det att 39 artiklar ställer sig fördelaktigt till NoSQL databasen i

jämförelse med relationsdatabasen. Enbart en av artiklarna slog fast att NoSQL databasen

presterade sämre än relationsdatabasen.

Koncept D, Tillgänglighet

På grund av att webbapplikationerna behöver klara av ökande användarbelastning måste även

databasens tillgänglighet vara hög. I tillgängligheten ingår även att databasen klarar av att

hantera flera anslutningar samtidigt från olika användare (Tauro & Aravindh, 2012;

Zvarevashe & Gotora, 2014).

Av det som går att utläsa från mappningen är att 22 artiklar bekräftar att NoSQL databasen är

bättre än relationsdatabasen i tillgänglighet.

Koncept E, Anpassningsbar

Med odefinierade scheman är databasen mer flexibel och det blir lättare att anpassa databasen

till applikationen istället för tvärtom. Det utvecklaren ska utgå ifrån är sin applikation för att

designa databasen utseende. Det som gör databasen flexibel är att det går att ändra en del av

databasens upplägg utan att resterande delar av databasen berörs, detta i sin tur resulterar i att

hanteringen av användarens data blir enklare (Abramova, Bernardino, & Furtado, 2014).

Sammanfattningsvis visade mappningen att 17 artiklar sa att NoSQL databasernas

anpassningsbarhet är bättre än relationsdatabasernas. En artikel var negativ till NoSQL

databasernas anpassningsbarhet i förhållande till relationsdatabaserna. Ytterligare en artikel

tog upp negativa aspekter men den tog även upp positiva sidor.

Koncept F, Consistency

Consistency syftat till att garantera att en uppdatering går igenom, att alla ställen med berörd

data och kopior av samma data ska ändras när en förfrågan av förändring, tillägg eller

borttagning inträffar, det vill säga att data i databasen ska vara konsekvent (Strauch, 2012). Vi

har valt att inkludera artiklar oavsett om det är consistency enligt ACID eller BASE.


18

Mappningen visar att en artikel ställer sig fördelaktigt till NoSQL databasen i consistency

jämfört med relationsdatabasen medan 21 visade på motsatsen.

Koncept G, Kapacitet

Enligt oss är kapacitet hur stort datalagringsutrymme databasen kan hantera. Databasen måste

klara av att bearbeta stora mängder data utan att ta för långt tid på sig för att svara på

förfrågan.

Alla 32 källor som berör detta koncept anser att NoSQL databasers förmåga att hantera och

lagra stora mängder data är en fördel jämfört med relationsdatabasers förmåga att göra

detsamma.

Koncept H, Bearbeta data

Bearbeta data handlar om huruvida databasen klarar av att hantera aggregatfunktioner och om

det går att hämta och utläsa statistik om den data som finns i databasen. Enligt (Padron-

McCarthy, 2005b) är aggregatfunktioner i relationsdatabaserna att arbeta med data för att

bland annat räkna ut till exempel summa, maximum eller minimum ur en tabell.

Att hämta ut affärsdata ur en databas är något som exempelvis ett företag kan vara intresserad

av att göra. Affärsdata är till för att beskriva innehållet och/eller strukturen ur ett visst

perspektiv för en viss samling data. Affärsdata är den data som bland annat säger hur många

gånger som en viss person har loggat in i databasen. Vilken data som har hämtats, lagrats,

ändrats med mera (Zvarevashe & Gotora, 2014).

Majoriteten av de källor som explicit tar upp detta koncept anser att NoSQL databasernas

förmåga att bearbeta data är negativt jämfört med relationsdatabasernas förmåga att göra

detsamma. Endast tre källor är positiva enligt mappningen.

Koncept I, Expertis

Expertis syftar till att redogöra för hur pass hög kompetens en utvecklare behöver ha för att

kunna hantera en NoSQL databas jämfört med att hantera en relationsdatabas. Eftersom

NoSQL fortfarande är relativt nytt jämfört med relationsdatabaser så kommer det att ställas

högre krav på utvecklarna (Hammes et al., 2014).

Av de artiklar som tar upp konceptet är nio artiklar negativt inställda. I och med att NoSQL

kräver hög expertis, är det inte att rekommendera om utvecklaren inte har tid att sätta sig in i

ämnet/databasen. Två artiklar var positivt inställda.


19

Koncept J, Support och administration

Support enligt oss syftar till att redogöra för hur supportstödet för NoSQL databaser är i

jämförelse med relationsdatabaserna och administration syftar till hur förvaltning och

underhåll hos NoSQL databaserna är i jämförelse med relationsdatabaserna.

Mappningen visar två artiklar som är positivt inställda, elva artiklar som är negativt inställda

och två artiklar är både positivt och negativt inställda till NoSQL databasers support och

administrationsstöd i förhållande till relationsdatabaserna.

Koncept K, Språkstandard

Med konceptet språkstandard syftar vi på huruvida artiklarna anser att det är för- och nackdel

med att ha en språkstandard samt om NoSQL databaserna har en gemensam språkstandard

eller inte.

Som visas i mappningen är 17 av artiklarna negativt inställda till att NoSQL inte har ett

standardiserat frågespråk och tre var positivt inställda i jämförelse med relationsdatabaserna.

Däremot tog en artikel upp både negativa och positiva aspekter.

Koncept L, Kostnad

Kostnad syftar till att redogöra för hur kostnadseffektiv NoSQL databaserna är i jämförelse

med relationsdatabaserna. Nu när dagens databaser behöver kunna hantera mer och mer data

så kommer företag i framtiden att behöva utöka sina databaser. Detta innebär att mer pengar

behöver spenderas, därför är kostnaden en viktig faktor att ta ställning till vid val av databas

(Manoj, 2014; Hammes et al., 2014; Han, E, Le, & Du, 2011).

Det som går att utläsa ifrån mappningen är att 18 artiklar säger att NoSQL databaserna

jämfört med relationsdatabaserna har bättre kostnadseffektivitet, en artikel tar upp båda

negativa och positiva aspekter och ingen artikel ställer sig negativ i detta koncept.

4.1 Mappning

Tabell 1 visar alla artiklar som granskades under litteraturstudien och vilka koncept som togs

upp i artikeln. Notationen i tabellen visar om artikeln ställer sig fördelaktigt eller inte till

NoSQL databasen i förhållande till relationsdatabasen.


20

Tabell 1. Resultatet av artikelmappningen.

Koncept A B C D E F G H I J K L

ArtikelNr

1 +

+

- +

2

+

3 + - + +

+ - - -

4 +

+&- -

-

-

5 +

+ +

+

6

-

-

7 +

+

+

-

8

+

+

+ -

+

9 + - +

-

- -

10 +

+

+

+

+

+

11 + - +

+

+

- -

+

12 +

+ - + + -

13 +

+

+ -

+ & - -

14 +

+ + +

+

15

-

16 +

+

+

+

17 +

+ +

-

-

18 + - + + +

+

19 +

+ +

- +

+ +

20 + - +

-

+

21 + - + + + -

- + & - +

22 +

+

+ - +

- - + & - +

23 +

+

24

+

- -

- - - -

25 + -

+ +

+

26 +

+

27 +

+ +

+ -

28

-

- +

-

29 +

+

+

30 +

+

+ - - - - +

31 +

+

32

-

-

- - - -

33 +

+ + -

- -

+

34 +

+

- + -

+

35 + - +

+

+

36 +

+

+

37 +

+

+

- - - +

38 +

+

39 + +

+

-

+

+ & -

40 +

+ +

-

41 +

+

42 + -

+

43 + - + + + - +

44 + - + + + - + +

45 +

+ +

+


21

46 + - + +

+

47 +

+ +

+

+

48 + - +

+

+

+

+

49 +

+ +

+

50 +

+

-

51 +

+ +

-

52 +

+

- +

53

-

54 +

+

+

+

55 +

+

- +

- +

56 +

+

- +

-

-

57 + - +

+

+

58

+

-

5 Analys

Nedan analyseras de artiklar som berör respektive koncept. Sist kommer en sammanfattning

av alla koncepten indelad i för- och nackdel.

5.1.1 Koncept A, Horisontell skalbarhet

Skalbarhet är motivationen bakom att NoSQL började utvecklas i större skala, då data i

NoSQL databaser är enklare att flytta runt mellan olika servrar än i en relationsdatabas

(Hammes et al., 2014). Anledningen till varför relationsdatabaser har sämre skalbarhet är på

grund av att relationsdatabaser kan ha flera relationer mellan olika tabeller (Zvarevashe &

Gotora, 2014).

Även Thantriwatte och Keppetiyagama (2011) skriver att NoSQL utvecklades för att ge ett

nytt sätt att hantera data. Samtidigt som NoSQL databaser fyller några av de brister

relationsdatabaser har, exempelvis som att relationsdatabaser blir ineffektiva vid hantering av

stora mängder data (Thantriwatte & Keppetiyagama, 2011). Författaren Pokorny (2013)

instämmer också i att relationsdatabaser inte klara av skalbarheten då många webbsidor

kräver mer kapacitet och bättre genomströmning i takt med att antalet användare ökar.

Däremot är NoSQL bättre anpassad för att snabbt kunna skala horisontellt och hantera

tillgängligheten (Zahid et al., 2014). Genom att kostnaden för NoSQL-systemets skalning är

linjärt med antalet användare och servrar, så blir det mer kostnads- och prestandaeffektivt (se

Figur 20). Vilket relationsdatabaser har svårt att tillhandahålla (Huang & Luo, 2014; Pokorny,

2013; Zaki, 2014).


22

Figur 20. För att relationsdatabaser ska kunna stödja fler användare eller lagra mer data, behöver de lägga till mera

processorer, minne och diskutrymme. NoSQL databaser tillhandahåller en mer skalbar, prestanda- och

kostnadseffektiv linjär strategi än relationsdatabaser (Zaki, 2014).

Med NoSQL är det möjligt att partitionera data utan att påverka databasen som helhet, vilket i

sin tur underlättar horisontell skalning (Hammes et al., 2014). I och med att horisontell

skalning innebär att data distribueras mellan olika servrar, så blir det svårare och mer

komplicerat att utföra join-operationer i en relationsdatabas (Pokorny, 2013; Bonnet, Laurent,

Sala, Laurent, & Sicard, 2011).

En anledning till varför det behövs ett smidigt sätt att expandera lagringskapaciteten är att

ostrukturerad data tar mer plats än strukturerad data i databasen. Eftersom att NoSQL

databaser kan hantera ostrukturerad data, något relationsdatabaser har svårt att göra är det

bättre att använda NoSQL databaser i fall kravet är att kunna lagra stora mängder

ostrukturerad data (Tauro & Aravindh, 2012; Nance et al., 2013).

Det som går att utläsa utifrån mappningen är att NoSQL är att föredra i situationer då det

krävs horisontell skalning.

5.1.2 Koncept B, Säkerhet

I och med att NoSQL databasmiljön är distribuerande, resulterar detta i stora mängder

parallella anslutningar och beräkningar. Detta medför en ökad potentiell attackyta över flera

distribuerande noder vilket gör det är komplext att säkra upp ett NoSQL system (Kadebu &

Mapanga, 2014; Osawaru & Ahamed, 2014).

Medan relationsdatabasens säkerhet är hög med decennier av utförliga studier, så har NoSQL

inte granskats lika noggrant. NoSQL brister i säkerhetsegenskaper fastän säkerheten är en av

de viktigaste egenskaperna när det gäller horisontell skalning. Eftersom NoSQL är designad


23

för att tillhandahålla hög tillgänglighet och är skalbar för stora mängder data, så borde

säkerheten enligt Enescu (n.d.) prioriteras högre. Däremot så har enligt (Mohamed, Altarfi, &

Ismail, 2014) NoSQL databasernas säkerhetsaspekter åsidosatts eftersom NoSQL var

framtagen med målet att lösa big data lagringsproblem samt öka prestandan.

Jämfört med relationsdatabasens säkerhetsmekanismer har NoSQL ett magert säkerhetslager,

därför förlitar sig NoSQL system på extern säkerhet. Utvecklare som använder NoSQL skapar

säkerhet i deras mellanprogram för att det inte går att upprätthålla säkerheten i NoSQL

databasen (Osawaru & Ahamed, 2014; Mohamed et al., 2014; Zaki, 2014).

Bland NoSQL-systemens säkerhetsaspekter brister NoSQL i till exempel datakryptering, svag

autentisering, sårbarhet vid SQL injektioner, överbelastningsattacker samt behörighetskontroll

(Nance et al., 2013; Osawaru & Ahamed, 2014; Zvarevashe & Gotora, 2014; Kadebu &

Mapanga, 2014; Zaki, 2014).

Datakryptering

För att kunna hålla data konfidentiellt måste applikationer i ett databassystem använda sig av

datakryptering men eftersom data i NoSQL databasen lagras öppet går det inte att applicera

kryptering (Zahid et al., 2014; Mohamed et al., 2014). Relationsdatabaser har ett mer

välutvecklat datakrypteringsstöd än NoSQL databaser. Vilket är bekymmersamt hos NoSQL

databaser på grund av att de saknar datakrypteringsmekanismer (Kadebu & Mapanga, 2013;

Nance et al., 2013). Dessutom bör inte data lagras som ren text i databasen på grund av att

NoSQL har svaga autentiserings- och auktoriseringsmetoder (Osawaru & Ahamed, 2014).

Autentisering

Autentisering är verifieringsprocessen när en användare vill ha åtkomst till en resurs, databas

eller applikation (Zahid et al., 2014; Kadebu & Mapanga, 2014), vilket alla relationsdatabaser

i grunden har (Mohamed et al., 2014). I relationsdatabaser finns möjligheten att välja vilken

autentiseringsmekanism som ska vara aktiv. Till skillnad från relationsdatabaser kommer de

flesta NoSQL databaser utan några autentiseringsmekanismer men det finns externa

funktioner som utför detta (Mohamed et al., 2014). Även Osawaru och Ahamed (2014)

nämner att olika NoSQL databaser har olika autentiseringstekniker som oftast erbjuds på

högre nivåer i lagerarkitekturen. Det finns vissa NoSQL databaser som kan tillämpa

autentiseringsmekanismer på enskilda noder men har svårt att genomdriva det till samtliga

noder i ett kluster (Zaki, 2014).


24

Injektioner

Det finns många olika injektionstekniker såsom SQL injektion, schema injektion, REST

injektion med mera, som på ett otillåtet sätt kan komma åt databasen för skadliga aktiviteter.

Genom injektionsattacker kan valfri data läggas till i databasen vilket kan göra databasen

otillgänglig och korrumpera databasens innehåll. Eftersom NoSQL använder sig av

mekanismer som är starkt sammankopplade så är NoSQL databaser känsligare för

injektionsattacker (Osawaru & Ahamed, 2014; Zaki, 2014). Däremot är NoSQL databaser i

molnmiljö inte berörda av SQL injektioner eftersom de inte använder sig av

relationsdatabasernas frågespråk (Hammes et al., 2014).

Som det går att utläsa utifrån mappningen är NoSQL inte lämplig i situationer där säkerheten

har hög prioritet.

5.1.3 Koncept C, Prestanda

Relationsdatabaser är mer benägna att få deadlocks i takt med att mängden data ökar samt att

de också har svårt att hantera flera operationer samtidigt (engelska concurrency). Vilket leder

till att mängden läs- och skrivförfrågningar minskar. För att relationsdatabaser ska få snabbare

responstid kan de enbart hantera ett fåtal parallella operationer samtidigt (Zvarevashe &

Gotora, 2014).

I och med att Web 2.0 efterfrågar snabb responstid med hög concurrency så uppfyller inte

relationsdatabasen det kravet (Zvarevashe & Gotora, 2014). För att öka hastigheten på

förfrågningar, började NoSQL databaser att använda flyktigt minne6. Genom att använda det

flyktiga minnet istället för att läsa direkt från hårddisken ökas prestandan och minskar

exekveringstiden för varje förfrågan (Abramova et al., 2014).

I artikeln av Barmpis och Kolovos (2012) visar resultatet från deras experiment att NoSQL

databaserna presterade snabbare i prestanda än relationsdatabasen. För att NoSQL ska kunna

uppnå hög prestanda och skalbarhet har de fått ge avkall på säkerhet, consistency och

funktionalitet (Osawaru & Ahamed, 2014; Kadebu & Mapanga, 2014; Wayner, 2012; Zahid

et al., 2014).

Läsbarhet

I ett prestandatest där läsbarhetsbelastningen testades visar resultatet att relationsdatabasen

klarade sig nästan lika bra som NoSQL databasen (Tudorica & Bucur, 2011; Huang & Luo,

6 Random Access Memory (RAM-minne) eller cache minne.


25

2014; Lungu & Tudorica, 2013). Anledningen till att NoSQL läser snabbare än

relationsdatabasen är för att relationsdatabasen söker igenom hela databasen något som

NoSQL inte gör på grund av key-value lagring (Sharma & Soni, 2014; Moniruzzaman &

Hossain, 2013).

En annan studie visar på att både relationsdatabasen och NoSQL databasen fungerar

tillfredställande men vid hanteringen av strukturerade frågor som exempelvis att gå igenom

databasen och räkna antalet nådda noder. Så var NoSQL databasen i vissa fall tio gånger

snabbare än relationsdatabasen (Vicknair et al., 2010). Även (Parker et al., 2013) påvisade i

sitt läsbarhetsexperiment att NoSQL överlag klarade sig tre gånger bättre än

relationsdatabasen. Däremot i en annan studie av Li och Manoharan (2013) visar deras

experiment på motsatsen, att relationsdatabasen presterar bättre än två av fem NoSQL

databaser i läsbarhet. Eftersom det finns många olika variationer av NoSQL databaser så finns

det även NoSQL databaser som relationsdatabasen kan prestera bättre respektive sämre än (Li

& Manoharan, 2013). Ytterligare en artikel säger att NoSQL databasen de testade presterade

betydligt långsammare än relationsdatabasen vid läsning (Manoj, 2014).

Skrivbarhet

Tre artiklar visade inga större skillnader mellan relationsdatabaser och NoSQL databaser när

det kommer till responstiden vid skrivoperationer (engelska write-operation). I likhet med

läsbarhetstesterna finns det olika NoSQL databaser, vissa presterar sämre och andra bättre än

relationsdatabaser beroende på vilken den jämförs med (Li & Manoharan, 2013; Parker et al.,

2013; van der Veen, van der Waaij, & Meijer, 2012).

Fyra andra artiklar visar att NoSQL databaser är snabbare i responstid än relationsdatabasen

vid skrivningsoperationer. I artikeln av Tudorica och Bucur (2011) testades två

relationsdatabaser mot två NoSQL databaser. Resultaten visar att relationsdatabaserna blir

långsammare och slutar att svarar vid mer än 7000 operationer samtidigt. Responstiden blir så

långa att de inte skulle vara acceptabla i verkliga situationer (Tudorica & Bucur, 2011).

Resultatet stärks av Huang och Luo (2014).

I artikel av Manoj (2014) visade skrivbarhetsexperimentet att NoSQL databasen var lite

snabbare då den klarade 2000 inserts7 per sekund än relationsdatabasen som klarade 1500

insert per sekund. En anledning till att en relationsdatabas kräver längre tid för att klara

7 Inskrivningar av data i databasen.


26

skrivoperationer är för att skrivoperationer är den enda operationen som direkt använder sig

av hårddisken (Lungu & Tudorica, 2013).

Uppdatering och borttagning

(Parker et al., 2013) testade tre olika uppdateringsoperationer mellan en relationsdatabas och

en NoSQL databas. Först testades att uppdatera uppgifter om en användare i en icke indexerad

databas via förnamnet. Resultatet visade att NoSQL databasen presterade långsammare än

relationsdatabasen men två av testerna visade att NoSQL databasen presterade bättre än

relationsdatabasen på grund av att uppdateringen skedde via id.

Li och Manoharan (2013) jämförde sex stycken NoSQL databaser mot en relationsdatabas i

radera-operationer (engelska delete operation). Resultaten visade att två av NoSQL

databaserna har bättre responstid än relationsdatabasen medan resterande presterade sämre.

En av artiklarna i mappningen anser att, även om NoSQL har utvecklats mycket på sistone är

deras prestanda fortfarande sämre än relationsdatabasens. Relationsdatabasen var i deras

experiment överlag snabbare än NoSQL databaserna. Relationsdatabasens frågespråk

möjliggör för systemet att prestera och köras mer effektivt än NoSQL. Även med hjälp av

MapReduce program8 kunde inte NoSQL databaserna öka i prestanda. Relationsdatabasen

kunde också hantera flera kunder samtidigt med bättre responstid än NoSQL databasen

(Floratou, Teletia, DeWitt, Patel, & Zhang, 2012).

Utifrån vår mappning är NoSQL databasen att föredra i de situationer där prestanda är ett

viktigt krav samt då läs- och skrivbarhet är det som används mest.

5.1.4 Koncept D, Tillgänglighet

Web 2.0 orsakade att nya applikationer som ska kunna lagra och hantera stora mängder med

data skapades. Dessa applikationer behöver mer tillgänglighet än vad relationsdatabaserna kan

tillhandahålla. Eftersom interaktiva webbapplikationer kräver hög tillgänglighet på databasen

kostar det pengar när applikationer ligger nere (Mohamed et al., 2014; Kadebu & Mapanga,

2013). Ett annat problem är concurrency, då mer och mer information hämtas från nätet

kräver det bra anslutningar för användaren att nå data (Tauro & Aravindh, 2012; Zvarevashe

& Gotora, 2014).

8 Är en programmeringsmodell och tillhörande implementation för hantering av stora mängder data (Dean &

Gnemawat, 2008).


27

För att kunna upprätthålla hög tillgänglighet är det att rekommendera att lägga databasen i ett

distribuerat nätverk, så kallat kluster. Detta medför att en nod enkelt kan plockas ut ur klustret

för exempelvis underhåll utan att påverka databasen. På grund av detta har ett ökat antal

företag anammat olika typer av NoSQL databaser till sina verksamheter (Mohamed et al.,

2014; Kadebu & Mapanga, 2013). I takt med att datamängden ökar får relationsdatabaserna

problem med prestandan, något som är relaterat till tillgängligheten. Detta är ytterligare en

anledning till att NoSQL databaserna skapades (Sharma & Soni, 2014). Relationsdatabaserna

kan inte garantera tillgängligheten, NoSQL databaserna kan däremot göra detta delvis genom

att offra säkerhet och consistency (Sharma & Soni, 2014; Zahid et al., 2014; Mohamed et al.,

2014).

För att kunna tillhandahålla hög tillgänglighet så är många systemutvecklare villig att överge

ACID egenskaperna vid transaktioner. Detta för att många användare tolererar att

applikationen inte alltid visar den senaste informationen. Till exempel att användaren inte

upptäcker att varan de ha lagt i varukorgen är slutsåld förrän de genomför köpet (Cattell,

2011). Däremot anser (Mohamed et al., 2014) att NoSQL passar bäst till molndatabaser

eftersom alla egenskaper NoSQL har är önskvärda för databaser i molnet. I och med att

molndatabaserna inte är kompatibla med ACID egenskaperna medför det att molndatabaserna

får en förbättrad tillgänglighet, skalbarhet, prestanda och flexibilitet.

En anledning till att tillämpa NoSQL är för att den har flexibel arkitektur och kapacitet för

stora datamängder medan relationsdatabaser är svårare att skala horisontellt samt inte passar

till molnapplikationer. NoSQL har blivit populärt för dess höga tillgänglighet, tillförlitlighet

och skalbarhet (Zahid et al., 2014; Shalini & Dhamodharan, 2014; Gudivada, Rao, &

Raghavan, 2014; Mohamed et al., 2014).

Enligt (Hammes et al., 2014) samt (Rith, Lehmayr, & Meyer-Wegener, 2014) kan

tillgängligheten vara den viktigaste NoSQL implementationen. NoSQL databasen är utformad

för att stödja tillgängligheten av data för att tillfredsställa slutanvändaren och är inte skapad

för att samla in affärsdata till företag. Detta sker genom att skapa redundanta replikationer av

data i databasen för att försäkra snabbare kommunikation (Indrawan-Santiago, 2012).

Det som går att utläsa utifrån mappningen är att NoSQL databasen är lämplig om

tillgänglighet är en viktig fråga för databasutvecklaren.


28

5.1.5 Koncept E, Anpassningsbar

Flera av de artiklarna som ställer sig positivt säger att NoSQL databaser är mer flexibla och

anpassningsbara än vad relationsdatabaserna är. På grund av att de inte har strikta

fördefinierade datamodeller eller scheman, till skillnad från relationsdatabaserna där schemat

måste vara definierat före datalagringen. På grund av att möjligheten till användning av SQL

frågespråket inte finns i NoSQL databaserna leder det till enklare hämtning och lagring av

data oavsett datastruktur (Abramova et al., 2014; Mohamed et al., 2014; Dykstra, 2012;

Bonnet et al., 2011). Dessutom kan dataformatet i NoSQL databaser ändras när som helst utan

att databasen skadas. Vilket gör databaserna flexibla som i sin tur leder till att webbtjänsterna

enkelt kan hantera användarnas data (Huang & Luo, 2014).

Wayner (2012) ifrågasätter i sin artikel en av NoSQL databasernas fördelar. Nämligen

NoSQL databasens flexibilitet när det kommer till schema. Han menar att flexibilitet är bra

eftersom den kan snabba upp utvecklingsprocessen om den används rätt. Det han kritiserar är

att friheten leder till att varje team som hanterar databasen sätter sina egna nycklar vilket kan

resultera i att olika team sätter in samma data på olika sätt. Exempelvis ett fält där

användarnamnet ska stå kan nyckeln som identifierar data heta olika beroende på vilken

utvecklare som döper nyckeln (Wayner, 2012). Det kan till exempel bli: "användarnamn", "a-

namn", "anv" och så vidare. I och med att utvecklaren kan designa NoSQL databasen som han

eller hon vill kan det i längden förhindra databasens anpassningsförmåga och skalbarhet

menar (Özcan et al., 2014).

Om anpassningsbarhet är något som eftersträvas vid val av databas så är NoSQL databaser att

föredra.

5.1.6 Koncept F, Consistency

När NoSQL återintroducerades var det fokus på att kunna hantera stora mängder data och

skalbarhet dock på bekostnad av consistency och säkerhet (Zahid et al., 2014; Kadebu &

Mapanga, 2014). Enligt (Özcan et al., 2014), (Nayak et al., 2013) samt Sharma och Soni

(2014) offrar NoSQL databaserna ACID egenskaperna för att uppnå hög skalbarhet och

tillgänglighet.

De flesta av NoSQL databaserna stödjer enbart eventual consistency och förskjuter

transaktionshanteringen till applikationslagret. Med eventual consistency garanteras inte

användaren konsekvent resultat vid en given tidpunkt eftersom varje nod inte kan vara helt


29

synkroniserad med den noden som håller den senaste uppdateringen av data (Osawaru &

Ahamed, 2014; Pokorny, 2013). Vid till exempel utformningen av ett bankomatsystem är inte

eventual consistency att föredra men i praktiken menar Pokorny (2013) att tillgängligheten

övertrumfar consistency dock med en viss risk.

Enligt (Hammes et al., 2014) måste en transaktion bli framgångsrikt slutförd innan ändringar

kan åtas till huvuddatabasen, sedan kan huvuddatabasen uppdatera resterande dubbletter om

det finns. Problemet är enligt Wayner (2012) är att NoSQL gör det svårt att hålla de olika

posterna konsekventa. Det finns inga transaktioner som kan se till att alla förändringar i flera

tabeller görs samtidigt och om ett fel skulle uppstå kan hela databasen bli inkonsekvent. I

artikeln av Tudorica och Bucur (2011) visar deras kvalitativa undersökning av

relationsdatabasen och NoSQL databasen att databaserna erbjuder likvärdiga egenskaper

förutom i consistency. Relationsdatabasen var den enda i undersökningen som uppfyllde

ACID egenskaperna fullt ut. Det finns NoSQL databaser som erbjuder transaktionskontroll

över data skriven till en nod och låter utvecklaren bestämma consistency på valfritt antal

noder. Ett flertal NoSQL databaser experimenterar med att lägga till denna typ av

transaktionskontrollsfunktioner. För att få perfekt consistency måste alla noder vara

uppdaterade med den senaste versionen av data, vilket kan ta lång tid (Wayner, 2012).

Enligt (Bonnet et al., 2011) gör NoSQL ett val att försvaga consistency för att förbättra

tillgänglighet och prestanda. Vid användning av ett NoSQL databassystem måste utvecklaren

tänka på att consistency inte är den viktigaste egenskapen. Om databasmodellen inte kräver

stark consistency är det inte heller ett relevant problem vilket gör att NoSQL databasen blir

det logiska valet.

Nyckeln till att lösa problemet med den ökade belastningen av nätverkstrafiken är att använda

cache eller att garantera data consistency och på så sätt minskar tycket på databasservern.

Även om relationsdatabaserna kan vara distribuerade så är NoSQL databaser framför allt

bättre än relationsdatabaser på att hantera data consistency i en distribuerad miljö (Xiang,

Hou, & Zhou, 2010).

Fel! Hittar inte referenskälla.Är consistency viktigt för databasen är inte NoSQL databaser

det lämpliga valet.


30

5.1.7 Koncept G, Kapacitet

Google's BigTable var det som stimulerade populariteten för NoSQL databaserna och det som

bäst visade på bristerna i relationsdatabasernas skalbarhet. Anledningen till att Google

behövde en ny typ av databas var på grund av deras evigt växande mängd med

semistrukturerad data som var distribuerade i olika datacenter världen över (Indrawan-

Santiago, 2012).

Det finns ett behov av att kunna hantera big data inom bland annat de kommersiella områdena

och vid hantering av stora mängder data i en relationsdatabas blir operationer som join

ohanterliga (Indrawan-Santiago, 2012). Applikationer som sociala nätverkstjänster (SNS) och

sökmotorer måste kunna tillgodose effektiv datalagring på petabytenivå samtidigt som de ska

kunna bemöta behovet av miljontals datatrafikanter (Zvarevashe & Gotora, 2014; Han et al.,

2011), vilket dagens relationsdatabaser inte har möjlighet att göra (Zvarevashe & Gotora,

2014; Tauro & Aravindh, 2012). NoSQL databasen togs fram för att bemöta lagringsbehovet

av stora mängder datavolymer i key-value lagring (Abramova et al., 2014).

För att kunna lagra stora datavolymer fordras servrar med större kapacitet och

skalningsmöjligheter vilket är en begränsning för relationsdatabaserna (Abramova et al.,

2014). Eftersom relationsdatabaserna är mer lämpade för vertikal skalning så kan det vara

kostsamt att uppgradera kapaciteten, vilket gör att relationsdatabaserna är olämplig vid

lagring av stora mängder data (Xiang et al., 2010).

Den främsta fördelen med NoSQL databaserna är att de kan hantera ostrukturerad data, därför

används NoSQL databaserna i SNS och big databearbetning (Sharma & Soni, 2014; Xiang et

al., 2010). Det är därför många verksamheter som lagrar stora mängder ostrukturerad data

numera allt oftare använder sig av NoSQL databaser (Moniruzzaman & Hossain, 2013; Zaki,

2014). NoSQL databasen passar att använda i applikationer som hanterar stora

transaktionsvolymer och har behov av låg responstid för att komma åt massiv information

samt behöver bra tillgänglighet även när databasmiljön är opålitlig. Företag som använder

relationsdatabaser för att uppnå dessa mål började att bygga ut databaserna till större kluster.

Företagen som misslyckades med skalningen av databasen fick istället skala ner sin

existerande relationsdatabas (Nance et al., 2013).

Tudorica och Bucur (2011) konstaterar att eftersom NoSQL databaserna är konstruerade för

att hantera stora databaser så är det ingen ide att jämföra dem med relationsdatabaserna på


31

grund av att det inte skulle tillföra något. De hävdar även att det är allmän kännedom att den

största relationsdatabasen inte kan hantera datamängder över en viss gräns utan minnes

caching och utökad fragmentering. I lägen över denna gräns blir relationsdatabasen för

långsam för att vara användbar i någon situation.

För att få en robust och korrekt databas ska den uppfylla ACID egenskaperna men när

datastorleken blir stor är det svårt att upprätthålla dessa egenskaper. Det är därför NoSQL

databaserna fokuserar på BASE principerna istället (Abramova & Bernardino, 2013). Faktum

är att med stora datasamlingar blir det näst intill omöjligt att identifiera farlig information som

kan skada databasen (Osawaru & Ahamed, 2014).

Det som går att utläsas från mappningen är att NoSQL är den databasen som föredras vid

lagring av stora mängder ostrukturerad data vilket även (Parker et al., 2013) och (Nance et al.,

2013) bekräftar.

5.1.8 Koncept H, Bearbeta data

Enligt Zvarevashe och Gotora (2014) är bristen på affärsanalytiska data en av de bidragande

anledningarna till NoSQL databasens omognad (se Figur 4). I och med att NoSQL databasen

utvecklades för att tillmötesgå skalningskravet som moderna Web 2.0 applikationer kräver, så

har NoSQL databaserna inte utvecklat funktioner för att hämta affärsdata. Något som är

viktigt för företag att kunna göra då det kan förbättra verksamhetens konkurrenskraft. NoSQL

databaser erbjuder få funktioner för ad-hoc frågor och analyser. Även enkla frågeoperationer

kräver programmeringsexpertis och vanligt använda business intelligence verktyg fungerar

inte i NoSQL (Zvarevashe & Gotora, 2014). Eftersom NoSQL mest stödjer get och put

gränssnitt har de svårt att erbjuda enkla grupperingar och aggregatstöd (Özcan et al., 2014).

Enligt Indrawan-Santiago (2012) var NoSQL databaser designade för att stödja

tillgängligheten av data till slutanvändare snarare än till att hjälpa vid insamling av affärsdata

för beslutsfattning. Därför har NoSQL väldigt begränsat frågestöd för detta. Till skillnad från

relationsdatabaserna så behöver NoSQL utvecklarna vara skickligare för att kunna ta fram

affärsdata. Detta på grund av att relationsdatabaserna har bättre verktyg för affärsanalys.

NoSQL är en stor samling databasmodeller som inte följer relationsdatabasens modell vilket

gör att de sällan använder sig av SQL språket vid bearbetning av data (Huang & Luo, 2014).


32

På grund av att NoSQL databaser är horisontellt distribuerade stödjer de inte operationer som

join och order by. Denna restriktion gäller även för horisontellt distribuerade

relationsdatabaser. Det går att lösa detta problem genom att lägga join-operationen på

klientlagret (Pokorny, 2013; Osawaru & Ahamed, 2014).

En kvalitativ undersökning gjord av Shalini och Dhamodharan (2014) visar att NoSQL

databaserna till skillnad från relationsdatabaserna inte har stöd för dataanalys via bland annat

aggregatfunktioner. De säger även att relationsdatabaserna har ett specifikt språk för att

hantera data i databasen. Något som NoSQL får göra genom ett objektorienterat

applikationsprogrammeringsgränssnitt (API). I ett läshastighetstest av aggregatoperationen

utfört av Manoj (2014) visar resultaten att NoSQL databasen klarade sig signifikant mycket

sämre än relationsdatabasen. Manoj (2014) menar att vissa moderna NoSQL databaser

prioriterar skalbarhet över consistency vilket leder till att join- och aggregatfunktioner har

utelämnats.

Artikel av (Bonnet et al., 2011) säger att vissa NoSQL databaser har implementerat

MapReduce ramverket för att snabbt kunna aggregera data. Däremot i artikeln av (Floratou et

al., 2012) visas att även med hjälp av MapReduce kunde inte NoSQL databasen klara sig

bättre än relationsdatabasen.

(Parker et al., 2013) jämförde prestandan mellan relationsdatabasen och NoSQL databasen i

aggregatfunktionen vilket visar att NoSQL databasen presterade cirka 23 gånger långsammare

än relationsdatabasen. Däremot presterade NoSQL databasen lika bra och i bland bättre än

relationsdatabasen vid enkla frågor som insert, update och select. I (Vicknair et al., 2010)

visade deras resultat att NoSQL databasen presterade upp till tio gånger bättre i enkla frågor

än relationsdatabasen.

Anledningen enligt Wayner (2012) till varför NoSQL databasen presterar långsammare vid

beräkningar är för att all data först måste hämtas för att sedan kunna bearbetas. Det är tiden

för att hämta data, det vill säga bandbredden som kostar tid och inte själva beräkningen. I

relationsdatabasen när summan av endast en kolumn efterfrågas utförs den beräkningen i

databasen för att sedan skickas tillbaka vilket resulterar i snabbare responstid.

Vid stort behov av affärsdata och användande av aggregatfunktioner är inte NoSQL databasen

att föredra på grund av att: ett; den tillhandhåller inte stöd för aggregatfunktioner, två; NoSQL

databasen är långsammare än relationsdatabasen på att ta fram affärsdata, tre; det finns ingen


33

databasdesignstandard och fyra; den följer inte relationsdatabasens principer för logisk och

fysisk dataoberoende.

5.1.9 Koncept I, Expertis

Relationsdatabasen utför komplexa operationer lätt medan NoSQL databasen gör det nästan

omöjligt svårt för utvecklaren att göra detsamma enligt Cattell (2011) samt Kadebu och

Mapanga (2014). Eftersom inte alla NoSQL databaser har stöd för ad-hoc frågor krävs högre

programmeringsexpertis hos utvecklarna av NoSQL databaser än hos relationsdatabasernas

utvecklare (Indrawan-Santiago, 2012). En anledning till att många organisationer inte väljer

NoSQL databaser är för att de känner sig osäkra på tekniken då den är obekant för dem

(Naheman & Wei, 2013).

En fördel med NoSQL databaserna är enligt Leavitt (2010) att det är lättare att arbeta med

dem för de utvecklare som inte vana vid SQL språket. NoSQL databasens utvecklingsprocess

är annorlunda från relationsdatabasens då det kräver en utvecklarcentrerad strategi från

tillämpningens början till slut. I början av databasmodelleringsprocessen hos NoSQL

databaserna utförs det av en applikationsarkitekt eller en systemutvecklare medan hos

relationsdatabaserna är det dataarkitekter och datamodellerare som utför

datamodelleringsuppgifterna. Ofta börjar dataarkitekter eller datamodellerare med att bygga

konceptuella och logiska datamodeller. Transaktioner och frågeoperationer involveras inte

förrän vid utformningen av den fysiska relationsdatabasen. Däremot för NoSQL databaser

börjar applikationsarkitekten eller systemutvecklaren med att identifiera applikationens frågor

och utifrån det strukturera datamodellen för att effektivt stödja frågorna, därmed finns det en

stark koppling mellan applikationens och datamodellens frågor. Detta medför att förändringar

av frågor på ena stället påverka andra, exempelvis om utvecklaren ändrar i datamodellens

frågor så måste applikationens frågor också ändras och vice versa (Leavitt, 2010). Vilket är

tvärtemot relationsdatabasernas beprövade principer för logisk och fysisk dataoberoende

(Gudivada et al., 2014).

5.1.10 Koncept J, Support/administration

En orsak till bristande förtroende hos stora företag är på grund av att NoSQL databasen är en

relativt ny teknik vilket gör att företagen väljer relationsdatabasen eftersom den har tillförlitlig

support och förvaltning (Barmpis & Kolovos, 2012; Vicknair et al., 2010). NoSQL

databasernas mål är att tillhandahålla en administrationslös lösning men verkligheten är en

annan. Dagens NoSQL databaser kräver en hel del skicklighet för att installeras och stor


34

ansträngning för att underhållas (Zvarevashe & Gotora, 2014; Nayak et al., 2013). Detta för

att NoSQL databaser inte har mekanismer för utförande och hantering av data consistency

(Tauro & Aravindh, 2012).

Eftersom relationsdatabaser har ett enhetligt språk resulterar det i bättre support och enklare

administration. Dessutom är kunskapen om relationsdatabaserna generellt mer spridda än

NoSQL databasernas vilket innebär att relationsdatabaserna inte är lika sårbara som NoSQL

databaserna om företaget som har skapat och tillhandahåller databasen försvinner (Nayak et

al., 2013; Zvarevashe & Gotora, 2014; Leavitt, 2010). Stor arbetsbörda läggs på

databasadministratörer eftersom administratörerna i NoSQL databaserna måste skapa egna

API:er bland annat för dataåtkomst. Vilket kan vara en mardröm i situationer där en

applikation ska flyttas från en NoSQL databas till en annan (Mohan, 2013).

Huang och Luo (2014) menar att företagen förväntar sig att deras databassystem ska ha

tillgång till trovärdig support hela tiden, något som leverantörerna av relationsdatabaser i hög

grad kan erbjuda. Däremot kan inte de små företag som levererar NoSQL databaserna

tillhandahålla samma supportkvalitet.

Två artiklar nämner både positiva och negativa aspekter av NoSQL databasernas support och

administration. Ena artikeln av (Abramova et al., 2014) säger att NoSQL möjliggör enklare

förvaltning och tar bort behovet av ändringar i applikation eller databasschema. NoSQL

databaser kan dra nytta av nya kluster och noder automatiskt utan att behöva manuell

hantering från databasadministratörer. Eftersom databasadministration vid stora mängder data

kan vara en svår uppgift att hantera. I artikeln av Kadebu och Mapanga (2013) säger de att

NoSQL databaserna generellt sätt har lägre administrationskrav, är billigare att förvalta samt

ger en hög prestanda. Utmaningen med NoSQL databaserna är bristen på standardiserade

databasmodeller och expertis för effektiv databashjälp (Kadebu & Mapanga, 2014).

Artikeln av Zaki (2014) menar att i och med de schemalösa datamodellerna och flexibla

egenskaperna hos NoSQL databaserna, så anpassas databasen efter organisationens krav och

förenklar kommunikationen mellan applikationen och databasen. Vilket resulterar i färre

kodrader som i sin tur underlättar felsökning och förvaltning. Manoj (2014) säger att med

automatisk fragmentering av databaserna i NoSQL eliminerar det ett visst administrativt

besvär som manuell fragmentering skulle innebära vid horisontell skalning.


35

Relationsdatabasen är fortfarande det dominerande databassystemet på marknaden, vilket

innebär att företag med stort behov av support inte borde använda sig av en NoSQL databas

då den än så länge inte har en utvecklad supporthjälp.

5.1.11 Koncept K, Språkstandard

För att enkelt kunna öka kapaciteten genom horisontell skalning offrar NoSQL databaserna en

fast datastruktur och ett kraftfullt frågespråk (van der Veen et al., 2012).

I och med att utvecklingen av NoSQL har koncentrerats på att övervinna några av

relationsdatabasernas brister så har utvecklingen av NoSQL's frågespråk blivit åsidosatt. På

grund av detta har fördelarna med ett högnivåfrågespråk och applikationsoberoende också

försummats (Mohan, 2013). Ett sofistikerat frågespråk som SQL kommer alltid att överglänsa

ett osofistikerat frågespråk som de NoSQL tillhandahåller enligt Wayner (2012). De flesta

NoSQL databaser har inte stöd för högnivåspråk med inbyggd frågeoptimering utan istället

förväntas applikationsutvecklaren att ta hand om optimeringen men de få optimeringar som

finns är inte lika sofistikerade som de relationsdatabaserna har. Detta innebär att NoSQL

databaserna idag inte har en gemensam frågespråksstandard (Mohan, 2013; Özcan et al.,

2014; Barmpis & Kolovos, 2012; Parker et al., 2013; Pokorný, 2014).

Det gemensamma språket hos relationsdatabaserna gör att övergångar mellan olika

implementationer är enklare än med NoSQL databaserna, eftersom de enskilda NoSQL

databasernas frågespråk är specifika för just dem (Vicknair et al., 2010).

Enligt Stonebraker (2011) erbjuder SQL en enkel programmering för ad-hoc förfrågningar.

Han menar också att det är som att gå tillbaka i utvecklingen då utvecklaren måste formulera

egna metoder för att hämta data i en NoSQL databas. Vidare menar Lungu och Tudorica

(2013) att nästan alla NoSQL databaserna är som främmande för varandra eftersom de är

designade med olika strukturer, koncept och tekniker. Så om någon applikation skulle behöva

använda sig av NoSQL databasen stöter de svårigheten att behöva tala flera språk. I artikeln

av Leavitt (2010) nämner han att manuell frågeprogrammering krävs då NoSQL databaserna

inte kan samarbeta med SQL. Detta kan vara snabbt för enkla uppgifter men tidskrävande för

mer komplexa uppgifter. Däremot menar (Atzeni et al., 2013) att relationsdatabasmodellen

och deras dominerande språk (SQL) måste skiljas åt när det kommer till relationsdatabaser.

Relationsmodellen och SQL uppfanns vid en tid då datahanteringen främst var riktad för

administrativa applikationer. Målet då var att stödja applikationer för exempelvis


36

bankverksamheter men informationshanteringen i dagens IT-samhälle har utvecklats.

Exempel på denna typ av information är bland annat semi- eller ostrukturerad data vilket

relationsmodellen och SQL inte var skapad för att hantera (Atzeni et al., 2013; Özcan et al.,

2014).

(Nayak et al., 2013) talar om ett försök till att skapa ett familjärt, standardiserat NoSQL

frågespråk. Det frågespråk artikeln nämner heter UnQL som har SQL-liknade syntax vilket

underlättar för utvecklare som redan kan SQL. Med UnQL finns det även funktioner som

möjliggör att göra val och manipulering av komplexa dokumentstrukturer. Det i sin tur

tillhandahåller NoSQL databasens flexibla schemafria design samt utnyttjar

relationsdatabasens strukturerade tabellformat.

Detta koncept förekommer ofta när det skrivs om nackdelar med NoSQL bland annat skriver

Bartholomew (2010) att det inte finns och kommer aldrig att finnas något frågespråk eller API

som är gemensamt för NoSQL databaser eftersom alla NoSQL databaser är så olika

(Bartholomew, 2010) och majoriteten av artiklarna i mappningen säger detsamma.

5.1.12 Koncept L, Kostnad

Enligt (Nance et al., 2013) lämpar sig inte relationsdatabasen för de moderna

webbapplikationerna som ska kunna stödja miljontals samtidigt anslutna användare. NoSQL

databasteknologin har uppstått för att ge ett kostnadseffektivt databashanteringsalternativ för

de moderna webb- och mobilapplikationerna. Relationsdatabaserna enligt Pokorny (2013)

tillhandahåller inte ett kostnadseffektivt sätt att expandera databasens lagringsutrymme.

NoSQL databaser kan köras i kluster av billiga dataservrar vilket innebär att utskalningen blir

kostnadseffektivt. Dessutom är de flesta NoSQL databaserna open source utan dyra

licenskostnader (Naheman & Wei, 2013; Nance et al., 2013; Abramova et al., 2014). För en

del utvecklare är just detta attraktivt ur ett kostnadsperspektiv (Mohan, 2013; Atzeni et al.,

2013).

Nackdelen med NoSQL databaser är att det kan vara en ekonomisk börda för ett företag att

upprätthålla tillförlitlig lagringskapacitet för flera uppsättningar redundant ostrukturerad data.

Samtidigt måste kostnadsnyttan ställas i paritet med kostnaden av att anställa utvecklare och

systemadministratörer för förvaltning av relationsdatabasen. En annan nackdel är att NoSQL

databasen endast har funnits i mindre ett decennium vilket gör den till en ung teknik i


37

jämförelse med relationsdatabasen. Detta innebär att det finns få erfarna utvecklare inom

NoSQL vilket kan ge höga kostnader vid supportbehov (Hammes et al., 2014).

Om kostnaden för att utöka lagringskapaciteten är högt prioriterat är NoSQL databaser

lämpligare än relationsdatabaserna.

5.2 NoSQL databasernas för- och nackdelar

Nedan presenteras en sammanfattning av NoSQL databasens för- respektive nackdelar i

punktform.

5.2.1 NoSQL databasernas fördelar

Horisontell skalbarhet - Utifrån litteraturstudien går det att utläsa att NoSQL helt klart

är bättre när det kommer till horisontell skalning av en databas. Ingen av artiklarna

ansåg att NoSQL databasens förmåga att hantera skalning var negativ. Detta beror

mycket på att NoSQL databaserna är utformade för horisontell skalning.

Prestanda - Detta är ytterligare ett område där NoSQL databaserna presterar bättre än

relationsdatabaserna. Ett antal artiklar har gjort prestandatester för att mäta

responstiden på olika operationer. Överlag presterade NoSQL databasen bättre.

Tillgänglighet - Alla artiklar som behandlade konceptet var positiv inställda. Eftersom

NoSQL databaser placeras i ett kluster av noder så är det lätt att ta bort och lägga till

noder utan att störa databasen funktion som helhet. Den replikation som NoSQL

databasen tillhandahåller gör det möjligt att alltid ha samma information tillgängligt

även om en nod ligger nere.

Anpassningsbarhet - I och med att det inte finns någon generell standard för hur

NoSQL databasen ska se ut och att det finns över 150 stycken olika NoSQL databaser

samt att de oftast är av open souce-typ gör att utvecklaren får friheten att anpassa efter

sina behov. Därför har NoSQL en klar fördel över relationsdatabasen i

anpassningsbarhet.

Kapacitet - NoSQL är skapat för att hantera enorma mängder data, vilket mappningen

tydligt visar på.

Kostnad - Bland alla artiklar som tar upp konceptet råder det i stort sätt koncensus

över att NoSQL är mer kostnadseffektiv än relationsdatabasen.


38

5.2.2 NoSQL databasernas nackdelar

Säkerhet - Alla artiklar förutom en som tar upp konceptet säger att NoSQL

databaserna brister i säkerheten, speciellt i datakryptering, autentisering och skydd

mot injektion.

Consistency - Consistency är ännu ett område där NoSQL databaserna brister vilket

mappningen helt klart påvisar.

Bearbeta data - NoSQL databaserna har sämre stöd för aggregatfunktioner än

relationsdatabaserna. Dessutom är NoSQL inte lämplig för att hämta adekvat

affärsdata.

Expertis - Mycket expertis krävs för att kunna skapa och underhålla NoSQL

databasen.

Support och administration - Bristen på expertis inom området och de faktum att

NoSQL är en ung databasteknik gör att det blir svårt att underhålla och administrera.

Avsaknad av språkstandard - Även om det ibland kan vara en fördel att inte ha en

språkstandard för att utvecklaren ska kunna anpassa databasen efter sina egna behov.

Så visar ändå mappningen att majoriteten av artiklarna ansar att det är en nackdel.

6 Diskussion

Här följer en diskussion om i vilka situationer NoSQL kan vara lämplig respektive olämplig.

Därefter diskuterar vi om hur vi ser på framtiden för databaser.

NoSQL databaser har enligt (Özcan et al., 2014) blivit populära bland systemvecklare trots att

NoSQL databaser brister på olika punkter som bland annat frånvaro av standardspråk och

stödjer för det mesta enbart läs- och skrivgränssnitt. Anledningen till varför NoSQL databaser

blivit omtyckta är för att de bland annat erbjuder flexibla scheman, hög skalbarhet, är enkla att

implementera med mera (Özcan et al., 2014).

Trots att NoSQL databaserna är populära bland systemutvecklare så är det inte många företag

som känner till NoSQL. En undersökning av Naheman och Wei (2013) visar att 44 procent av

755 stycken systemutvecklare vid företag aldrig har hört talas om NoSQL, 22 procent är

intresserad men behöver mer kunskap inom området och endast en procent använder NoSQL

som en viktig del av sin strategi (se Figur 11).


39

Figur 11. Visar hur många procent som känner till eller använder sig av NoSQL databaser (Naheman & Wei, 2013).

En undersökning utförd av Couchbase (2012) bland 1300 respondenter visar att den största

anledningen till att många väljer NoSQL databaser är NoSQL databasens flexibla scheman.

Andra orsaker är skalbarheten, låg responstid, kostnad med mera (se Figur12).

Figur 12. Orsaker som driver till valet att gå över till NoSQL (Couchbase, 2012).

6.1 När är NoSQL lämplig respektive olämplig?

Genom litteraturstudien har vi identifierat att fördelarna med NoSQL databaserna gör att de är

lämpliga i situationer där horisontell skalbarhet är en viktig prioritet. Exempelvis som hos

sökmotorer, sociala nätverk och e-handels hemsidor eftersom dessa lagrar enorma mängder

oftast ostrukturerad data. De har även behov av att kunna utöka sin databas i proportion till

antalet användare och mängden data som dessa användare genererar. Dessa applikationer har

inte stort krav på att data consistency. Därför anser vi att NoSQL databaser är lämpligt för

dessa ändamål.


40

I sociala applikationer som Facebook är consistency inte den viktigaste egenskapen som ställs

på databasen. Däremot är horisontell skalning, tillgången till stor datalagring, förmågan att

lagra ostrukturerad data och tillgängligheten viktiga egenskaper. På grund av den stora

mängden ostrukturerad data som sociala nätverk hanterar, behöver de ha kostnadseffektiva

alternativ till utökningen av databasen. En artikel av Kajeepeta (2012) påvisar att NoSQL

databasen passar perfekt i de fall det handlar om stora volymer av data, alltså minst några

terabyte data med 10 000 eller 20 000 samtidiga lagringar per sekund som exempel. När

databasen kommer upp till den belastningen måste företagen fokusera på skalningsmöjligheter

som inte kostar en förmögenhet (Kajeepeta, 2012). Därför anser vi att NoSQL databaser

passar för sociala media applikationer. Den stora användarbelastningen som sociala nätverk

har, sätter krav på hög tillgänglighet på databasens innehåll. Däremot är det mindre viktigt att

den data som visas är den senaste och mest aktuella informationen. Vilket gör att NoSQL

databasen är lämplig vid utveckling av sociala media applikationer.

Eftersom slutanvändare inte vill uppleva en lång väntetid vid exempelvis användning av

sökmotorer så är en snabb responstid en viktig faktor. Andra faktorer som är viktiga när det

kommer till sökmotorer är att sökorden ska resultera i relevanta resultat, att den fungera trots

att en del av databasen ligger nere och att kunna söka igenom stora mängder ostrukturerad

data. Vissa NoSQL databaser använder sig av ett key-value system för att optimera sökningar

i databasen. Dessa är speciellt lämpliga för sökmotorer. NoSQL databasens key-value system

testades av Sharma och Soni (2014) som visade att NoSQL systemet presterade bättre än

relationsdatabasen. Även (Parker et al., 2013) styrker detta påstående genom deras

läsbarhetsexperiment där NoSQL databasen klarade sig bättre än relationsdatabasen.

För bank-, finans-, och handelsverksamheter tror vi inte NoSQL databaser skulle vara lämplig

då de inte har den nivå av säkerhet och consistency som dessa verksamheter kräver. Eftersom

de oftast hanterar känslig information om kunderna. Två andra faktorer som gör NoSQL

olämplig för dessa verksamheter är att de inte har stöd för aggregatfunktioner eller affärsdata

för analys. Bankvärlden har trots allt nytta av att kunna göra beräkningar för till exempel lån,

räntor med mera. Med NoSQL databaser skulle responstiden vara för stor för vad dessa

branscher skulle kunna acceptera enligt oss. Detta är i enlighet med (Parker et al., 2013) som

har gjort prestandatestet på aggregatfunktioner i NoSQL databaser och relationsdatabaser.

Dessa tester visar att relationsdatabaserna är upp till 23 gånger snabbare än NoSQL

databaserna vilket i en verklig situation som i bankverksamheterna skulle innebära att NoSQL


41

databasen är allt för långsam. Ytterligare en orsak till varför NoSQL inte är att föredra inom

bankvärlden är deras brist på consistency. NoSQL stödjer endast eventual consistency vilket

betyder att det inte finns garantier för att transaktioner fullföljs. En krasch av databasen skulle

kunna innebära att data blir inkonsekvent. "The idea of “eventual consistency” for such

applications could lead to chaos in the business world." är ett citat taget från artikeln av

(Atzeni et al., 2013, s. 67) som beskriver våra tankar.

Ett annat område där NoSQL databaser inte skulle vara lämpliga är hälso- och

sjukvårdsverksamheter eftersom de är starkt styrda av sekretesslagen. Därmed är säkerheten

en avgörande faktor för varför NoSQL databaserna inte är passande. Speciellt eftersom

NoSQL inte har datakryptering eller något skydd för injektion samt är känslig för

överbelastningsattacker (Kadebu & Mapanga, 2014; Osawaru & Ahamed, 2014). En annan

faktor som är viktig för både bank-, finans-, handel- och sjukvårdverksamheten är tillgång till

support och administration. Eftersom det vid kritiska lägen krävs att problemen löses så

snabbt som möjligt. I och med att företagen som levererar NoSQL databaser oftast är små kan

de inte alltid tillhandahålla tillräcklig support (Zvarevashe & Gotora, 2014). Kunskapen om

dessa databaser är även en faktor som bidrar till bristerna i supportmöjligheterna eftersom

NoSQL är relativt ungt (Hammes et al., 2014).

Med NoSQL databasernas flexibla schemalösa struktur ges utvecklarna möjlighet att skapa en

mer dynamisk databas som är bra till applikationer som är i behov av ständiga förändringar

och inte behöver komplexa operationer. NoSQL databasernas anpassningsförmåga gör att

utvecklingsprocessen går snabbare men nackdelen med detta är att alla i en

utvecklingsprocess tänker olika vilket gör att förvaltningen av NoSQL databasen kan bli

komplicerad. Speciellt om databasen har gått igenom flera utvecklingsteam under sin

livscykel. Precis som exemplet ur artikeln av Wayner (2012) om att ett nyckelvärde kan få

olika benämningar beroende på vem som skapar det så kan databasen bli inkonsekvent

designad.

I och med att NoSQL databasen är lätt att anpassa efter behov, underlättar det i agil

utvecklingsmiljö där mycket kan ändras snabbt. NoSQL databaserna är flexibla samt

anpassningsbara till nya idéer och svarar emot nya krav för att implementera databasen i

iterativt utveckling (Hecht & Jablonski, 2011). Däremot finns det de som ifrågasätter NoSQL

databasernas snabba framfart. De menar att utvecklarna och företagen måste tänka till innan

de väljer en NoSQL databas för sina lagringsbehov. Precis som det går att utläsa av citatet


42

"For some of the NoSQL people either their memory is bad or they are too young to know

personally from experience about what has been done in the past and the lessons learnt as

different approaches were tried out." av (Mohan, 2013, s. 12) så ska inte flera decenniers

beprövade kunskaper helt åsidosättas.

Avsaknaden av en språkstandard bidrar till att det är svårt att hitta en expert inom just den

NoSQL databas som företaget använder Kadebu och Mapanga (2014) men för de kreativa

utvecklare som vill anpassa sin databas efter sin applikation samtidigt som de vill hålla

kostnaden nere är NoSQL databaserna att föredra. NoSQL är även lämpligt i de fall då

utvecklarna inte har tillräckliga kunskaper inom relationsdatabasernas språk eftersom de då

har lättare att ta till sig ett nya idéer och tankesätt.

6.2 Framtiden

En hybridlösning mellan relationsdatabasen och NoSQL databasen är den lösning som vi

anser är mest optimal. Eftersom NoSQL databasen inte är skapad för att konkurrera ut

relationsdatabasen, utan de är framtagna för att komplettera för där relationsdatabaserna

brister och samexistera med relationsdatabaserna (Zahid et al., 2014; Nayak et al., 2013).

Därför är NoSQL databaserna nischade mot vissa branscher (Cattell, 2011). Med hybrid

menar vi att en verksamhet kan välja att ha flera olika databaslösningar beroende på vilken

typ av ändamål de vill ha databasen till. Databaserna ska hantera den typen av uppgifter den

är mest lämpad för. Alltså om en del av verksamheten kräver hög säkerhet eller stark

consistency ska de välja relationsdatabasen. Å andra sidan, om en annan del av verksamheten

behöver en databas som ska gå att skala horisontellt på ett kostnadseffektivt sätt samt endast

behöver hämta och lagra ostrukturerat data så borde de välja NoSQL databasen. Dessa

databaser ska då kunna existera i symbios och på så sätt anpassas efter verksamheten behov.

Detta i sin tur kan vara kostnadseffektivt för företaget i längden eftersom NoSQL databaserna

generellt sätt är billigare att utöka medan det är dyrare att utöka en relationsdatabas till

liknade storlek (Pokorny, 2013).

Precis som Huang och Luo (2014) nämner i sin artikel förespår de att fler och fler utvecklare

kommer att överge ACID egenskaperna för att erhålla bättre skalbarhet, tillgänglighet med

mera. Eftersom flera företag kommer att behöva använda NoSQL databasteknologin för att

bemöta den stigande tillväxten av användare. Därför anser vi att NoSQL databaserna kommer

att förbättra sig på att uppfylla mer av ACID egenskaperna samt hitta ett mer standardiserat


43

språk som fortfarande erbjuder flexibiliteten i att anpassa databasmodellen efter

applikationen.

Huang och Luo (2014) tror även att relationsdatabaserna kommer att konkurrera med och ta

marknadsandelar från NoSQL databaserna under förutsättning att relationsdatabaserna blir

bättre på bland annat skalbarhet, prestanda och tillgänglighet. Vilket vi instämmer i men vi

anser att både relationsdatabaserna och NoSQL databaserna borde ha som mål att förbättra

sina fördelar och verktyg istället för att fokusera på sina konkurrenter.

Vi menar att så länge som både relationsdatabasens och NoSQL databasens fördelar nyttjas

vid de situationer de är lämpliga för, så är till exempel inte nackdelen säkerhet hos NoSQL

databasen en nackdel. I situationer där prestanda och hög tillgänglighet är prioriterat så skulle

säkerheten tynga ner processtiden (Osawaru & Ahamed, 2014). Som tidigare nämnts så anser

vi att NoSQL databaser passar till utveckling av sökmotorer. Där skulle säkerhet kunna vara

ett hinder mer än en hjälp. Däremot tror vi att NoSQL databaserna kommer att utvecklas

vidare på den delen, så länge säkerheten inte försämrar prestandan och tillgängligheten för

mycket.

En annan nackdel som vi har identifierat utifrån litteraturstudien är consistency men även den

behöver inte vara en nackdel. Speciellt i de applikationer som inte har som målsättningen att

alltid visa den senaste uppdateringen till slutanvändaren utan hellre prioriterar prestanda och

tillgänglighet. Exempel på detta är sociala nätverksapplikationer där slutanvändarna är

medvetna om att de inte alltid ser de senaste uppdateringarna men heller inte ser det som ett

problem.

7 Slutsats

Frågeställningarna som har styrt hela uppsatsen är i vilka situationer NoSQL databaserna är

lämpliga respektive olämpliga samt vilka för- och nackdelar de har. Utifrån resultatet och

analysen kan slutsatsen dras att nackdelarna med NoSQL databaserna är att de har låg

säkerhet, ingen språkstandard, bristande stöd för aggregatfunktioner och framtagning av

affärsdata, support och administration samt kräver hög expertis, vilket gör att de är mindre

lämpliga i situationer där detta efterfrågas. Exempelvis i bank-, sjukvård- eller

finansverksamheter. Däremot passar NoSQL databaser in i situationer där skalbarhet,

prestanda, tillgänglighet, kostnadseffektivitet, anpassningsbarhet och kapacitet är viktigt,


44

vilket också är NoSQL databasens fördelar. Därför passar NoSQL databaser till exempelvis

sökmotorer och webbshopp applikationer.

7.1 Teorietiska och praktiska bidraget

Eftersom uppsatsen sammanfattar NoSQL databasernas för- och nackdel på en abstrakt nivå

kan det teorietiska bidraget vara underlag för vidare studier. Uppsatsen kan även ligga till

grund för experiment som testar till exempel prestandaskillnader mellan relationsdatabaserna

och NoSQL databaserna. Ett område som kan vara intressant för vidare forskning är

subkategorierna av NoSQL databaserna, något denna uppsats inte har gått djupare in på.

Eftersom det finns många variationer inom NoSQL databaser så är det intressant att utreda

vilken NoSQL databas som skulle passa bäst till ett specifikt koncept ifrån vår mappning.

Något som också kan vara värt att utreda är hur lätt alternativt svårt det är att skapa en

NoSQL databas i jämförelse med relationsdatabasen. Vår uppsats skulle även då kunna bidra

teorietiskt eftersom vi har berört koncept som expertis, språkstandard med mera vilket kan

vara bidragande orsaker till om det är lätt respektive svårt att skapa en databas.

Det praktiska bidraget med uppsatsen är att den kan användas som underlag för exempel

systemutvecklarens eller företagarens beslutfattande vid val av vilken databas som är mest

lämpad för deras ändamål. Ett annat område som vi kan se att uppsatsen praktiskt kan bidra

till är inom utbildningsverksamheten. Där kan uppsatsen ligga till grund för att starta nya

kurser inom informatik.


45

Referenslista enligt APA

Abramova, V., & Bernardino, J. (2013). NoSQL Databases: MongoDB vs Cassandra.

International C* Conference on Computer Science and Software Engineering, 14-22.

doi:10.1145/2494444.2494447

Abramova, V., Bernardino, J., & Furtado, P. (2014). Experimental evaluation of NoSQL

databases. International Journal of Database Management Systems, 6(3), 1-16.

doi:10.5121/ijdms.2014.6301

Atzeni, P., Jensen, C. S., Orsi, G., Ram, S., Tanca, L., ... (2013). The relational model is dead,

SQL is dead, and I don’t feel so good myself. ACM SIGMOD Record, 42(2), 64-68.

doi:10.1145/2503792.2503808

Avdic, A. (2011). Riktlinjer för rapportering. Örebro: Örebro universitet kurslitteratur.

Barmpis, K., & Kolovos, D. S. (2012). Comparative Analysis of Data Persistence

Technologies for Large-Scale Models. Proceedings of the 2012 Extreme Modeling

Workshop, 33-38. doi:10.1145/2467307.2467314

Bartholomew, D. (2010, September 01). SQL vs. NoSQL. Linux Journal. Hämtad från

http://www.linuxjournal.com/article/10770

Bonnet, L., Laurent, A., Sala, M. Laurent, B., & Sicard, N. (2011). Reduce, you say: What

NoSQL can do for Data Aggregation and BI in Large Repositories. 22nd International

Workshop on Database and Expert Systems Applications, 483-488.

doi:10.1109/DEXA.2011.71

Cattell, R. (2011). Scalable SQL and NoSQL Data Stores. Special Interest Group on

Management of Data, 39(4), 12-27. doi:10.1145/1978915.1978919

Couchbase. (2012). Couchbase Survey Shows Accelerated Adoption of NoSQL in 2012.

Hämtat 24 december 2014 från Couchbase: http://www.couchbase.com/press-

releases/couchbase-survey-shows-accelerated-adoption-nosql-2012

Couchbase. (2014). Why NoSQL. Hämtat 24 december 2014 från Couchbase:

http://www.couchbase.com/nosql-resources/what-is-no-sql

http://dx.doi.org/10.1145/2494444.2494447


46

CS Språkwebb. (n.d.). Ordlistan. Hämtat 27 december 2014 från ComputerSweden:

http://cstjanster.idg.se/sprakwebben/ord.asp?ord=replikering

Dean, J., & Gnemawat, S. (2008). MapReduce: Simplified Data Processing on Large Clusters.

Communications of the ACM - 50th anniversary, 51(1), 107-113.

doi:10.1145/1327452.1327492

distributed computing environment (DCE). (n.d.). Hämtad 28 december, 2014, från

http://www.businessdictionary.com/definition/distributed-computing-environment-

DCE.html

Dykstra, D. (2012). Comparison of the Frontier Distributed Database Caching System to

NoSQL Databases. Journal of Physics: Conference Series, 396(5), 1-9.

doi:10.1088/1742-6596/396/5/052031

Elizabeth E (2013, 28 maj). Evaluating Information Found on the Internet . Hämtat 25

december 2014 från John Hopkins sheridan libraries:

http://guides.library.jhu.edu/content.php?pid=198142&sid=1657518

Enescu, M. A. (n.d.). Toward Scalable Security: On the Scalability of Security in large-scale

software systems. Hämtat 10 december 2014 från The University of British Columbia

Blogs: http://blogs.ubc.ca/computersecurity/files/2012/04/MEnescu_paper.pdf

Floratou, A., Teletia, N., DeWitt, D. J., Patel, J. M., & Zhang, D. (2012). Can the Elephants

Handle the NoSQL Onslaught? The 38th International Conference on Very Large

Data Bases, 5(12), 1712-1723. doi:10.14778/2367502.2367511

Goldkuhl, G. (2011). Kunskapande. Örebro: Örebro Universitet kurslitteratur

Gudivada, N. V., Rao, D., & Raghavan, V. V. (2014). NoSQL Systems for Big Data

Management. 2014 IEEE 10th World Congress on Services, 190-197.

doi:10.1109/SERVICES.2014.42

Hammes, D., Medero, H., & Mitchell, H. (2014). Comparison of NoSQL and SQL databases

in the cloud. Proceedings of the Southern Association for Information Systems

Conference, 1-8. Hämtad från

http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1011&context=sais2014


47

Han, J., E, H., Le, G., & Du, J. (2011). Survey on NoSQL Database. 2011 6th International

Conference on Pervasive Computing and Applications, 363-366.

doi:10.1109/ICPCA.2011.6106531

Hecht, R., & Jablonski, S. (2011). NoSQL Evaluation: A Use Case Oriented Survey. 2011

International Conference on Cloud and Service Computing, 336-341. doi:

10.1109/CSC.2011.6138544

Helmersson, D. (n.d.). Hämtad 28 december, 2014, från:

http://www.ne.se/uppslagsverk/encyklopedi/l%C3%A5ng/molnet

Henriksson, S (n.d.). Hämtad 28 december, 2014, från:

http://www.ne.se/uppslagsverk/encyklopedi/l%C3%A5ng/it

Huang, Y., & Luo, T. (2014). NoSQL Database: A Scalable, Availability, High Performance

Storage for big Data. ICPCA, 8351, 172-183. doi:10.1007/978-3-319-09265-2_19

Indrawan-Santiago, M. (2012). Database Research: Are We At A Crossroad? 15th

International Conference on Network-Based Information Systems, 5(12), 45-51.

doi:10.1109/NBiS.2012.95

Kadebu, P., & Mapanga, I. (2013). Database Management Systems: A NoSQL Analysis.

International Journal of Modern Communication Technologies & Research, 1(7), 12-

18. ISSN:2321-0850

Kadebu, P., & Mapanga, I. (2014). A security Requirements perspectiv towards a secured

NoSQL database Environment. International Conference of Advance Research and

Innovation, 472-480. ISBN:978-93-5156-328-0

Kajeepeta, S. (2012). NoSQL Everywhere? Not So Fast. United Business Media LLC, (1333),

1-3. ISSN:19383371

Lai, E. (2009, 1 juli). No to SQL? anti-database movement gains steam. Hämtat 14 december,

2014, från ComputerWorld:

http://www.computerworld.com/article/2526317/database-administration/no-to-sql--

anti-database-movement-gains-steam.html


48

Leavitt, N. (2010). Will NoSQL databases live up to their promise? IEEE Computer Society,

12-14. doi:10.1109/MC.2010.58

Li, Y., & Manoharan, S. (2013). A performance comparison of SQL and NoSQL databased.

Communications, Computers and Signal Processing, 15-19.

doi:10.1109/PACRIM.2013.6625441

Lungu, I., & Tudorica, B. G. (2013). The Development of a Benchmark Tool for NoSQL

Databases. Hämtat 27 november 2014 från Database Systems Journal:

http://www.dbjournal.ro/archive/12/12_2.pdf

Manoj, V. (2014). Comparative study of NoSQL document, column store databases and

evaluation of cassandra. Hämtat 1 december 2014 från AIRCC Publishing

Corporation: http://www.airccse.org/journal/ijdms/papers/6414ijdms02.pdf

Marrelli, A. F. (Augusti 2005). The Performance Technologist's Toolbox: Literature Review.

Performance Improvement, 44(7), 40-44. doi:10.1002/pfi.4140440710

Metadata. (2014, 18 augusti). Hämtad 14 december, 2014, från:

http://sv.wikipedia.org/wiki/Metadata

Microsoft Technet. (n.d.). Hämtad 28 december, 2014, från: http://technet.microsoft.com/en-

us/library/ms177433%28v=sql.105%29.aspx

Mohamed, A. M., Altarfi, O. G., & Ismail, M. O. (2014). Relational vs. NoSQL Databases: A

Survey. Hämtat 1 december 2014 från International Journal of Computer and

Information Technology:

http://www.ijcit.com/archives/volume3/issue3/Paper030320.pdf

Mohan, C. (2013). History repeats itself: Sensible and NonsenSQL aspects of NoSQL hoopla.

EDBT '13 Proceedings of the 16th International Conference on Extending Database

Technology, 11-16. doi:10.1145/2452376.2452378

Monger, M. D., Mata-Toledo, R. A., & Gupta, P. (2012). TEMPORAL DATA

MANAGEMENT IN NOSQL DATABASES. Hämtat 1 december 2014 från Journal of

Information Systems and Operations Management:

ftp://ftp.repec.org/opt/ReDIF/RePEc/rau/jisomg/WI12/JISOM-WI12-A1.pdf


49

Moniruzzaman, A. B., & Hossain, S. A. (2013). NoSQL database: New era of databases for

big data analytics – Classification, Characteristics and Comparison. Hämtat 14

oktober 2014 från International Journal of Database Theory and Application:

http://www.sersc.org/journals/IJDTA/vol6_no4/1.pdf

Naheman, W., & Wei, J. (2013). Review of NoSQL databases and performance testing on

HBase. 2013 International Conference on Mechatronic Sciences, Electric Engineering

and Computer, 2304-2309. doi:10.1109/MEC.2013.6885425

Nance, C., Losser, T., Iype, R., & Harmon, G. (2013). NoSQL vs RDBMS – Why there is

room for both. SAIS 2013Proceedings, 111-116. Hämtat från:

http://aisel.aisnet.org/sais2013/27

Nayak, A., Poriya, A., & Poojary, D. (2013). Type of NoSQL Databases and its comparison

with relational databases. International Journal of Applied Information Systems, 5(4),

16-19. Hämtat från: http://research.ijais.org/volume5/number4/ijais12-450888.pdf

Oates, J. B. (2010). Researching information Systems and Computing. London: SAGE

Publications Ltd.

Osawaru, E. R., & Ahamed, R. A. (2014). A Highlight of Security Challenges in Big Data.

International Journal of Information Systems and Engineering, 2(1), 1-10. Hämtat

från: http://www.ftms.edu.my/journals/IJISE/Journal/ASCENT%202014/001-010-

A%20Highlight%20of%20Security%20Challenges%20in%20Big%20Data.pdf

Padron-McCarthy, T. (2005, 18 juli). Distribuerade databaser. Hämtat från Databasteknik:

http://www.databasteknik.se/webbkursen/distribuerade/index.html den 27 December

2012

Padron-McCarthy, T. & Risch, T. (2005). Databasteknik. Lund: Studentlitteratur AB.

Parker, Z., Poe, S., & Vrbsky, S. V. (2013). Comparing NoSQL MongoDB to an SQL DB.

Proceedings of the 51st ACM Southeast Conference, 1-6.

doi:10.1145/2498328.2500047

Pokorny, J. (2013). NoSQL databases: a step to database scalability in web environment.

Proceedings of the 13th International Conference on Information Integration and

Web-based Applications and Services, 278-283. doi:10.1145/2095536.2095583


50

Pokorný, J. (2014). How to Store and Process Big Data: Are Today’s Databases Sufficient.

13th IFIP TC8 International Conference, CISIM 2014, 8838, 5-10. doi:10.1007/978-3-

662-45237-0_2

Pritchett, D. (den 28 Juli 2008). BASE, An ACID Alternative. Queue - Object-Relational

Mapping, 6(3), 48-55. doi:10.1145/1394127.1394128

Rith, J., Lehmayr, P. S., & Meyer-Wegener, K. (2014). Speaking in Tongues: SQL Access to

NoSQL Systems. 29th Annual ACM Symposium on Applied Computing, 855-857.

doi:10.1145/2554850.2555099

Rosengren, L. (den 24 Augusti 2012). 4 frågor om Big Data. Hämtat 27 december, 2014, från

CIO SWEDEN: http://cio.idg.se/2.1782/1.461976/4-fragor-om-big-data

Sadalage, J. P. & Fowlar, M. (2013). NoSQL Distilled a Brief Guide to the Emerging World of

Polygot Persistence. New Jersey: Pearson Education.

Shalini, M., & Dhamodharan, S. (11 2014). Performance and Scaling Comparison Study of

RDBMS and NoSQL (MongoDB). Compusoft An international journal of advanced

computer technology, 3(11), 1270-1275. ISSN:2320-0790

Sharma Mukul, S. P. (2014). Quantitative Analysis and Implementation of Relational and

Graph Database Technologies. International Journal of Modern Computer Science

and Applications, 2(5), 20-24. ISSN:2321-2632

Stonebraker, M. (2011). Stonebraker on NoSQL and enterprises. Communications of the

ACM, 54(8), 10-11. doi:10.1145/1978542.1978546

Strauch, C. (2012). NoSQL Databases. Hämtat 14 oktober, 2014, från Stuttgart Media

University:

http://www.sambib.lu.se/sites/sambib.lu.se/files/apa_manual_2014_v_1.01.pdf

Svenska datatermgruppen. (n.d.). Hämtat 28 december, 2014, från Svenska datatermgruppen:

http://www.datatermgruppen.se/visning.html?obj=b171

Tauro, C. J., & Aravindh, S. A. (2012). Comparative Study of the New Generation, Agile,

Scalable, High Performance NoSQL Databases. International Journal of Computer


51

Applications, 48(20), 1-4. Hämtat från:

www.academia.edu/download/30869512/pxc3880336.pdf

Thantriwatte, T., & Keppetiyagama, C. (2011). NoSQL query processing system for wireless

ad-hoc and sensor networks. The International Conference on Advances in ICT for

Emerging Regions, 78-83. doi:10.1109/ICTer.2011.6075030

Tiwari, S. (2011). Professional NoSQL. Indianapolis: John Wiley & Sons, Inc.

Tudorica, B. G., & Bucur, C. (2011). A comparison between serveral NoSQL databases with

comments and notes. Roedunet International Conference, 1 - 5.

doi:10.1109/RoEduNet.2011.5993686

van der Veen, J. S., van der Waaij, B., & Meijer, R. J. (2012). Sensor Data Storage

Performance: SQL or NoSQL, Physical or Virtual. 2012 IEEE Fifth International

Conference on Cloud Computing, 431-438. doi:10.1109/CLOUD.2012.18

Vangie, B. (2015). structured data. Hämtat 7 januari, 2015, från http://www.webopedia.com:

http://www.webopedia.com/TERM/S/structured_data.html

Wayner, P. (2012). 7 hard truths about the NoSQL revolution. Hämtat 19 december, 2014,

från InfoWorld.com:

http://db.ub.oru.se/login?url=http://search.proquest.com/?url=http://search.proquest.co

m/docview/1025748918?

web 2.0. (n.d.). Hämtad 28 december, 2014, från

http://www.businessdictionary.com/definition/web-2-0.html

Webster, J., & Watson, R. T. (2002). ANALYZING THE PAST TO PREPARE FOR THE

FUTURE: WRITING A LITERATURE REVIEW. Management Information Systems

Quarterly, 26(2), 13-23. Hämtat från:

http://aisel.aisnet.org/cgi/viewcontent.cgi?article=2625&context=misq&sei-

redir=1&referer=http%3A%2F%2Fscholar.google.se%2Fscholar%3Fq%3DANALYZ

ING%2BTHE%2BPAST%2BTO%2BPREPARE%2BFOR%2BTHE%2BFUTURE%

3A%2BWRITING%2BA%2BLITERATURE%2BREVIEW%26hl%3Dsv%26as_sdt

%3D0%26as_vis%3D1%26oi%3Dscholart%26sa%3DX%26ei%3DqF6vVNCpCef-

ygObyYCoBA%26ved%3D0CB0QgQMwAA#search=%22ANALYZING%20PAST


52

%20PREPARE%20FUTURE%3A%20WRITING%20LITERATURE%20REVIEW%

22

Vicknair, C., Marcias, M., Zhao, Z., Nan, X., Chen, Y., ... (2010). A comparison of a graph

database and a relational database, a data provenance perspective. Proceedings of the

48th Annual Southeast Regional Conference, 1-6. doi:10.1145/1900008.1900067

Wikipedia. (2014, 26 november). Concurrency (computer science). Hämtat 28 december 2014

från Wikipedia: http://en.wikipedia.org/wiki/Concurrency_(computer_science)

Xiang, P., Hou, R., & Zhou, Z. (2010). Cache and Consistency in NoSQL. 2010 3rd IEEE

International Conference on Computer Science and Information Technology, 117-120.

doi:10.1109/ICCSIT.2010.5563525

Zahid, A., Masood, R., & Shibli, M. A. (2014). Security of Sharded NoSQL Databases: A

comparative analysis. Conference on Information Assurance and Cyber Security, 1-8.

doi:10.1109/CIACS.2014.6861323

Zaki, K. A. (2014). NoSQL DATABASES: NEW MILLENNIUM DATABASE FOR BIG

DATA, BIG USERS, CLOUD COMPUTING AND ITS SECURITY

CHALLENGES. International Journal of Research in Engineering and Technology,

403-409. eISSN:2319-1163

Zvarevashe, K., & Gotora, T. T. (2014). A Random Walk through the Dark Side of NoSQL

Databases in Big Data Analytics. International Journal of Science and Research, 3(6),

506-509. ISSN:2319-7064

Özcan, F., Tatbul, N., Abadi, D. J., Kornacker, M., Mohan, C., ... (2014). Are We

Experiencing a Big Data Bubble? 2014 ACM SIGMOD international conference on

Management of data, 1407-1408. doi:10.1145/2588555.2618215


53

Bilagor

Bilaga 1

Datum-

2014

Sökmotor Sökord Begränsning Sortering Övrig Urval

1

Urval

2

14 okt Google

Scholar

nosql 11 11

14 okt Google

Scholar

nosql 2013-2014 8 6

29 okt Google

Scholar

nosql, sql 2012-2014 3 2

29 okt Google

Scholar

nosql, sql 2014 6 5

29 okt IEEE

Xplore

NoSQL 2010-2014 2 2

29 okt ACM

Digital

Library

NoSQL 1 1

27 nov Summon "nosql"

"sql"

"compare

"

Relevans 7 6

27 nov Summon "nosql"

"sql"

"evaluati

on"

Relevans 3 2

27 nov Scopus "NoSQL

" "CAP"

2 2

28 nov Summon Cap Relevans Förf.:

Brewer

1 0

28 nov Summon Will

nosql

databases

Relevans Förf.:

Brewer

1 1

28 nov Compari

son of

NoSQL

and SQL

Database

s in the

Cloud

Klicka

vidare

på

länken

i

artikeln

1 1

28 nov History

Repeats

Itself:

Sensible

and

NonsenS

QL

Aspects

Klicka

vidare

på

länken

i

artikeln

1 1


54

of the

NoSQL

Hoopla

28 nov Summon 7 hard

truths

about the

nosql

Relevans Förf.:

wayner

2 2

28 nov Summon "the

dangers

of

replicatio

n and a"

Relevans Förf.:

helland

1 0

1 dec Google

Scholar

"NoSQL

"

"ACID"

Relevans 21 18

2 dec Summon "database

" "cap"

Computer

science

5 1

2 dec Summon "Distribu

ted

Database

"

Computer

science

8 4

9 dec Summon NoSQL

security

Fulltext,

tidningsartikel

,

tidskriftsartike

l, engelska,

engelska,

computer

science

2 1

10 dec Google

Scholar

NoSQL

security

Relevans 10 6

96 72


55

Bilaga 2

Artik

elNr Artikelnamn Författare

1

A comparison between serveral NoSQL

databases with comments and notes Tudorica Bogdan George, Bucur Cristian

2

A performance comparison of SQL and

NoSQL databased Li Yishan, Manoharan Sathiamoorthy

3

A Random Walk through the Dark Side of

NoSQL Databases in Big Data Analytics Zvarevashe Kudakwashe, Gotora Tatenda Trust

4 Are We Experiencing a Big Data Bubble?

Özcan Fatma, Tatbul Nesime, Abade Daniel J.,

Kornacker Marcel, Mohan C, Ramasamy Karthik,

Wiener Janet

5 Cache and Consistency in NoSQL Xiang Peng, Hou Ruichun, Zhou Zhiming

6

Can the Elephants Handle the NoSQL

Onslaught?

Floratou Avrilia, Teletia Nikhil, DeWitt David J.,

Patel Jignesh M., Zhang Donghui

7

Comparative Study of the New Generation,

Agile, Scalable, High Performance NoSQL

Databases

Tauro Clarence J. M., Aravindh S, Shreeharsha A.

B.

8 Comparing NoSQL MongoDB to an SQL DB Parker Zachary, Poe Scott, Vrbsky Susan V.

9

Comparative Analysis of Data Persistence

Technologies for Large-Scale Models Barmpis Konstantinos, Kolovos Dimitrios S.

10 Experimental evaluation of NoSQL databases

Abramova Veronika, Bernardino Jorge, Furtado

Pedro

11

NoSQL Database: A Scalable, Availability,

High Performance Storage for big Data Huang Yu, Luo Tiejian

12

Reduce, you say: What NoSQL can do for

Data Aggregation and BI in Large

Repositories

Bonnet Laurent, Laurent Anne, Sala Michel,

Laurent Bénédicte, Sicard Nicolas

13

Type of NoSQL Databases and its

comparison with relational databases Nayak Ameya, Poriya Anil, Poojary Dikshay

14

Comparison of the Frontier Distributed

Database Caching System to NoSQL

Databases Dykstra Dave

15 In Search of Database consistency Stonebraker Michael

16 NoSQL Everywhere? Not So Fast Kajeepeta Sreedha

17 NoSQL Systems for Big Data Management

Gudivada N Venkat, Rao Dhana, Raghavan Vijay

V

18 Relational vs. NoSQL Databases: A Survey

Mohamed A mohamed, Altarfi Obey G, Ismail

Mohammed O

19

The relational model is dead, SQL is dead,

and I don’t feel so good myself

Atzeni Paolo, Jensen Christian S, Orsi Giorgio,

Ram Sudha, Tanca Letizia, Torlone Riccardo

20

A Highlight of Security Challenges in Big

Data Osawaru Eweka Raphael, Ahamed Riyaz A.H

21

A security Requirements perspectiv towards a

secured NoSQL database Environment Kadebu Prudence, Mapanga Innocent

22

Will NoSQL databases live up to their

promise? Leavitt Neal

23

Evaluation of the cap properties on Amazon

SimpleDB and Windows Azure Table

Benefico Simone, Gjeci Eva, Comaransca

Gonzalez Ricardo, Lever Eros, Lombardo Santo,


56

Storage Ardagna Danilo, Di Nitto Elisabetta

24 7 hard truths about the NoSQL revolution bra Wayner Peter

25 NoSQL Burd Greg

26

Improving network systems performance by

clustering distributed database sites Hababeh Ismail

27

Performance and Scaling Comparison Study

of RDBMS and NoSQL(MongoDB) Shalini Merlin, Dhamodharan S

28

How to Store and Process Big Data: Are

Today’s Databases Sufficient Pokorný Jaroslav

29

NoSQL query processing system for wireless

ad-hoc and sensor networks Thantriwatte T.A.M.C, Keppetiyagama C.I

30

Review of NoSQL databases and

performance testing on HBase Naheman Wumuti, Wei Jianxin

31

Performance Evaluation of Unstructured

NoSQL data over distributed framework Nyati Suyog S, Pawar Shivanand, Ingle Rajesh

32

A comparison of a graph database and a

relational database, a data provenance

perspective

Vicknair Chad, Marcias Michael, Zhao

Zhendong, Nan Xiaofei, Chen Yixin, Wilkins

Dawn

33

Comparative study of NoSQL document,

column store databases and evaluation of

cassandra Manoj V

34

NoSQL databases: a step to database

scalability in web environment Pokorny Jaroslav

35

NoSQL vs RDBMS – Why there is room for

both

Nance Cory, Losser Travis, Iype Reenu, Harmon

Gary

36

Megastore: Providing scalable, highly

available storage for interactive services

Baker Jason, Bond Chris, Corbett James C,

Furman JJ, Khorlin Audrey, Larson James, Léon

Jean-Michel, Li Yawei, Lloyd Alexander,

Yushprakh Vladim

37

History repeats itself: Sensible and

NonsenSQL aspects of NoSQL hoopla Mohan C

38

Correlation aware technique for SQL to

NoSQL transformation

Hsu Jen-Chun, Hsu Ching-Hsien, Chen Shih-

Chang, Chung Yeh-Ching

39

Comparison of NoSQL and SQL databases in

the cloud

Hammes Dayne, Medero Hiram, Mitchell

Harrison

40

NoSQL Evaluation: A use case oriented

survey Hecht Robin, Jablonski Stefan

41

NoSQL database: New era of databases for

big data analytics – Classification,

Characteristics and Comparison Moniruzzaman A B M, Hossain Syed Akhter

42

Toward Scalable Security: On the Scalability

of Security in large-scale software systems Enescu Michael A.

43

Security of Sharded NoSQL Databases: A

comparative analysis

Zahid Anam, Masood Rahat, Shibli Muhammad

Awais

44

Quantitative Analysis and Implementation of

Relational and Graph Database Technologies Sharma Mukul, Soni Pradeep

45 NoSQL Databases: MongoDB vs Cassandra Abramova Veronica, Bernardino Jorge

46

Database Management Systems: A NoSQL

Analysis Kadebu Prudence, Mapanga Innocent

47

Improving Network Scalability Using NoSql

Database Bhatewara Ankita, Waghmare Kalyani

48 NoSQL DATABASES: NEW Zaki Khan Asadulla


57

MILLENNIUM DATABASE FOR BIG

DATA, BIG USERS, CLOUD

COMPUTING AND ITS SECURITY

CHALLENGES

49 Scalable SQL and NoSQL Data Stores Cattell Rick

50

Sensor Data Storage Performance: SQL or

NoSQL, Physical or Virtual

van der Veen Jan Spike, van der Waaij Bram,

Meijer Robert J.

51

Speaking in Tongues: SQL Access to NoSQL

Systems

Rith Julian, Lehmayr Phillipp S, Meyer-Wegener

Klaus

52 SQL Databases v. NoSQL Databases Stonebreaker Michael

53 Stonebraker on NoSQL and Enterprises Stonebreaker Michael

54 Survey on NoSQL Database Han Jing, E Haihong, Le Guan, Du Jian

55 SQL vs. NoSQL Bartholomew Daniel

56 Database Research: Are We At A Crossroad? Indrawan-Santiago Maria

57

TEMPORAL DATA MANAGEMENT IN

NOSQL DATABASES

Monger Morgan D, Mata-toledo Ramon A.,

Gupta Pranshu

58

The Development of a Benchmark Tool for

NoSQL Databases Lungu Ion, Tudorica Bogdan George

Documents

NoSQL!787545/... · 2015. 2. 10. · NoSQL databaser i Web 2.0 applikationer hos etablerade företag såsom Google, Amazon och Facebook (Moniruzzaman & Hossain, 2013). Enligt (Parker,