Fulltext
Ö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 Affärsdata Concurrency Förklaring Data som kan användas till att utvinna affärsnyttig information för ett företag. Term inom datavetenskapen som betyder att flera beräkningar ska kunna utföras och samarbeta samtidigt (Wikipedia, 2014). En informationssamling av flera källor, så som analyser och modeller. Datalager 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.). När två eller fler uppgifter permanent blockerar varandras utförande. I Deadlocks 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ö Molnet Skalbarhet Är ett kluster av sammankopplade datorer via internet eller andra typer av nätverk för lagring av data (BuissnessDictionary.com, n.d.). 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. 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). Structured Query Language är det frågespråket som är standard för relationsdatabaser. De olika relationsdatabaserna som existerar har SQL skillnader i sina frågespråk men de följer alla en gemensam ISOstandard från 2003, den så kallade SQL:2003 (Padron-McCarthy & Risch, 2005a). Ett samlingsbegrepp för internettjänster, så som bloggar, wikis Web 2.0 (användarberoende internetbaserade uppslagsverk) sociala medier med mera (BuissnessDictionary.com, n.d.). NoSQL! Med rätt att finnas? 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 1 NoSQL! Med rätt att finnas? 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. 2 NoSQL! Med rätt att finnas? 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. 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.). 2 3 NoSQL! Med rätt att finnas? 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). 4 NoSQL! Med rätt att finnas? 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). 5 NoSQL! Med rätt att finnas? 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 6 NoSQL! Med rätt att finnas? 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 7 NoSQL! Med rätt att finnas? 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". 8 NoSQL! Med rätt att finnas? 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. 9 NoSQL! Med rätt att finnas? 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 10 NoSQL! Med rätt att finnas? 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. Urval 1 96 Urval 2 72 Urval 3 58 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 11 NoSQL! Med rätt att finnas? 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 12 NoSQL! Med rätt att finnas? 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 (+ & -) 13 NoSQL! Med rätt att finnas? 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 forskningseller 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. 14 NoSQL! Med rätt att finnas? 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. 15 NoSQL! Med rätt att finnas? 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. 16 NoSQL! Med rätt att finnas? 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. 17 NoSQL! Med rätt att finnas? 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 (PadronMcCarthy, 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. 18 NoSQL! Med rätt att finnas? 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. 19 NoSQL! Med rätt att finnas? Tabell 1. Resultatet av artikelmappningen. Koncept ArtikelNr 1 2 3 4 5 6 7 8 9 10 11 A B C - + + + + + + + D E F G - + + + +&- + + + + 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 + + + + + + - + + + + + + J - - - K L + + - I + + H + + + - + + + + + + + + - + + + +&- + + + - + - + + + + + + + + - + + + + + + + + + + + + + + + - + + + + + + + + + + + - - +&- + +&- - - - - + + + + + + + + + + + - - - - - - - - - - + + - + + + + - - + + + + + + - + - + + + + - + + + - + + + + + + + + + - + + + +&- + - + + + + + + + + + - + + + + 20 NoSQL! Med rätt att finnas? 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). 21 NoSQL! Med rätt att finnas? 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 22 NoSQL! Med rätt att finnas? 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). 23 NoSQL! Med rätt att finnas? 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. 24 NoSQL! Med rätt att finnas? 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. 25 NoSQL! Med rätt att finnas? 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). 26 NoSQL! Med rätt att finnas? 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. 27 NoSQL! Med rätt att finnas? 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", "anamn", "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 28 NoSQL! Med rätt att finnas? 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. 29 NoSQL! Med rätt att finnas? 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 (IndrawanSantiago, 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å 30 NoSQL! Med rätt att finnas? 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). 31 NoSQL! Med rätt att finnas? 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 32 NoSQL! Med rätt att finnas? 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 33 NoSQL! Med rätt att finnas? 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. 34 NoSQL! Med rätt att finnas? 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 35 NoSQL! Med rätt att finnas? 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 36 NoSQL! Med rätt att finnas? 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. 37 NoSQL! Med rätt att finnas? 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). 38 NoSQL! Med rätt att finnas? 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. 39 NoSQL! Med rätt att finnas? 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 40 NoSQL! Med rätt att finnas? 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 41 NoSQL! Med rätt att finnas? "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 42 NoSQL! Med rätt att finnas? 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, 43 NoSQL! Med rätt att finnas? 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. 44 NoSQL! Med rätt att finnas? 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/pressreleases/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 45 NoSQL! Med rätt att finnas? 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-environmentDCE.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 46 NoSQL! Med rätt att finnas? 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), 1218. 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 47 NoSQL! Med rätt att finnas? 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/enus/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 48 NoSQL! Med rätt att finnas? 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-010A%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 49 NoSQL! Med rätt att finnas? 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-3662-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 50 NoSQL! Med rätt att finnas? 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&seiredir=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%3DqF6vVNCpCefygObyYCoBA%26ved%3D0CB0QgQMwAA#search=%22ANALYZING%20PAST 51 NoSQL! Med rätt att finnas? %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 52 NoSQL! Med rätt att finnas? Bilagor Bilaga 1 Datum- Sökmotor Sökord Begränsning Sortering Övrig Urval Urval 1 2 2014 27 nov Google Scholar Google Scholar Google Scholar Google Scholar IEEE Xplore ACM Digital Library Summon 27 nov Summon 27 nov Scopus 28 nov Summon 28 nov Summon 14 okt 14 okt 29 okt 29 okt 29 okt 29 okt 28 nov 28 nov nosql 11 11 nosql 2013-2014 8 6 nosql, sql 2012-2014 3 2 nosql, sql 2014 6 5 NoSQL 2010-2014 2 2 1 1 NoSQL "nosql" "sql" "compare " "nosql" "sql" "evaluati on" "NoSQL " "CAP" Cap Relevans 7 6 Relevans 3 2 2 2 1 0 Will nosql databases Compari son of NoSQL and SQL Database s in the Cloud History Repeats Itself: Sensible and NonsenS QL Aspects Relevans Förf.: Brewer Förf.: Brewer 1 1 Klicka vidare på länken i artikeln 1 1 Klicka vidare på länken i artikeln 1 1 Relevans 53 NoSQL! Med rätt att finnas? 28 nov Summon 28 nov Summon of the NoSQL Hoopla 7 hard truths about the nosql "the Relevans Förf.: wayner 2 2 Relevans Förf.: helland 1 0 21 18 Computer science Computer science 5 1 8 4 Fulltext, tidningsartikel , tidskriftsartike l, engelska, engelska, computer science 2 1 10 6 96 72 dangers of replicatio n and a" 1 dec Google Scholar 2 dec Summon 2 dec Summon 9 dec Summon 10 dec Google Scholar "NoSQL " "ACID" "database " "cap" "Distribu ted Database " NoSQL security NoSQL security Relevans Relevans 54 NoSQL! Med rätt att finnas? Bilaga 2 Artik elNr 3 Artikelnamn A comparison between serveral NoSQL databases with comments and notes A performance comparison of SQL and NoSQL databased A Random Walk through the Dark Side of NoSQL Databases in Big Data Analytics 4 Are We Experiencing a Big Data Bubble? 5 Cache and Consistency in NoSQL Can the Elephants Handle the NoSQL Onslaught? Comparative Study of the New Generation, Agile, Scalable, High Performance NoSQL Databases 1 2 6 7 8 Författare Tudorica Bogdan George, Bucur Cristian Li Yishan, Manoharan Sathiamoorthy Zvarevashe Kudakwashe, Gotora Tatenda Trust Özcan Fatma, Tatbul Nesime, Abade Daniel J., Kornacker Marcel, Mohan C, Ramasamy Karthik, Wiener Janet Xiang Peng, Hou Ruichun, Zhou Zhiming Floratou Avrilia, Teletia Nikhil, DeWitt David J., Patel Jignesh M., Zhang Donghui Tauro Clarence J. M., Aravindh S, Shreeharsha A. B. 14 Comparing NoSQL MongoDB to an SQL DB Parker Zachary, Poe Scott, Vrbsky Susan V. Comparative Analysis of Data Persistence Technologies for Large-Scale Models Barmpis Konstantinos, Kolovos Dimitrios S. Abramova Veronika, Bernardino Jorge, Furtado Experimental evaluation of NoSQL databases Pedro NoSQL Database: A Scalable, Availability, High Performance Storage for big Data Huang Yu, Luo Tiejian Reduce, you say: What NoSQL can do for Data Aggregation and BI in Large Bonnet Laurent, Laurent Anne, Sala Michel, Repositories Laurent Bénédicte, Sicard Nicolas Type of NoSQL Databases and its comparison with relational databases Nayak Ameya, Poriya Anil, Poojary Dikshay 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 17 NoSQL Systems for Big Data Management 18 Relational vs. NoSQL Databases: A Survey The relational model is dead, SQL is dead, and I don’t feel so good myself A Highlight of Security Challenges in Big Data A security Requirements perspectiv towards a secured NoSQL database Environment Will NoSQL databases live up to their promise? Evaluation of the cap properties on Amazon SimpleDB and Windows Azure Table Kajeepeta Sreedha Gudivada N Venkat, Rao Dhana, Raghavan Vijay V Mohamed A mohamed, Altarfi Obey G, Ismail Mohammed O Atzeni Paolo, Jensen Christian S, Orsi Giorgio, Ram Sudha, Tanca Letizia, Torlone Riccardo 9 10 11 12 13 19 20 21 22 23 Osawaru Eweka Raphael, Ahamed Riyaz A.H Kadebu Prudence, Mapanga Innocent Leavitt Neal Benefico Simone, Gjeci Eva, Comaransca Gonzalez Ricardo, Lever Eros, Lombardo Santo, 55 NoSQL! Med rätt att finnas? Storage Ardagna Danilo, Di Nitto Elisabetta 24 7 hard truths about the NoSQL revolution bra Wayner Peter 25 NoSQL Improving network systems performance by clustering distributed database sites Performance and Scaling Comparison Study of RDBMS and NoSQL(MongoDB) How to Store and Process Big Data: Are Today’s Databases Sufficient NoSQL query processing system for wireless ad-hoc and sensor networks Review of NoSQL databases and performance testing on HBase Performance Evaluation of Unstructured NoSQL data over distributed framework A comparison of a graph database and a relational database, a data provenance perspective Comparative study of NoSQL document, column store databases and evaluation of cassandra NoSQL databases: a step to database scalability in web environment NoSQL vs RDBMS – Why there is room for both 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 Megastore: Providing scalable, highly available storage for interactive services History repeats itself: Sensible and NonsenSQL aspects of NoSQL hoopla Correlation aware technique for SQL to NoSQL transformation Comparison of NoSQL and SQL databases in the cloud NoSQL Evaluation: A use case oriented survey NoSQL database: New era of databases for big data analytics – Classification, Characteristics and Comparison Toward Scalable Security: On the Scalability of Security in large-scale software systems Security of Sharded NoSQL Databases: A comparative analysis Quantitative Analysis and Implementation of Relational and Graph Database Technologies Burd Greg Hababeh Ismail Shalini Merlin, Dhamodharan S Pokorný Jaroslav Thantriwatte T.A.M.C, Keppetiyagama C.I Naheman Wumuti, Wei Jianxin Nyati Suyog S, Pawar Shivanand, Ingle Rajesh Vicknair Chad, Marcias Michael, Zhao Zhendong, Nan Xiaofei, Chen Yixin, Wilkins Dawn Manoj V Pokorny Jaroslav Nance Cory, Losser Travis, Iype Reenu, Harmon Gary Baker Jason, Bond Chris, Corbett James C, Furman JJ, Khorlin Audrey, Larson James, Léon Jean-Michel, Li Yawei, Lloyd Alexander, Yushprakh Vladim Mohan C Hsu Jen-Chun, Hsu Ching-Hsien, Chen ShihChang, Chung Yeh-Ching Hammes Dayne, Medero Hiram, Mitchell Harrison Hecht Robin, Jablonski Stefan Moniruzzaman A B M, Hossain Syed Akhter Enescu Michael A. Zahid Anam, Masood Rahat, Shibli Muhammad Awais Sharma Mukul, Soni Pradeep 47 NoSQL Databases: MongoDB vs Cassandra Abramova Veronica, Bernardino Jorge Database Management Systems: A NoSQL Analysis Kadebu Prudence, Mapanga Innocent Improving Network Scalability Using NoSql Database Bhatewara Ankita, Waghmare Kalyani 48 NoSQL DATABASES: NEW 46 Zaki Khan Asadulla 56 NoSQL! Med rätt att finnas? MILLENNIUM DATABASE FOR BIG DATA, BIG USERS, CLOUD COMPUTING AND ITS SECURITY CHALLENGES 49 51 Scalable SQL and NoSQL Data Stores Sensor Data Storage Performance: SQL or NoSQL, Physical or Virtual Speaking in Tongues: SQL Access to NoSQL Systems Cattell Rick van der Veen Jan Spike, van der Waaij Bram, Meijer Robert J. 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? TEMPORAL DATA MANAGEMENT IN NOSQL DATABASES The Development of a Benchmark Tool for NoSQL Databases Indrawan-Santiago Maria Monger Morgan D, Mata-toledo Ramon A., Gupta Pranshu 50 57 58 Lungu Ion, Tudorica Bogdan George 57
© Copyright 2024