UMEÅ UNIVERSITET

JAMFORELSE MELLAN ORACLERDBMS, ORACLE NOSQL OCH

MONGODB

Jorgen BygdemarkAndreas Arvidsson

Kandidatexamen, 15 hpDatavetenskap

2019

Jamforelse mellan Oracle RDBMS, Oracle NoSql och MongoDB

Sammanfattning

Databaser forekommer overallt i vart moderna samhalle och mangden data okarstandigt, vilket innebar a� det har blivit viktigare an nagonsin a� hi�a sa� a�hantera massiva mangder med data pa e� e�ektivt sa�. NoSQL-databaser1 harutvecklats for a� kunna losa just de�a problem genom a� e�ektivt lagra storamangder data och ge snabb atkomst till det datat. E�ersom NoSQL-databaserbara borjat bli populara inom de senaste tio aren har de inte blivit lika valundersokta som relationsdatabaser. Darfor ska en utvardering utforas pa sexutmarkande egenskaper dar en av delarna utgor jamforande av prestandatester.De ovriga egenskaperna ar: skalbarhet, konsistens, tillganglighet, hallbarhet ochtillforlitlighet. MongoDB och Oracle NoSQL ar NoSQL-databaserna som anvandsoch tillsammans med Oracle RDBMS som relationsdatabas utgor dessa tre grun-den till en jamforande undersokning.

Det visade sig a� det �nns stora skillnader mellan hur data hanteras iNoSQL jamfort med relationsdatabaser som paverkar valet av databas, somt.ex. a� NoSQL prioriterar a� klienter kan na databasen over a� data skavara motsagelsefri och a� genom lagre krav pa transaktionshanteringen gynnaprestanda och datalagringsformaga. Vidare visade prestandatesterna a� badaNoSQL-databaserna i de �esta fall var snabbare an relationsdatabasen oavse�storlek pa datamangden. MongoDB var klart den snabbaste pa lasoperationer,medan Oracle NoSQL utforde skrivoperationer snabbast for det mesta. BadaNoSQL-databasernas prestanda paverkas mindre av en vaxande datamangd anvad relationsdatabasen gor bade for las-och skrivoperationer.

1Star for ”Not Only SQL” och bor inte forvaxlas med ovriga databaser som inte anvander SQL som t.ex. hier-arkiska databaser

Comparing Oracle NoSql and MongoDB to Oracle RDBMS

Abstract

Databases are present everywhere in our modern society and the amount of datathat have to be stored is constantly increasing, which means that it’s now moreimportant than ever to be able to handle massive data sets e�ectively. NoSQLdatabases2 were developed to solve this problem by e�ciently storing largeamounts of data and enable fast access to that data. Since NoSQL databases onlybecame popular within the last ten years, they haven’t been as well researchedas relational databases. An in-depth evaluation is carried out on six distinct fea-tures, where one part is comparative performance tests. �e other features are:scalability, consistency, availability, durability and reliability. MongoDB and Or-acle NoSQL are the NoSQL databases used and together with Oracle RDBMS asrelational database make up the basis for a comparative study of the above men-tioned features.

�e results showed that there are big di�erences between how data is handled inNoSQL compared to relational databases that will a�ect the choice of database,e.g. that NoSQL tends to prioritize that clients can reach the database over non-contradictory data and lowering the demands on transaction management toincrease performance and storage capacity. Furthermore, the performance testsshowed that both NoSQL databases performed be�er than the relational databaseregardless of the data set size. MongoDB was clearly the fastest on reading oper-ations, while Oracle NoSQL performed write operations the fastest most of thetime. Both NoSQL databases are impacted less by a growing data set than therelational database for both read and write operations.

2stands for ”Not Only SQL” and are not to be confused with other databases that also don’t use SQL, e.g.hierarchical databases

Forfattarnas tack

Vi vill tacka Ska�everket for hjalpen med projektet, for a� de bidrog med material, exempel-data och arbetsplatser. E� sarskilt tack gar till Peter Backstrom for givande samtal och diskus-sioner. Vi riktar aven e� tack till var handledare pa Umea Universitet Kai-Florian Richter forhans insiktsfulla bidrag till vart arbete.

Innehallsforteckning

1 Introduktion 1

1.1 Sy�e och fragestallning 2

1.2 Omfang och avgransningar 2

1.2.1 Forvantade resultat 2

2 Teoretisk bakgrund 3

2.1 Relationsdatabaser 3

2.1.1 ACID-egenskaperna 3

2.2 NoSQL-databaser 4

2.2.1 BASE-egenskaper 4

2.3 Skillnader 4

2.4 Egenskaper av RDBMS och NoSQL 5

2.4.1 Skalbarhet 5

2.4.2 Tillganglighet 6

2.4.3 Konsistens 6

2.4.4 Hallbarhet 7

2.4.5 Tillforlitlighet 7

3 Metod 9

3.1 Metodval 9

3.2 Datainsamling 10

3.3 Hardvara och mjukvara 10

3.3.1 Databaser 10

3.4 Testdata 10

3.5 �eries som har testats 11

4 Resultat & analys 15

4.1 Skalbarhet 15

4.2 Konsistens 15

4.3 Tillganglighet 16

4.4 Hallbarhet 18

4.5 Tillforlitlighet 19

4.6 Prestanda 19

5 Diskussion 27

5.1 Begransningar 28

5.2 Slutsats och rekommendationer 29

5.3 Vidare arbete 30

Kallforteckning 31

A Appendix 35

1 Introduktion

Relationsdatabaser hanteras av e� Relational DataBase Managemenet System (RDBMS). PaOracles hemsida [1] beskrivs a� en typisk DBMS innehaller bland annat: DBMS-karnkod fora� hantera minne och lagring, metadata over tabeller och databasen och e� query-sprak. EnRDBMS maste folja en ”relationsmodell”, vilket har: valde�nierade objekt som lagrar och gertillgang till data i databasen, tydliga funktioner som tillater applikationer a� paverka data ochstrukturer i databasen, samt integritetsregler som reglerar funktioner pa data och strukturer.I grund och bo�en ar RDBMS amnad a� �y�a data till en databas, lagra data samt hamta datasa det kan paverkas av applikationer.

Abramova och Bernardino [2] tar i sin studie upp historiken for NoSQL. Termen “NoSQL”anvandes for forsta gangen ar 1998 av Carlo Strozzi for a� namnge hans enkla open-source-relationsdatabas som inte anvande sig av det vanliga SQL standardinterfacet, men �ck intenagot storre genombro� vid denna tid. Termen introducerades senare pa ny� i e� forsok a�namnge den okande mangden av relationslosa databaser som inte erbjuder samma transak-tionsgarantier som traditionella relationsdatabaser. Anvandningen av NoSQL okade betydligti samband med vissa foretags uppgang pa Internet, t.ex. Google och Facebook. Dessa foretagstalldes infor nya datahanteringsproblem, som t.ex. e�ektiv hantering av miljontals dataob-jekt och stora mangder ostrukturerad data, som inte kunde hanteras av en traditionell databas.

Trots a� NoSQL-modellerna har e� klart overtag nar det kommer till a� hantera mas-siva mangder data och erbjuda hog prestanda ar det inte nodvandigtvis den losningensom situationen jamt kraver. I vissa fall kravs en mycket strikt transaktionshanteringsom sakerstaller a� korrekt och den senast uppdaterade datan alltid returneras, som tillexempel i banksystem dar traditionella relationsdatabaser o�ast ar ba�re lampade. Lourenco,Cabral, Carreiro, och Vieira [3] visar a� det �nns hundratals olika NoSQL-losningar pamarknaden som inriktar sig till olika anvandningsomraden beroende pa anvandarens data-och prestandakrav. De �esta NoSQL-losningarna har hog prestanda men da pa bekostnad avandra viktiga delar. E� exempel pa de�a ar vilken grad av korrekthet datan har vid varje nylasning, det vill saga om en uppdatering av e� objekt i databasen maste utforas i sin helhetoch sparas pa disk innan en ny lasning av samma objekt kan utforas. A� tillata nya lasningarinnan varje uppdatering ar klar okar prestandan pa lasoperationerna men medfor risken a�datan som returnerats inte ar den senaste versionen. Denna egenskap handlar om vilkengrad av konsistens databasen erbjuder och ar bara e� exempel pa skillnader som forekommermellan olika losningar.

A� NoSQL-databaser ar betydligt enklare a� utoka (vanligtvis kallat a� skala upp) ar enav de viktigaste egenskaperna som gor a� anvandare valjer en NoSQL-databas. Men a�utoka databasen paverkar ocksa prestandan oavse� om utokningen ar for a� hantera mangaanvandare samtidigt eller stora mangder data. Hur denna sa kallade ”skalbarhet” hanteras arnagot som skiljer sig mellan olika NoSQL-databaser.

I en tidigare utford studie forsoker Lourenco, Cabral, Carreiro, och Vieira[3] besvara vilkenNoSQL-losning man bor valja beroende pa anvandningsomrade. I det arbetet har de identi-

1

�erat e� antal egenskaper som enligt dem tacker en storre del vanligt forekommande mjuk-varuscenarion och som bor utvarderas for a� avgora hur en speci�k NoSQL-databas hanterardessa egenskaper. De viktigaste egenskaperna ar skalbarhet, konsistens, tillganglighet,hallbarhet, tillforlitlighet och prestanda.

1.1 Sy�e och fragestallning

Sy�et med denna studie ar dels a� utvardera skillnader mellan databaserna och dels a� geforslag pa passande anvandningsomraden baserat pa resultaten.

Fragestallning

Utifran problemstallningen kommer vi besvara foljande fragestallning:

• Hur skiljer sig MongoDB, Oracle NoSQL och Oracle RDBMS gallande egenskapernaskalbarhet, konsistens, tillganglighet, hallbarhet, tillforlitlighet och prestanda?

• For vilka anvandningsomraden passar en NoSQL-databas ba�re an en traditionell rela-tionsdatabas utifran dessa skillnader?

1.2 Omfang och avgransningar

Vi har valt a� ta med tre olika databaser i var studie: Oracle RDBMS, Oracle NoSQL ochMongoDB. A� vi valt just dessa ar for a� var samarbetspartner, Ska�everket, anvander framstOracle RDBMS vilket aven ger oss tillgang till Oracle NoSQL. De�a tyckte vi aven kandesrelevant och intressant da varken Oracle NoSQL eller Oracle RDBMS forekommer sarskilto�a i tidigare utford forskning. Vidare har vi valt a� aven ta med MongoDB da den ar envanligt forekommande losning med mycket tillganglig li�eratur samt a� den lagrar datan idokument istallet for rader och kolumner vilket kandes lampligt da vi framst var intresseradeav a� jobba med data lagrade i dokument pa JSON-format, vilket ar e� �lformat som lagrardata i textform.

1.2.1 Forvantade resultat

Studien bestar av tva moment, dels en teoretisk analys som forvantas bidra med informationsom beskriver olika egenskaper och skillnader mellan Oracle RDBMS, Oracle NoSQL ochMongoDB. Den andra delen bestar av prestandatester for e� antal operationer utforda pa detre databaserna. Resultaten fran dessa tester forvantas visa pa skillnader i prestanda for de tredatabaserna.

Informationen fran dessa tva delar forvantas sedan resultera i a� kunna presentera hur de tredatabaserna som omfa�as av studien skiljer sig at gallande egenskaperna i fragestallningenoch genom dessa kunna ge forslag pa anvandningsomraden dar MongoDB och/eller OracleNoSQL skulle passa ba�re an Oracle RDBMS.

2

2 Teoretisk bakgrund

I denna sektion ges en oversiktlig beskrivning av de olika typer av databaser som ingar.Det beskrivs hur de olika typerna fungerar och ar uppbyggda i mer generella drag. Vidarepresenteras e� antal utmarkande skillnader mellan de speci�ka databaserna som kommerutvarderas i studien.

”Massiva datamangder” tas upp i denna studie, men det �nns ingen konsensus angaende engrans dar en datamangd gar fran a� vara liten till a� vara stor eller massiv. I denna studieanvander vi betackningen massiva datamangder nar antalet objekt overstiger en miljon.

2.1 Relationsdatabaser

Relationsdatabaser innehaller e� antal relationer (tabeller) som i sin tur innehaller en mangdtuppler (rader) innehallande en mangd varden. E� relationsschema innehaller namngivnaa�ribut (kolumner) som ar en mangd av atomara datatyper (t.ex. numeriska, strangar, tidetc.). Vidare med hjalp av a� skapa begransningar kan data och referenser forbli konsekventa.Begransningarna kan till exempel innebara a� vissa varden inte far forekomma under vissaa�ribut, eller a� forandringar av en tuppel i en relation inte tillats pa grund av a� andratuppler i andra relationer refererar till den andrade tuppeln. Ifall sadana begransningar brytsav en operation visas felmeddelanden och operationen i fraga utfors inte. Se Melton [4] foren detaljerad beskrivning.

E� problem som relationsdatabaser tenderar a� stota pa, som Chandra beskriver i [5], ar a�prestanda forsamras allt e�ersom databasens innehall okar. De�a kan losas genom vertikalskalning, vilket innebar a� utoka kra�en (RAM och CPU) hos den maskin som innehallerdatabasen. De�a ar dock kostsamt och kan bli svart pa grund av hardvarubegransningar.

Structured �ery Language, eller SQL, ar e� deklarativt sprak for a� hamta data som hanterasav en relationsdatabas. De�a innebar a� anvandare endast behover speci�cera vad sombehover hamtas, och inte hur det ska ga till.

2.1.1 ACID-egenskaperna

Garcia-Molina, Ullman och Widom [6] beskriver hur en DBMS behover nagon typ av transak-tionshanterare som kan ta emot �era samtidiga transaktioner fran anvandare. Dessa transak-tioner bestar av en serie operationer mot en given databas. Transaktioner sags vara ordentligtimplementerade om de har dessa fyra egenskaper:

• Atomicity - alla operationer i transaktionen lyckas, annars forkastas transaktionen i sinhelhet

• Consistency - transaktioner far inte bryta mot relationsregler (eller liknande) inom endatabas

3

• Isolation - varje transaktion maste exekveras som om ingen ovrig transaktion exekver-ades samtidigt

• Durability - forsakrar a� andringarna som utfordes av en transaktion inte forsvinner

2.2 NoSQL-databaser

NoSQL de�nieras som en icke-relationell databastyp som uppstod av behovet a� kunnalagra stora mangder information pa e� mindre strukturerat sa� an vad som de�nierar enrelationsdatabas [7] som gav upphov till termen ”NoSQL”. De�a anses idag sta for ”Not onlySQL” och sy�ar till a� det strukturerade programspraket SQL inte anvands for a� hanteradata i databasen, aven om det �nns exempel dar liknande eller delar av SQL anvands.

Till skillnad fran relationsdatabaser ar NoSQL inte uppbyggt av tabeller och kolumnersom foljer strikta scheman utan ar istallet schemalost vilket ger anvandaren en betydligtstorre frihet a� skapa dynamiska datasamlingar och forenkla skapande och omstrukturerandeav a�ribut.

2.2.1 BASE-egenskaper

Till skillnad fran relationsdatabaser som foljer ACID, beskriver Chandra [5] a� NoSQL-databaser foljer BASE for transaktioner. Denna paradigm baseras pa fallet dar data ar dis-tribuerad och datasynkronisering inte langre ar praktiskt. Till skillnad fran ACID kraver inteBASE exakta/tidsendliga varden, dock dyker en ny utmaning upp: hur ska distribuerad datauppdateras nar datat kan ta en mangd oforutsedda vagar? Det ar komplicerat a� bygga enNoSQL-databas som foljer ACID, vilket leder till a� BASE forsummar ACID-egenskapernaConsistency och Isolation for a� framja tillganglighet och prestanda vilket innebar a� utveck-larna far ansvaret a� uppra�halla motsagelsefri data. Beskrivningen av BASE ges i [5, 8] avChandra respektive Pokorny och star for:

• Basically Available innebar a� databasen ser ut a� fungera jamt fran applikationsper-spektivet, da det ska alltid ga a� na den e�erfragade datan trots a� e� antal servrar arur funktion.

• So� state som betyder a� data behover inte vara konsistent hela tiden, och kan forandrasmed tiden aven utan input fran anvandare tack vare nasta punkt:

• Eventually consistent, som innebar a� lagringssystemet garanterar a� ifall inga nya up-pdateringar gors pa e� objekt inom en viss tid, kommer de senaste uppdaterade vardeta� spridas till resterande maskiner.

2.3 Skillnader

For a� ge en oversiktligt bild pa de olika databaserna som omfa�as av denna studie presen-teras i tabell 1 information fran e� antal tidigare utforda studier [9, 10, 11, 12].

4

Tabell 1 Skillnader mellan Oracle RDBMS, MongoDB och Oracle NoSQL

A�ribut Oracle RDBMS MongoDB Oracle NoSQLDatarepresentation Tabeller Dokument Nyckel-vardeImplementationssprak C och C++ C++ JavaSchema Fixerade Dynamiskt DynamisktBASE eller ACID ACID BASE ACIDSkalning Vertikal Vertikal och horisontell Vertikal och horisontell�erysprak SQL Javascript Javascript samt stod for SQL

I appendix A presenteras en jamforelse av e� antal aspekter som tagits fram fran en mangdstudier [9, 11, 13, 14] och som visar mer generella skillnader mellan relationella och icke-relationella (NoSQL) databaser.

2.4 Egenskaper av RDBMS och NoSQL

Lourenco, Cabral, Carreiro, Vieira och Bernardino [3] diskuterar i sin artikel a� NoSQL-databaser bestar av e� stort antal olika egenskaper och a� det kan vara svart a� avgora vilkasom ar relevanta a� utvardera for a� tacka en storre del av potentiella anvandningsomraden.I artikeln foreslas e� ramverk for utvardering innehallande e� antal utvalda egenskaper somenligt forfa�aren tacker en bred mangd av distinkta mjukvaruscenarion. De�a stods av andrastudier i amnet som utvarderar dessa eller en delmangd av dessa egenskaper. Nedan foljerforklaringar av de egenskaper som kommer a� omfa�as i denna studie.

2.4.1 Skalbarhet

Mojligheten a� pa e� e�ektivare sa� kunna bygga ut e� system ar en av de viktigaste anled-ningarna till a� NoSQL databaser borjade utvecklas fran borjan da de�a ar nagot som ar badekomplext och dyrt for en relationsdatabas. A� bygga ut systemet kallas i databaskontext fora� ”skala ut” och de�a gar a� utfora pa tva olika sa� (se �g. 1):

• Horisontell skalning, vilket innebar a� lagga till �er maskiner eller servrar, o�a kalladenoder.

• Vertikal skalning, vilket ar a� uppgradera eller utoka be�ntlig hardvara.

5

Figur 1: Skalning av databaser

Orend [15] beskriver a� termen skalbarhet inte sy�ar pa hur val e� system kan byggas ut,utan innebar i denna kontext hur val e� system kan hantera en okande arbetsbelastning. Merspeci�kt, om systemet gar a� skala utan nagon allvarlig forsamring av prestandan. Anlednin-gen till a� behova skala e� system har olika grunder beroende pa vilken typ av applikationdet galler, vissa behover hantera e� stort antal anvandare samtidigt medan andra behoverhantera en okande datamangd. De �esta NoSQL databaserna idag forlitar sig pa horisontelloch elastisk skalning. Elastiskt betyder i de�a sammanhang hur val e� system kan hanteraa� en nod inom e� kluster av noder kopplar upp och ner under dri�.

2.4.2 Tillganglighet

Tillganglighet betyder i vilken utstrackning e� system ar bade fungerande och atkomligtnar det behover anvandas [16]. I fallet dar endast en databasserver ar narvarande raknas e�dataobjekt som otillgangligt om: servern far for manga forfragningar sa det antingen ej kanhanteras eller tar for lang tid a� hanteras, eller om databasnoden misslyckas.

E� sa� a� hantera overbelastning ar a� skala systemet vertikalt sa a� det kan hantera �erklienter per tidsintervall. De�a blir dock valdigt dyrt e�ersom kra�en i systemet inte okarlinjart med kostnaderna samt a� det kan fortfarande forekomma overbelastning da det �nnsbegransningar i hur mycket det gar a� skala vertikalt. Det ar aven viktigt a� notera a� en-dast vertikal skalning av en nod inte hindrar den fran a� bara sluta fungera (aven om detbara skulle vara tillfalligt), vilket ar nagot som kan hanteras av a� lagga till �er noder (ho-risontell skalning) och dela upp datamangden mellan dem vilket kan minska belastningen paindividuella servrar.

Men a� skala e� system horisontellt och dela upp datamangden mellan noderna hindrar intea� e� speci�kt databobjekt kan bli otillgangligt ifall noden den lagras i misslyckas, alltsahar inte tillgangligheten for just det dataobjektet forba�rats. For a� oka tillgangligheten fore� dataobjekt maste det replikeras och lagras i �era noder, sa a� en inkommande forfragantill en otillganglig nod istallet skickas till en annan nod. Men nar det �nns �era kopior ave� dataobjekt dyker det upp e� ny� problem, namligen hur konsistens ska behallas mellankopiorna.

2.4.3 Konsistens

Enligt Lourenco, Cabral, Carreiro, Vieira och Bernardino [3] �nns ingen universellt accepteradde�nition for konsistens, men kan enligt forfa�arna ses som en garanti for a� framtida

6

transaktioner ser uppdateringar gjorda pa data av tidigare transaktioner. De�a kan tolkas soma� det i transaktionshantering ska �nnas e� tillatet tillstand i borjan och i slutet av transaktio-nen dar varje nod i systemet ser samma data. Brewer [17] beskriver a� inom NoSQL-systemar konsistens starkt kopplat till tillganglighet som tidigare diskuterats och o�a maste konsis-tensen o�ras for en hog tillganglighet, men det ar inte nodvandigt a� utan e�ertanke overgeden ena for den andra e�ersom det ar mer av en avvagning mellan dessa. Manga NoSQL-system foljer BASE-egenskaperna (se kapitel 2.2.1) och enligt dessa garanteras konsistensinte omedelbart, utan endast sa smaningom, men i praktiken erbjuder de �esta systemen enstallbar konsistens niva.

2.4.4 Hallbarhet

Lourenco, Cabral, Carreiro, Vieira och Bernardino beskriver a� “hallbarhet sy�ar till kraveta� data ska vara valid och skriven till disk e�er en korrekt utford transaktion” [3]. Som tidi-gare diskuterats (2.4.3) erbjuder NoSQL-losningar o�a en stallbar konsistensniva och o�rardarmed konsistens for a� istallet kunna erbjuda en hog tillganglighet da de�a anses viktigarei verkliga anvandningsscenarion. De�a paverkar hallbarheten da konsistensproblem poten-tiellt kan innebara dataforluster.

2.4.5 Tillforlitlighet

J. Domaschka, C. B. Hauser och B. Erb [16] beskriver a� tillforlitlighet mojliggor en kompo-nent a� utfora de funktioner som kravs av den under sa�a villkor over en given tidsperiod.Den korta de�nitionen forfa�arna ger ar: “e� ma� pa oavbruten och korrekt utford tjanst”.Hur tillforlitligt e� system ar beror pa vad den speci�cerade funktionen ska utfora for uppgi�.Alltsa en databas kan anses vara ej tillforlitlig ifall den ger e�er en interaktion e� ej forvantatresultat. Med de�a i atanke blir de tva framsta utmaningarna for tillforlitlighet: hur losessamtidiga skrivningar till samma objekt, och vad ar konsistensen som upplevs av klienter.

7

8

3 Metod

For a� besvara fragestallningen Hur skiljer sig MongoDB, Oracle NoSQL och Oracle RDBMSgallande aspekterna skalbarhet, konsistens, tillganglighet, hallbarhet, tillforlitlighet och pre-standa? kommer forst en teoretisk utvardering av de tre databaserna med avseende pa defem forsta aspekterna a� utforas. For a� sedan utvardera hur prestandan skiljer sig at mel-lan de olika databaserna utfors en experimentell jamforelse genom a� skapa e� testprogramsom mater responstiden for e� antal utvalda operationer. De�a utfors dels for a� styrka ellerbestrida resultaten fran den teoretiska analysen och dels for a� en teoretisk jamforelse av pre-standan forsvaras av bristen pa tidigare utforda prestandatester, framforallt for Oracle NoSQL.

3.1 Metodval

Som tidigare diskuterats bor e� �ertal egenskaper inga vid en utvardering av en databas [3]och for a� utfora de�a genom en experimentell studie skulle massor av resurser och tid kravasvilket inte ryms inom ramen for denna studie. Darfor kommer egenskaperna skalbarhet, kon-sistens, tillganglighet, hallbarhet och tillforlitlighet utvarderas teoretiskt med hjalp av resultatfran tidigare utforda studier.

Gallande prestanda har vi inte lyckats identi�era nagra studier som utfor prestandatester darOracle NoSQL ingar och darfor kommer denna egenskap a� utvarderas i en experimentell delsom liknar det som utforts i andra studier [14, 18, 19]. I dessa studier anges inte exakt vilkaqueries som anvands for a� utfora matningar vilket leder till a� vi sjalva maste bestamma enutformning som testar olika delar av de typer av operationer som kan utforas i en databas.Med de�a i atanke valde vi a� utfora tre olika lasoperationer med olika komplexitet, en oper-ation som utfor en aggregatfunktion (raknar objekt i de�a fall) samt tre olika skrivoperationer(en insa�ning, en uppdatering samt en radering). Dessa anser vi skapar en tillrackligt bredtestmangd for a� kunna se skillnader pa for vilka typer av operationer de olika databasernapresterar ba�re och samre.

Vi valde a� endast mata responstiden for de olika operationerna for a� minimera/undvikapaverkan fran sjalva testprogrammet, det vill saga a� det som mats endast blir det som skeri sjalva databasen och inte nagot i testprogrammet.

For a� vidare kunna visa hur prestandan paverkades av en vaxande mangd data valde vi a�anvanda tre olika storlekar pa datamangden, 6000, 100 000 och 500 000 objekt. Anledningentill dessa summor var till a� borja med a� vi anvande testdata som tillhandaholls av var samar-betspartner, Ska�everket, och denna inneholl ca 6000 objekt och �ck bli utgangspunkten forprestandatesterna. A� fa tillforlitliga resultat nar det galler NoSQL-databaser kan vara en ut-maning da det o�a kraver miljoner objekt vilket ar nagot som sallan �nns tillgangligt. Genoma� skapa kopior pa var be�ntliga testdata kunde vi utoka datamangden till totalt 500 000objekt vilket enligt Azhi Faraj, Bilal Rashid och Twana Shareef [13] anses vara en tillrackligmangd testdata.

Vidare undersokte vi praktiskt hur manga objekt i en datamangd fran 6000 till 500 000 som

9

kunde vara relevanta a� utfora testen pa. De�a visade a� en okning fran 6000 till 100 000 varmotiverat da det kravs for a� visa nagon storre skillnad i testresultaten.

3.2 Datainsamling

Den teoretiska delen samlar in data genom a� ga djupare in i tidigare utford forskning daraspekterna vi ska ti�a pa utvarderats och anvanda resultaten de kommit fram till.

For a� genomfora prestandamatningarna kommer vi a� implementera e� Java-program somutfor de utvalda operationerna mot respektive databas. Prestandan mats genom a� kontrollerahur lang tid det tar a� fa respons fran de olika operationerna pa olika stora datamangder.

3.3 Hardvara och mjukvara

Testerna har utfors pa en klientdator med foljande hardvara/mjukvara:

• Operativsystem: Windows 10

• CPU: Intel Core i7-7500U 2,7Ghz.

• Internminne: 16 GB.

• Harddisk: Samsung SSD 512GB

3.3.1 Databaser

For prestandamatningarna anvander vi databasimplementationer som tillhandahalls av Skat-teverket. Oracle RDBMS-implementationen vi anvander ar samma som anvands inom myn-digheten for testkorningar och ar installerad pa deras servrar. Oracle NoSQL och MongoDBar installerade speci�kt for denna studie och ligger aven dessa pa maskiner i Ska�everketsserverhall.Versioner pa databaserna som anvands:

• MongoDB: 4.0.9

• Oracle RDBMS: 12.2

• Oracle NoSQL: 18.3.11

3.4 Testdata

Vi har fa� tillgang till det myndigheten anvander som testdata. Denna data bestar av e� storreantal tabeller med information om personer och med relationer till andra tabeller som berorvarje speci�k person som till exempel kontaktinformation etc. Testdatat utgors av cirka 6000objekt. For a� oka mangden till totalt 500 000 objekt kommer vi a� duplicera be�ntlig data.For testerna vi kommer a� utfora ar det inte nodvandigt a� skapa kopior pa samtliga tabellersom testdatan bestar av, istallet kan tva av tabellerna valjas ut for a� skapa testmangderna. TillOracle NoSQL och MongoDB var vi intresserade av a� arbeta med datan i JSON-dokument

10

istallet for tabeller och rader, sa de utvalda tabellerna konverterades till e� gemensamt JSON-dokument. Konverteringen till JSON innebar a� antalet objekt blev nagot storre da varje doku-ment innehaller en adress och personen kopplad till denna, vilket innebar a� en person kanforekomma i �era dokument da en person kan ha mer an en adress. Men da skillnaden i an-tal i slutandan blev tillrackligt liten anser vi a� denna inte paverkar prestandamatningarnasutfall, (nar relations databasen inneholl 100 000 objekt innehaller NoSQL databaserna ca 100800 dokument). Alla a�ribut som inneholl null-varden i Oracle RDBMS utelamnades i konver-teringen till JSON-dokument och darmed �ck vi dataobjekt som inneholl olika antal a�ribut.

3.5 �eries som har testats

Har tas varje query upp och deras utformning beskrivs kort for reproducerbarhet.

Hamta IDENTITET

Oracle RDBMS har denna query utformad med vanlig SQL: ”select IDENTITET from table”.

Oracle NoSQL anvander Java-biblioteket TableAPI och indexering for a� utfora motsvarandequery.

MongoDB har e� Java-bibliotek mongodb som innehar alla metoder for a� utformaqueries till databasen. Istallet for ”select” anvands en funktion som heter find som kanhamta onskad information.

Hamta objekt dar IDENTITET = x

Oracle RDBMS: ”select * from table where IDENTITET = x”

Oracle NoSQL hamtar objektet genom a� skapa en index-nyckel med den givna iden-titeten och anvander sedan TableAPI-klassen for a� hamta resultatet av query:n.

MongoDB hamtar alla objekt fran samlingen dar IDENTITET har e� speci�cerat vardeoch anvander en �nd-funktion med kriteriet som parameter.

Hamta attr1 och attr2 dar attr3 >x

Oracle RDBMS: ”select table1.a�r1, table2.a�r2 from table1 inner join table2 on id1 = id2 wherea�r3 >x”

Oracle NoSQL utny�jar for denna operation mojligheten a� kora querys pa SQL-format ochkan da kora en liknande query som Oracle RDBMS med skillnaden a� a�ributen hamtas utfran JSON-dokumentet istallet for fran separata rader och kolumner.

MongoDB:s variant av en >-operator representeras av $gt. De�a mojliggor utforman-det av e� kriterie dar a�r3 maste vara storre en nagon angiven konstant.

11

Rakna objekt

Oracle RDBMS: ”select count(*) from table”

Oracle NoSQL utny�jar aven for denna operation mojligheten a� kora querys pa SQL-format.

MongoDB maste med si� Java-bibliotek anropa en speciell aggregat-metod istallet for�nd. I denna nya metod speci�cerar man som parameter den aggregatfunktion som skaanvandas, vilket i de�a fall ar count.

Lagg till ett nytt objekt

Oracle RDBMS: ”insert into table (rader) values (varden)”. Da e� objekt bestar av bade person-uppgi�er samt kontaktuppgi�er innebar de�a a� for Oracle RDBMS sa maste insa�ningenske i tva separata querys till tva olika tabeller.

Oracle NoSQL skapar en ny rad med e� unikt id och e� JSON-objekt som innehallersamtlig information tillhorande det nya objektet och anvander sedan metoden table.put()fran TableAPI klassen for insa�ning.

MongoDB kan lagga till nya objekt till en samling genom a� ska e� Document-objekt.Med e� Document gar det a� speci�cera a�ribut och dess varde i valfri ordning. E�eratanropas en insert-funktion som lagger till objektet i en samling.

Ta bort ett objekt dar IDENTITET = x

Oracle RDBMS: ”delete from table where IDENTITET = x”. I de�a test raderades en givenidentitet och for Oracle RDBMS kravdes for denna operation a� identiteten raderades i tvaolika tabeller vilket innebar a� tva SQL-operationer maste exekveras for a� genomfora testet.

Oracle NoSQL anvander TableAPI.delete()-metoden for a� radera en rad i databasensom tar en primarnyckel som parameter. Primarnyckeln i de�a fall ar variabeln uid somkopplats till JSON-�len som innehaller identiteten som ska raderas.

MongoDB anropar en deleteOne-metod som tar e� Document-objekt som parameter.MongoDB tar da bort det forsta objektet i databasen dar Document-objektets alla speci�cer-ade varden �nns.

Uppdatera ett objekt dar IDENTITET = x

Oracle RDBMS: ”UPDATE table SET a�r1 = x, a�r2 = y WHERE id = z”

Oracle NoSQL anvander en metod fran TableAPI for a� skriva over e� falt med en put-metod.

MongoDB-biblioteket innehar en metod for a� uppdatera e� dokument genom a� taemot kriteriet ”IDENTITET=x” for a� veta vilket objekt som ska uppdateras, samt e�argument ”a�r=y” for a� ange vilken a�ribut som ska uppdateras till vad.

12

Vart att notera for testerna for Oracle NoSQL

For a� utfora testet dar datan for e� speci�kt id skulle hanteras kunde vi utny�ja indexeringvilket forba�rade tiden avsevart.

13

14

4 Resultat & analys

Gallande egenskaperna konsistens, tillganglighet, hallbarhet och tillforlitlighet sa foljer Ora-cle RDBMS transaktionsreglerna enligt ACID vilket gor a� det ar mer relevant a� utvarderahur NoSQL-losningarna i studien hanterar dessa delar.

4.1 Skalbarhet

For Oracle RDBMS ar skalbarhet inte relevant a� utvardera da denna typ av databas endastkan skala vertikalt vilket inte sker pa samma sa� som horisontell skalning och darmed intekommer a� paverka prestandan under dri�.

Gallande MongoDB sa utfor Dory, Mejıas, Van Roy och Tran [20] prestandamatningarpa skalbarhet och elasticitet dar de jamfor MongoDB med tva andra databaser. Testernautfors genom a� lagga till �er noder till klustret och samtidigt mata hur de�a paverkarprestandan. Gallande skalbarhet redogor forfa�arna a� MongoDB blir 78% langsammarenar antalet noder fordubblats fran 6 till 12 stycken. De�a visar enligt forfa�arna a� Mon-goDBs skalbarhet ar dalig da de andra testade databaserna endast visar en mycket litenforsamring och en till och med visar en forba�rad prestanda. Gallande elasticitet redogorforfa�arna for hur MongoDB uppvisar en betydligt storre variation i prestanda undertiden som nya noder infors i systemet an vid normal dri�. Stabiliseringstiden for systemeta� aterga till normal dri� ar ocksa betydligt langre for MongoDB an de andra tva databaserna.

Vidare redogor forfa�arna for a� de sto�e pa problem med MongoDB da testerna skulleutforas pa e� storre antal noder vilket verkade vara relaterat med hur MongoDB replikerardatan fran masternoden. Under testerna ledde de�a till a� diskutrymmet blev fullt snabbarean vad datan kunde replikeras till andra noder och databasen kraschade. De�a behoverutredas mer om MongoDB skulle overvagas for anvandningsomraden dar skalbarhet ochelasticitet ar viktigt. Det ska dock noteras a� testerna utfordes ar 2011 pa version 1.8.0 ochproblemen som uppstod kan vara forandrat till den just nu senaste versionen 4.0.8.

For Oracle NoSQL har vi under var studie inte kunnat identi�era nagra studier dartester pa skalbarhet och elasticitet utforts och skulle darfor behova undersokas for a� kunnautvardera denna aspekt. Aven generellt skulle skalbarhet behova utvarderas mer for olikaNoSQL-databaser for det �nns for lite kunskap om hur de�a paverkar prestandan.

4.2 Konsistens

MongoDB anvander sig av las for a� garantera a� las- och skrivoperationer ar konsistenta [9].Men enligt D. Abadi [21] erbjuder MongoDB aven en asynkron datareplikeringsmodell,vilket innebar a� en uppdatering av data anses vara klar sa fort den ar kopierad till ennod men innan den hunnit synkronisera datan pa samtliga noder i systemet. Trots de�a

15

anses MongoDB vara en av fa NoSQL-databaserna dar stark konsistens erbjuds. OracleNoSQL garanterar a� varje operation ar totalt ACID-kompatibel [22] och har en mangdolika konsistenspolicys (se Figur 2). Pa den ena sidan av spektrummet kan total konsistensanges vilket garanterar a� en las operation returnerar det senaste insa�a vardet for engiven nyckel. Pa andra sidan kan applikationer som tillater inkonsekvent data ange en svagkonsistens for a� istallet erbjuda en hog e�ektivitet men med risken a� datan inte ar densenast uppdaterade versionen. Mellan dessa y�erligheter �nns mojligheten a� ange enversion- eller tidsbaserad konsistens niva dar garantier ges for a� det returnerade vardet armax nan angiven tid gammal eller tillhor minst en pa forhand angiven version [23].

Figur 2: Oracle NoSQLs konsistens nivaer [24]

4.3 Tillganglighet

Enligt Oracle[25] hanterar Oracle NoSQL tillganglighet genom a� lagra data i en KVStore,de�a ar en samling av lagringsnoder som i sin tur bestar av e� antal replikeringsnoder.En KVStore kan antingen ersa�a eller anvandas tillsammans med en back-end databas. La-gringsnoderna kan vara fysiska (eller virtuella) maskiner (se Figur 3).

16

Figur 3: Denna bild [26] representerar en typisk arkitektur for en applikation dar OracleNoSQL anvands.

Varje lagringsnod innehaller en eller �era replikeringsnoder dar antalet ar beroende pa la-gringsnodens hardvara. Det �nns inget krav pa a� lagringsnoderna ska vara lika kra�fulla,e�ersom Oracle NoSQL ser till a� lagringsnoderna far en fordelning av belastningen propor-tionell till nodens kra�.

En replikeringsnod kan ses som en enda databas innehallande nyckel-varde-par. Dessa noderorganiseras i shards (se Figur 4). En shard innehaller en enda replikeringsnod (master-noden),som anvands for a� utfora skrivoperationer mot databasen samt en eller �era nodkopior somendast utfor lasoperationer. Master-noden kopierar allt som skrivs till den till nodkopiorna.Trots a� det endast kan forekomma max en master-nod vid e� givet tillfalle kan alla noder ien shard bli en master-nod. Alltsa om en master-nod i en shard skulle misslyckas befordrasen av nodkopiorna till master.

17

Figur 4: Denna bild [27] visar hur shards ar uppdelade i en KVStore.

MongoDB erbjuder tillganglighet via kopierade noder [2]. En Master-Slave-losning anvandsdar en nod agerar som master och har en eller �era slave-noder. Det ar master-noden somskriver till och laser fran �ler, medan slavarna �nns som back-up och endast kan utforalasoperationer. Ifall en master-nod blir otillganglig befordras slave-noden med den nyastedatan till master. De�a kan astadkommas e�ersom alla kopior av en nod ar asynkrona, vilketinnebar a� uppdateringar i en nod inte sprids omedelbart till ovriga kopior. Det gar a� kon-�gurera noderna i e� system pa �era sa�:

• Endast sekundara medlemmar, kan inte overga till a� vara master-nod.

• Gomda medlemmar, kan inte overga till a� vara master-nod och ar aven osynliga forklienten.

• Skiljedommare, ar medlemmar som endast �nns for a� delta i val och kommuniceramed andra medlemmar

• Ej-rostande medlemmar, deltar inte i val och anvands for det mesta i stora kluster med�er an sju medlemmar.

4.4 Hallbarhet

D. Abadi [21] diskuterar hur MongoDB anvander sig av en asynkron datareplikeringsmod-ell som garanterar a� datan atminstone ar skriven till master-noden innan transaktionenanses klar. Vid handelsen a� fel uppstar med master-noden innan den hunnit replikera datantill ovriga noder, sparas datan i en lokal aterstallningskopia for a� kunna anvandas vidaterkoppling till klustret av noder. De�a har visats bidra till en lagre dataforlust hos Mon-goDB vid nodfel. Oracle NoSQL erbjuder genom sin anvandning av KV-Store (se 4.3) enstallbar niva pa hallbarheten (Oracles manual [28] visar tillvagagangssa�et for anvandningmed programspraket Java). Vid installning av den starkaste garantin for hallbarhet kravs a�samtliga kopior bekra�ar skrivningen innan transaktionen anses klar. De�a medfor avenden samsta prestandan for skrivoperationer men de�a kan begransas genom a� ange olikahallbarhetsinstallningar for speci�ka skrivoperationer och endast krava den hogsta garantinfor de viktigaste operationerna.

18

Sammanfa�ningsvis kan vi utifran de�a anse a� Oracle NoSQL kan vara det ba�re valet omhallbarhet ar en mycket viktig aspekt for applikationen man tankt anvanda systemet till. Menaven MongoDB erbjuder till en viss grad en stallbar hallbarhetsniva. Vart a� notera ar a�dokument-baserade system som MongoDB vanligtvis anvander e� singel-versions system,dessa ar konstruerade speci�kt for a� erbjuda hog hallbarhet [16].

4.5 Tillforlitlighet

MongoDB far en stor del av sin tillforlitlighet genom a� samtidiga operationer hanteras meddatalas [22], vilket gor a� max en klient at gangen kan skriva till e� objekt. Nar det kommertill Oracle NoSQL hanterar den samtidiga operationer genom a� en utvald master-nod skoteralla skrivoperationer i replikerade grupper [29]. Angaende hur konsistensen for klienter kanupplevas, se 4.2 ovan.

4.6 Prestanda

Fran ovan namnda egenskaper har vi se� a� prestandan o�a paverkas beroende pa hur deolika egenskaperna hanteras. Darfor ar det relevant a� se hur prestandan skiljer sig at mellande olika databaserna i studien.

Da vi inte kunnat identi�era nagra studier som utfor prestandatester dar Oracle NoSQL inga�,utvarderas nedan resultaten fran de experimentella tester vi utfort.

Figur 5: Prestandaskillnader vid lasning av e� varde i respektive databas.

Resultaten i Figur 5 visar a� bade MongoDB och Oracle NoSQL presterar bra vid okomplicer-ade sokningar for a� hamta id fran samtliga objekt i datamangden och paverkas mycket lite avantalet objekt. Oracle RDBMS presterar samre med en responstid pa ca 10 ms vid 6000 och 100000 objekt. Sedan visas en tydlig forsamring nar databasen okar till 500 000 objekt da respon-

19

stiden okat till 14.04 ms vilket da aven tyder pa a� forsamringen kan oka om datamangdenstiger y�erligare.

Figur 6: Prestandaskillnader mellan databaserna nar alla varden kopplat till e� speci�kt idhamtas.

I Figur 6 visas e� test dar samtliga varden kopplat till e� speci�kt id hamtades, dar id arav datatypen long. Varje stapel visar medeltiden for varje operation pa de tre olika stor-lekarna pa datamangderna for sina respektive databaser. MongoDB visar sig vara den snab-baste databasen i alla fall med en medeltid under 0.0002 ms for 6000 dataobjekt, ca 0.0005 msvid 100 000 objekt och sist 0.0002 ms i medeltid for 500 000 objekt.

Nast snabbast vid alla tillfallen var Oracle NoSQL som hade 0.13 ms i medeltid 6000 objekt.For 100 000 objekt var medeltiden ca 0.11 ms, alltsa lite ba�re an for den minsta datamangden.For den storsta mangden var medeltiden 0.10 ms.

Relationsdatabasen Oracle RDBMS hade i sarklass samst tider for denna operation och ham-nade aldrig under 9 ms for 6000 dataobjekt med en medeltid runt 10 ms. For 100 000 objekthade den en medeltid av ca 10.5 ms och till sist for 500 000 objekt var medeltiden ca 14.1 ms.

20

Figur 7: Prestandaskillnader mellan databaserna nar a�ribut x och y fran alla rader dar radensz-varde ar storre an en angiven konstant hamtas.

Resultaten i Figur 7 visar a� responstiden for Oracle NoSQL och MongoDB inte paverkasnamnvart vid en okande datamangd. MongoDB har en medeltid pa 0.0005 ms for 6000 objekt,0.0004 ms for 100 000 objekt och sist 0.0006 ms for 500 000 objekt. De�a beror delvis pa a�manga matningar gick sa fort a� de inte var matbara och darfor gav resultatet 0 ms vilket drogner medelvardet betydligt. Om man daremot ti�ar pa de individuella korningarna visas avena� nagra av de forsta matningarna tar betydligt langre tid, dar till exempel forsta matvardetvid datamangden 500 000 objekt visar en responstid pa 0.06ms och overgar sedan a� till sni�etpa 0.0006. De�a visar a� databasen optimeras for denna speci�ka query e�er nagra iterationer.

Oracle NoSQL har betydligt langsammare responstid an MongoDB och redovisarmedelvarden pa 87.6 ms for 6000 objekt, 79.2 ms for 100 000 objekt och 79.1 ms for 500 000 ob-jekt dar den snabbare tiden galler vid matning med 500 000 objekt vilket visar a� responstideninte verkar paverkas negativt vid en okande datamangd.

Resultaten for Oracle RDBMS visar a� denna databas i hog grad paverkas av storleken padatamangd. Medel-responstiden nar databasen innehaller 6000 objekt ar 10.6 ms, vid 100 000objekt har det okat till 28.23 ms och vid 500 000 objekt har responstiden okat anda till 366.7ms vilket visar pa en tydlig forsamring vid storre datamangder.

Under de olika hamta-testerna har NoSQL-databaserna i regel presterat betydligt ba�re anrelationsdatabasen Oracle RDBMS. Varken MongoDB eller Oracle NoSQL paverkas markbartnegativt av en vaxande datamangd, medan Oracle RDBMS presterar allt samre med vaxandeantal objekt. Som tidigare diskuterats ar tanken med NoSQL-databaser a� kunna lagra ochhantera massiva datamangder vilket ocksa marks i dessa tester. I jamforelse med hamta-testerna utforda i [13] kan man se a� forfa�arna fa� liknande resultat dar MongoDBpresterar mycket ba�re an Oracle RDBMS i nastan alla tester. Dar observeras a� vid endatamangdstorlek pa 500 000 objekt presterar MongoDB ba�re i fyra av fem queries mensamre vid en query. De queries som kordes i [13] ar dock nagot mer detaljerade an de somgjordes i denna studie vilket bor ha bidragit till de markbart langre exekveringstiderna somden studien resulterade i an resultaten fran denna studie. I denna studie har hamta-testerna

21

varit ra� enkla vilket ar anledningen till exekveringstider under 1 ms for NoSQL-databaserna.

Undantaget som observerades var resultaten till query:n ”Hamta a�r1 och a�r2 dar a�r3>x”. I de�a test var Oracle NoSQL mycket samre an Oracle RDBMS for dem tva mindredatamangderna 6000 och 100 000. Oracle NoSQL far en mycket langsammare tid e�ersom denar en key-value-databas, och enligt Vaish, Gaurav [7] maste en sadan forst forst fa nyckelnspeci�cerat till vardet innan den har mojlighet a� hamta det e�ersokta vardet vilket innebara� den saknar direkta funktioner for a� �ltrera varden. I ovrigt hade Oracle NoSQL en ra�jamn exekveringstid for alla tre datamangder for det testet, men Oracle RDBMS paverkadesvaldigt negativt nar datamangden okade fran 100 000 till 500 000 genom a� bli mer an 10ganger sa langsam. De�a ar inte sa otroligt med tanke pa a� relationsdatabaser inte varamnade a� e�ektivt lagra stora datamangder. Det ar dock vart a� notera a� Oracle RDBMS-servern som anvandes under testerna har kon�gurerats och optimerats av Ska�everket for a�fungera sa bra som mojligt for deras verksamhet och exakt hur de�a har paverkat resultateni denna studie ar inte helt klart.

Figur 8: Prestandaskillnader mellan databaserna for operationen som raknar antalet objektsom �nns i databasen.

I det test som visas i Figur 8 utfordes aggregationsoperationen a� rakna e� utvalt antal objektoch speci�kt i de�a fall sa raknades samtliga objekt som fanns i respektive databas vid olikastora datamangder. Testen visade a� Oracle NoSQL hade en valdigt hog medeltid (mellan 600-700 ms) vid samtliga storlekar pa testdatan medan bade MongoDB och Oracle RDBMS utfordedenna operation valdigt snabbt (se Figur 8).

MongoDB ar i sarklass snabbast vid utforandet av operationen for a� rakna antalet objekt idatabasen oberoende av storlek dar operationen endast tar 1-2 tusendels millisekund. OracleRDBMS utfor operationen pa ca 40 ms nar datamangden ar 6000 och 100 000 och visar enokning till ca 60 ms vid 500 000 objekt. Oracle NoSQL ar i sarklass langsammast pa a�utfora denna operation med medelresponstider pa mellan 6 och 700 ms men visar dock enforba�ring nar testdatamangden bestar av mer an 6000 objekt.

Faraj, Rashid, och Shareef [13] utfor en prestanda jamforelse mellan Oracle RDBMS

22

och MongoDB dar bland annat e� antal tester pa COUNT -operationer ingar. Forfa�arnasresultat for dessa visar a� MongoDB har en exekveringstid pa mellan 0.6-2 sekunder ochpresterar betydligt samre an Oracle RDBMS. A� skillnaden ar sa stor mot vara resultat berorpa a� i [13] skickas en query med som sorterar ut en delmangd av objekten och raknar dessa.Vart test skickar inte med nagon query e�ersom den e�ersom den anvanda count-funktionendast returnerar e� uppska�at statistiskt varde som sparats internt [30] och gar darforvaldigt snabbt men ar daremot inte helt palitligt.

Oracle NoSQL anvander for denna operation en SQL-fraga, nagot som erbjuds for OracleNoSQL for a� kunna hantera en bredare funktionalitet an vad som ryms inom den en-klare nyckel-varde atkomsten. Men prestandamatningarna visar a� arbetet som maste skepa databasniva for a� oversa�a dessa SQL fragor paverkar prestandan mycket negativt.

Figur 9: Prestandaskillnader mellan databaserna for operationen som sa�er in en ny rad mednodvandiga varden.

I testet ovan skapades e� ny� objekt som sa�es in i respektive databas vid de tre olika stor-lekarna pa datamangd. Till Oracle NoSQL och MongoDB ingar samtliga uppgi�er i sammaJSON-dokument och darfor behover endast en insa�ning utforas. Resultaten i Figur 9 visarmycket liknande matvarden for radering for bade MongoDB och Oracle NoSQL. For dessa tvapaverkas inte responstiden namnvart nar datamangden okar. For Oracle RDBMS uppvisasdaremot aven har en betydlig okning i responstid vid okande datamangd.

Nar det kommer till a� lagga till objekt till en databas ar Oracle NoSQL konsekvent densnabbaste oavse� storlek pa datamangden som ska ta emot det nya objektet. For dessadatamangder verkar storleken ha en omarkbar paverkan pa exekveringstidens medeltid.

MongoDB har den nast snabbaste insa�ningstiden for alla tre datamangdstorlekar. Vart a�notera ar a� det tar mer tid a� sa�a in e� objekt i en mangd med 100 000 dokument ochminst tid i mangden med 500 000 dokument. Som namnt tidigare har MongoDB fokus palashastighet framfor skrivhastighet [31], vilket leder till a� den inte klarar av insa�ningstiderpa samma niva som Oracle NoSQL.

Oracle RDBMS ar den langsammaste for denna query med en noterbar okning i exekver-

23

ingstid mellan 6000 och 100 000 rader pa ungefar 48 ms, men en mindre markbar skillnadmellan 100 000 och 500 000 rader pa ca 4 ms. MongoDB ar den nast snabbaste pa insert-operationer och har betydligt ba�re tider an vad relationsdatabasen har. Exekveringstidenokar fran 6000 objekt till 100 000, men gar ner igen e�er mangden forstorats till 500 000 ob-jekt. Det ar osakert varfor de�a uppstar for a� det ar okant huruvida de�a monster ater�nnsi andra studier eller inte. Oracle RDBMS har de varsta tiderna for insert-operationer, vilketkan forklaras av konsistensbesgransningar som ar implementerade pa databasniva. I de�afall �nns en begransning pa a�ributet IDENTITET som automatiskt kontrolleras for varjeny rad som ska sa�as in. Aven i [32] syns kontrasten mellan MongoDB och Oracle RDBMSnar det kommer till insa�ningstider: MongoDB ar alltid snabbare pa insa�ningar an dennarelationsdatabas, och skillnaden i responstid kommer bara oka allt e�ersom databasen vaxer.

Figur 10: Prestandaskillnader mellan databaserna nar e� objekt i databasen raderas.

For Oracle NoSQL samt MongoDB behovdes endast e� nyckel-varde par respektive e� doku-ment raderas. Aven till denna operation var id indexerat i Oracle NoSQL som gor a� vardetsom e�ersoks snabbare kan lokaliseras. I Figur 10 uppvisar Oracle NoSQL dem snabbaste re-sponstiderna for samtliga datamangder med 16 ms nar testdatan bestar av 6000 objekt och ca13.5 ms for bade 100 000 och 500 000 objekt. MongoDB uppvisar nagot langsammare respon-stid an Oracle NoSQL, 23.6 - 29.3 ms men da den lagsta tiden registreras pa nar datamangdenar som storst tyder de�a pa a� prestandan kan oka ju storre datamangd som databasen in-nehaller. Oracle RDBMS presterar betydligt samre i de�a test jamfort med NoSQL databasernaoch uppvisar en betydlig forsamring ju storre datamangden blir. Nar testdatan bestar av 500000 objekt tar en radering i sni� 96.4ms vilket ar ca 7 ggr langsammare an for motsvarandetest av Oracle NoSQL (se Figur 10).

For bor�agningar av objekt var Oracle NoSQL konsekvent den snabbare databasen som intedrojde mer an 20 ms for nagon av datamangderna. MongoDB var den nast snabbaste och ly-ckades halla medeltiden for resultaten under 30 ms for alla datamangder som testades. Detvisade sig a� MongoDB tar langre tid for datamangder med 100 000 objekt an 500 000 objekt,vilket ar nagot som ej syns i andra studier. En anledning till a� MongoDB presterar nagotba�re an relationsdatabasen ar a� i de�a fall fanns mojlighet a� anropa en ”radera-enstaka-

24

objekt”-funktion som bara tar bort det forsta objektet som uppfyller det angivna kriteriet,vilket leder till a� MongoDB inte behover undersoka varje objekt i databasen [33]. Hade en”radera-�era”-funktion anvants hade resulta�iderna varit storre [34], men e�ersom malet en-dast var a� radera e� enda objekt var den funktionen inte nodvandig. En av sakerna Mon-goDB har i fokus ar hastighet [32], vilket ar nagot som marks bl.a. pa hur dess raderafunkionerbeter sig. MongoDBs raderafunktioner hanterar endast en samling at gangen [35], vilket intear nagot som relationsdatabasen har mojlighet a� gora i de�a fall nar tva tabeller anvands.Som en dokumentdatabas ar MongoDB aven fokuserad pa a� ha bra query-prestanda istalletfor a� ha dem e�ektivaste skrivoperationerna [31].

Oracle RDBMS hade dem langsta medelresponstiderna for alla datamangder. En stor bidra-gande faktor som paverkat exekveringstiden negativt ar just det faktum a� denna databas aren relationsdatabas. For a� uppra�halla tabellernas konsistens i en relationsdatabas i de�afall maste y�erligare rader fran en annan tabell tas bort an den som speci�cerades av deninledande query:n, vilket kraver mer arbete fran Oracle RDBMS som drar ut pa tiden.

Figur 11: Prestandaskillnader mellan databaserna nar e� a�ribut pa e� speci�kt objekt idatabaserna uppdaterades med olika stora mangder av data.

I testet som visas i Figur 11 uppdaterades e� a�ribut for e� utvalt id for respektive databas ochstorlek pa testdatan. For MongoDB och Oracle NoSQL innebar de�a a� uppdatera a�ributeti JSON-dokumentet. Testerna visar a� nar databaserna innehaller endast 6000 objekt ar skill-naden i responstid inte speciellt stor med en spridning mellan ca 18-28 ms och MongoDB arden som utfor operationen langsammast (se Figur 11). Vid 100 000 objekt okar responstidenavsevart for Oracle RDBMS till ca 57ms och ar da ca 4 ggr langsammare an Oracle NoSQL ochaven nastan dubbelt sa langsam som MongoDB. Oracle NoSQL anvander sig av indexeringfor a� snabbare kunna hi�a id:t som ska uppdateras som kan vara en del av forklaringen a�denna uppvisar bast prestanda for de�a test. Vid 500 000 objekt i testdatan jamnas si�rornaut en del da bade MongoDB och Oracle RDBMS uppvisar e� ba�re medelvarde an vid 100 000objekt. Oracle NoSQL uppvisar daremot en okning i responstid om an mycket liten.

Resultaten for nar e� a�ribut i e� objekt ska uppdateras visar for Oracle RDBMS a� re-sponstiden okar markant fran a� databasen innehaller 6000 objekt till a� den innehaller

25

100 000 objekt men a� den sedan gar nagot snabbare igen nar databasen innehaller 500000 objekt. Samma beteende gar a� observera gallande MongoDB, aven denna uppvisar denlangsammaste responstiden nar datamangden innehaller 100 000 dokument. Medeltidernafor Oracle NoSQL skiljer sig daremot nagot fran de ovriga genom a� vara langsammast nardatabasen innehaller 6000 objekt till a� prestera snabbast vid 100 000 objekt och sedan baraoka marginellt till nar databasen innehaller 500 000 objekt. Tidsmassigt nar testdatan bestar av6000 objekt forhaller sig Oracle RDBMS mycket bra gentemot de tva NoSQL databaserna vilketdelvis kan forklaras med a� en av grund ideerna med NoSQL databaser ar a� kunna hanterastora mangder data och ar darfor inte optimerad for sma mangder data. Redan nar testdatanbestar av 100 000 objekt blir aspekten som diskuterats i studien a� relationsdatabaser inte kanhantera storre mangder data lika val som NoSQL tydligare da medelresponstiden for OracleRDBMS vid denna mangd ar ca 2-4 ganger langsammare an MongoDB och Oracle NoSQL.Aven nar testdatan bestar av 500 000 objekt presterar Oracle RDBMS samst aven om medel-responstiden ga� ner nagot.

26

5 Diskussion

Sy�et med studien var a� utvardera vilka skillnader som �nns mellan Oracle RDBMS,Oracle NoSQL och MongoDB gallande sex utvalda egenskaper och om det �nnsanvandningsomraden dar den ena eller andra ar ba�re lampad. Studien visade a� gallandekonsistens, tillganglighet, hallbarhet och tillforlitlighet sa ar den overgripande skillnaden a�for Oracle RDBMS garanteras dessa egenskaper tack vare a� denna foljer ACID-reglerna fortransaktioner. For MongoDB och Oracle NoSQL kan graden av dessa egenskaper daremotvariera. Det visade sig for bada a� graden av dessa egenskaper o�ast ar installningsbar ocha� egenskaperna aven o�a paverkar varandra. De�a innebar a� MongoDB och Oracle NoSQLtill skillnad fran Oracle RDBMS ger betydligt mer frihet till anvandaren a� valja vad som arviktigt och nar, vilket ger en mer �exibel losning.

Genom vara prestandatester kunde vi utvardera hur MongoDB och Oracle NoSQL presterarjamfort med Oracle RDBMS da standardinstallningarna for de tva NoSQL-losningarna anvan-des. Av de fem teoretiskt utvarderade egenskaperna ar det endast hallbarhet och konsistens ivart fall som paverkar prestandatesterna. Gallande hallbarhet sa foljer Oracle RDBMS ACIDoch maste se till a� data ar skriven till disk innan transaktionen anses fardig. MongoDB pri-oriterar prestanda genom a� endast begara en bekra�else e�er a� operationen skrivit tillminne och inte till disk. Oracle NoSQL har �era policyer for hallbarhet, men som standardhar den sa lag hallbarhet som mojligt, vilket gynnar prestandan [36]. Gallande konsistens kanMongoDB:s skrivprestanda paverkas av dess konsistensdesign e�ersom den anvander datalasfor varje dataobjekt den paverkar, vilket tar lite tid. Oracle NoSQL ar som standard installda� inte erbjuda nagon konsistens alls [37] vilket paverkar prestandan positivt jamfort medOracle RDBMS som erbjuder full konsistens. Skalbarhet och tillganglighet paverkar inte pre-standatesterna da dessa egenskaper skulle krava a� �er an en nod anvandes vilket inte varitfallet i vara tester. Tillforlitligheten paverkar inte heller prestandan i vara tester da de�a hara� gora med hur samtidiga transaktioner hanteras och vara tester utfor endast en transaktioni taget.

Den teoretiska utvarderingen gav intrycket a� for lasoperationer var egenskaperna som utva-rderats inget som borde paverka prestandan negativt och a� NoSQL databaserna borde ha enbetydligt hogre prestanda an relationsdatabasen. Resultaten av lasoperationernas prestandat-ester visade a� MongoDB var den klart snabbaste av alla databaser. Oracle NoSQL var o�astden nast snabbaste men exekverade betydligt langsammare dar den anvande SQL-queries,vilket gjorde a� den presterade samre an Oracle RDBMS for det mesta. Tillfallet dar OracleNoSQL ar snabbare an Oracle RDBMS med en SQL-query observeras i Figur 7 dar relations-databasen var langsammare for 500 000 objekt, vilket ar vantat e�ersom relationsdatabaserklarar inte av sadana mangder data lika val som NoSQL-databaser. A� Oracle NoSQL tog saforvanansvart lang tid med SQL-queries var ovantat for a� vi inte visste exakt hur OracleNoSQL utfor dessa operationer. Tidsatgangen beror mojligtvis pa en oversa�ning av query-syntax fran SQL till Oracle NoSQL:s egna query-sprak, men de�a ar osakert och behoverundersokas.

I en liknande studie utford av Faraj, Rashid och Shareef [13] som jamforde exekveringstid

27

for MongoDB och Oracle RDBMS, observerades a� MongoDB inte alltid var den snabbaste.Den studien redovisade exakt hur varenda query sag ut, vilket hjalpte med a� jamfora medvara resultat. Det vi upptackte var a� vi borde ha formulerat queries som hanterade hamtningav �era speci�cerade varden pa samma gang tillsammans med mer detaljerade villkor for a�fa en ba�re uppfa�ning om prestationsformagorna for de tre olika databaserna. Hade �erolika aggregationsfunktioner inkluderats hade vi aven fa� en klarare insikt i vilken databassom var e�ektiv pa vilka typer av berakningar, vare sig det handlade om en lasoperation sominkluderar en enkel jamforelse av heltal eller en upprakning av antalet dataobjekt.

Angaende skrivoperationerna gav den teoretiska utvardering intrycket a� Oracle RDBMSborde ha de samsta tiderna dels p.g.a. constraints som maste foljas och dels a� data maste skri-vas till disk vilket ACID kraver. Vidare visade utvarderingen a� MongoDB borde ha paverkatsnegativt prestandamassigt av sina datalas som maste anvandas for varje objekt den modi�erar,men samtidigt behovde den endast skriva data till minne vilket forvantades leda till ba�represtationstider an relationsdatabasen. Oracle NoSQL:s standardinstallningar anger lag kon-sistens och hallbarhet, samt saknar den ovriga nackdelar for skrivoperationer, vilket bordeleda till hog prestanda.

I prestandatesternas resultat for skrivoperationer visade det sig som vantat a� key-value-databasen Oracle NoSQL ar den mest tidse�ektiva for alla datamangdstorlekar. Vi ser avena� MongoDB o�ast ar vara snabbare an relationsdatabasen forutom nar det handlar om a�uppdatera objekt nar testen utfors pa den mindre datamangden, i vilket fall MongoDB artydligt langsammare an Oracle RDBMS. De�a beror pa a� en av faktorerna som skiljer endokumentdatabas fran en relationsdatabas ar a� dokumentdatabasen ar amnad a� e�ektivtlagra massiva mangder data samt snabbt kunna na e�erfragad data, medan relationsdatabasenhar mojlighet a� arbeta e�ektivt nar datamangden inte ar sa stor.

For vilka anvandningsomraden passar Oracle NoSQL eller MongoDB battre?

Vilken typ av data samt vilka krav pa anvandning och datalagring som ar viktiga foranvandaren paverkar i hog grad vilken databaslosning som passar ba�re for e� visstanvandningsomrade. Den framsta anledningen a� valja en NoSQL-databas ar dess formaga a�hantera stora datamangder vilket ocksa far stod fran vara prestandatester. E� annat uppenbarttillfalle dar NoSQL passar ba�re ar dar man i forvag inte vet exakt vilken typ av a�ribut e� ob-jekt behover innehalla eller a� man vet a� manga objekt i databasen kommer innehalla olikaantal a�ribut. Da NoSQL-databaser o�ast inte ar lasta till fasta strukturer pa liknande sa� somen relationsdatabas ar de�a e� omrade som passar ba�re for NoSQL-losningar. Utvarderingenvisade dock a� det ar svart a� generellt saga vilka anvandningsomraden dar den ena losningenar ba�re an den andra utan a� det o�ast ar starkt forknippat till det speci�ka fallet.

5.1 Begransningar

I denna studie observerar man e� monster for hur val olika databastyper hanterar en vaxandedatamangd fran 6000 objekt, till 100 000 objekt, till 500 000 objekt. Om man utforde tester paen mer gradvis vaxande datamangd med �er storlekar, t.ex. 25 000, 250 000, 1 000 000 objektetc., kunde eventuellt en mer detaljerad tidskurva observerats. Det hade potentiellt visat entydligare overgang fran nar en relationsdatabas hade varit e� rimligt val prestandamassigtjamfort med en NoSQL-databas till nar en relationsdatabas inte langre ar e� praktiskt val.De�a var overlag inte nodvandigt e�ersom de valda storlekarna 6 000, 100 000 och 500 000

28

kunde fortfarande visa hur de olika databaserna hanterar en okande datamangd upp till 500000 objekt relativt till varandra for de testade operationerna.

I denna studie, angaende prestandatesterna, var vi intresserade av hur snabb en operation atgangen fran en klient i taget, kunde interagera med en databas som fanns helt pa en endanod som alltid var pa nar den anvandes. Manga aspekter fanns inte mojlighet a� praktiskttesta p.g.a brist pa resurser som t.ex. �er noder. Vissa faktorer som ar positiva med NoSQL-databaser som inte testades var t.ex. horisontell skalbarhet och partitionshantering. Genoma� kunna testa och jamfora respektive databas alla styrkor och nackdelar hade en mer kom-ple� bild kunnat skapas da prestationsformaga sallan beror endast pa a� en enda klient utforen enstaka transaktion at gangen pa en enda nod. Daremot har det ga� a� konkret se hurdatabasernas prestanda for las-och skrivoperationer paverkas av en vaxande datamangd e�er-som de ovriga databasegenskaperna som tagits upp i studien har minimerats som foljd av vartsystems enkla uppbyggnad och testernas utseende samt avsaknad av samtidiga transaktioner.Resultatet som visar hanteringen av en vaxande datamangd var viktigt e�ersom det ar enkarnfraga i NoSQL och for oss den mest intressanta aspekten.

I studien valde vi a� utvardera endast en delmangd av egenskaperna som Lourenco, Cabral,Carreiro, och Vieira [3] tog upp i sin studie och det namns aven dar a� det �nns hundratalsegenskaper som potentiellt skulle kunna utvarderas. Men for a� utvarderingen skulle rymmasinom ramen for denna studie var vi tvungna a� rimligt avgransa egenskaperna till en lampligmangd genom a� endast behalla de egenskaper vi anser vara viktigast samt a� lagga till”prestanda”.

Vi anvande den versionen av Oracle RDBMS som tillhandaholls av Ska�everket, men den haranvants over lang tid och har kon�gurerats och optimerats for myndighetens sy�en. Det arokant hur vara resultat paverkats e�ersom vi inte har ha� insyn i hur de�a ar utfort. Alltsa ardet mojligt a� vi hade se� resultat som liknar det Faraj, Rashid och Shareef observerade i sinstudie [13] dar Oracle RDBMS var snabbare an MongoDB vid lasning nar �era objekt skullehi�as med hjalp av e� speci�kt varde pa e� a�ribut.

5.2 Slutsats och rekommendationer

MongoDB hanterar generellt queries snabbare an vad Oracle RDBMS gor med fa undantag,vilket bor undersokas y�erligare genom a� utforma �er olika detaljerade queries som inklud-erar �er kriterier som �ltrerar hamtade varden. MongoDB:s responstider vaxer inte i sammatakt som Oracle RDBMS:s responstider nar databasen blir storre. MongoDB kan dock varalangsammare vid uppdateringar av objekt i mindre datamangder, men kan i ovrigt utforaskrivoperationer snabbare oberoende av storleken pa datamangden.

Oracle NoSQL ser ut a� alltid utfora skrivoperationer snabbare an vad Oracle RDBMS goroberoende av datamangdens storlek och oavse� om det ar uppdateringar, insa�ningar ellerbor�agningar av objekt. Oracle NoSQL hanterar enklare queries som t.ex. hamtning av e�enda a�ribut snabbare an Oracle RDBMS for alla datamangdstorlekar, men nar en queryhar e� tillrackligt detaljerat villkor blir Oracle NoSQL langsammare an Oracle RDBMS fordatamangder upp till en viss storlek. Den storleken ligger nagonstans mellan 100 000 och 500000 objekt. Ifall Oracle NoSQL behover anvanda en SQL-query for a� hamta onskad informa-tion tar den valdigt lang tid i forhallande till Oracle RDBMS a� utfora operationen. Det blevaven svart a� helt analysera resultaten e�ersom det �nns sa pass fa studier a� jamfora medsom anvander Oracle NoSQL.

29

Trots a� inte alla vasentliga aspekter har undersokts som skulle ge NoSQL-databaserna e�overtag over relationsdatabaser, gar det a� se i de praktiska testerna a� NoSQL-databasernaklarar av vaxande databaser pa e� e�ektivare sa�. Tyvarr visar det inte en komple� bildover hur MongoDB och Oracle NoSQL skulle prestera i e� verkligt scenario genom a� endastbasera det pa prestandatesterna och den teoretiska analysen. Daremot har vi redovisat, enligtoss, de viktigaste egenskaperna a� overvaga vid val av relations- och NoSQL-databaser ochhur dessa egenskaper u�rycks i MongoDB, Oracle NoSQL och Oracle RDBMS.

5.3 Vidare arbete

Under var studie har det framkommit a� Oracle NoSQL forekommer valdigt sallan i tidigareutford forskning bade inom teoretiska utvarderingar och aven i mer praktiska utvarderingaroch jamforelser. De�a innebar a� det varit svart a� �nna stod eller information om olikaaspekter gallande denna typ av databas. Aven for var prestandautvardering visade det sigvara svart a� hi�a information om hur Oracle NoSQL ska implementeras pa basta sa� vilketkan ha paverkat resultaten vi fa� och bor alltsa testas.

For a� fa en klarare uppfa�ning angaende skillnaderna bor �er tester utforas. Dessa testerbor utformas for a� minst tacka: konsistens (t.ex. partitionerad data), tillganglighet (t.ex. nodsom stangs av och en annan maste ta over), hallbarhet (t.ex. bekra�a a� data bestar e�er avs-lutad transaktion), skalbarhet (t.ex. inkludera �era servrar) och tillforlitlighet (t.ex. undersokasamtidiga skrivningar till samma objekt).

30

Kallforteckning

[1] Oracle, “1 introduction to oracle database,” accessed 2019-04-25. [Online]. Available:h�ps://docs.oracle.com/database/121/CNCPT/intro.htm#CNCPT001

[2] V. Abramova and J. Bernardino, “Nosql databases: Mongodb vs cassandra,” in Proceedingsof the International C* Conference on Computer Science and So�ware Engineering, ser.C3S2E ’13. New York, NY, USA: ACM, 2013, pp. 14–22, accessed 21 March 2019. [On-line]. Available: h�p://web.cs.wpi.edu/∼cs585/s17/StudentsPresentations/�is%20Year/Week14/mongodb vs cassandra.pdf

[3] J. R. Lourenco, B. Cabral, P. Carreiro, M. Vieira, and J. Bernardino, “Choosingthe right nosql database for the job: a quality a�ribute evaluation,” Journal of BigData, vol. 2, no. 1, p. 18, Aug 2015, accessed 9 June 2019. [Online]. Available:h�ps://doi.org/10.1186/s40537-015-0025-0

[4] J. Melton, “Sql language summary,” ACM Comput. Surv., vol. 28, no. 1, pp. 141–143, Mar.1996, accessed 9 June 2019. [Online]. Available: h�p://doi.acm.org.proxy.ub.umu.se/10.1145/234313.234374

[5] D. G. Chandra, “Base analysis of nosql database,” Future Generation Computer Systems,vol. 52, pp. 13 – 21, 2015, special Section: Cloud Computing: Security, Privacy andPractice, accessed 12 April 2019. [Online]. Available: h�p://www.sciencedirect.com/science/article/pii/S0167739X15001788

[6] H. Garcia-Molina, J. D. Ullman, and J. Widom, Database Systems: the complete book,2nd ed. Pearson Education Limited, july 2013.

[7] G. Vaish, Ge�ing started with NoSQL. Packt Publishing Ltd, 2013.

[8] J. Pokorny, “Nosql databases: a step to database scalability in web environment,” Inter-national Journal of Web Information Systems, vol. 9, no. 1, pp. 69–82, 2013, accessed 12April 2019.

[9] P. Sareen and P. Kumar, “Nosql database and its comparison with sql database,”International Journal of Computer Science & Communication Networks, vol. 5, no. 5,pp. 293–298, 2015, accessed 15 April 2019. [Online]. Available: h�p://www.ijcscn.com/Documents/Volumes/vol5issue5/ijcscn2015050506.pdf

[10] E. Mitreva and K. Kaloyanova, “Nosql solutions to handle big data,” in Proc.Doctoral Conference in MIE, 2013, pp. 77–86, accessed 15 April 2019. [On-line]. Available: h�ps://www.researchgate.net/pro�le/Emanuela Mitreva/publication/272491000 NoSQL Solutions to Handle Big Data/links/54e626560cf2cd2e028d10a8.pdf

[11] K. F. Sitalakshmi Venkatraman, S. Kaspi, and R. Venkatraman, “Sql versus nosqlmovement with big data analytics,” IJ Information Technology and Computer Science,pp. 59–66, 2016, accessed 15 April 2019. [Online]. Available: h�ps://journalo�igdata.springeropen.com/articles/10.1186/s40537-015-0025-0

31

[12] S. Sharma, “An extended classi�cation and comparison of nosql big data models,”arXiv preprint arXiv:1509.08035, 2015, accessed 15 April 2019. [Online]. Available:h�ps://arxiv.org/�p/arxiv/papers/1509/1509.08035.pdf

[13] A. Faraj, B. Rashid, and T. Shareef, “Comparative study of relational andnon-relations database performances using oracle and mongodb systems,”Journal Impact Factor, vol. 5, no. 11, pp. 11–22, 2014, accessed 9 June 2019.[Online]. Available: h�ps://www.researchgate.net/pro�le/Azhi Faraj/publication/269104119 COMPARATIVE STUDY OF RELATIONAL AND NON- RELATIONSDATABASE PERFORMANCES USING ORACLE AND MONGODB SYSTEMS/links/54809f150cf22525dcb5fc4d.pdf

[14] A. Nayak, A. Poriya, and D. Poojary, “Type of nosql databases and its comparison withrelational databases,” International Journal of Applied Information Systems, vol. 5, no. 4,pp. 16–19, 2013, accessed 9 June 2019. [Online]. Available: h�ps://www.researchgate.net/pro�le/Dikshay Poojary/publication/302557703 Article Type of nosql databasesand its comparison with relational databases/links/5aeaa2b50f7e9b837d3c40e7/Article-Type-of-nosql-databases-and-its-comparison-with-relational-databases.pdf

[15] K. Orend, “Analysis and classi�cation of nosql databases and evaluation of their abilityto replace an object-relational persistence layer,” Architecture, vol. 1, 2010, accessed 9June 2019. [Online]. Available: h�ps://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.184.483&rep=rep1&type=pdf

[16] J. Domaschka, C. B. Hauser, and B. Erb, “Reliability and availability properties ofdistributed database systems,” in 2014 IEEE 18th International Enterprise DistributedObject Computing Conference, Sep. 2014, pp. 226–233, accessed 15 April 2019. [Online].Available: h�ps://ieeexplore-ieee-org.proxy.ub.umu.se/document/6972071/

[17] E. Brewer, “Cap twelve years later: How the ”rules” have changed,” Computer,vol. 45, no. 2, pp. 23–29, Feb 2012, accessed 15 April 2019. [Online]. Available:h�p://alchem.usc.edu/courses-ee599/downloads/T CO2 CAP12YearsLater.pdf

[18] N. Jatana, S. Puri, M. Ahuja, I. Kathuria, and D. Gosain, “A survey and comparison ofrelational and non-relational database,” International Journal of Engineering Research &Technology, vol. 1, no. 6, pp. 1–5, 2012, accessed 9 June 2019. [Online]. Available: h�p://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.678.9352&rep=rep1&type=pdf

[19] C. M. Wu, Y. F. Huang, and J. Lee, “Comparisons between mongodband ms-sql databases on the twc website,” American Journal of So�-ware Engineering and Applications, vol. 4, no. 2, pp. 35–41, 2015,accessed 9 June 2019. [Online]. Available: h�ps://www.researchgate.net/pro�le/Yin-Fu Huang/publication/317184986 Comparisons between MongoDBand MS-SQL Databases on the TWC Website/links/592bf0cba6fdcc44435c7a0f/Comparisons-between-MongoDB-and-MS-SQL-Databases-on-the-TWC-Website.pdf

[20] T. Dory, B. Mejıas, P. Van Roy, and N. L. Tran, “Comparative elasticity and scalabilitymeasurements of cloud databases,” in Proc of the 2nd ACM symposium on cloudcomputing (SoCC), vol. 11. Citeseer, 2011, accessed 2019-04-09. [Online]. Available: h�p://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.472.3911&rep=rep1&type=pdf

[21] D. Abadi, “Consistency tradeo�s in modern distributed database system design: Cap isonly part of the story,” Computer, vol. 45, no. 2, pp. 37–42, Feb 2012, accessed 9 June 2019.[Online]. Available: h�p://md.ssdi.di.fct.unl.pt/resources/Summaries/abadi-pacelc.pdf

32

[22] V. Anand and C. M. Rao, “Mongodb and oracle nosql: A technical critique fordesign decisions,” in 2016 International Conference on Emerging Trends in Engineering,Technology and Science (ICETETS), Feb 2016, pp. 1–4, accessed 9 June 2019. [Online].Available: h�ps://ieeexplore.ieee.org/abstract/document/7602984

[23] Oracle, “Oracle nosql database transactions 2019,” 2019, accessed 16 April 2019.[Online]. Available: h�ps://www.oracle.com/technetwork/database/nosqldb/overview/nosql-transactions-497227.html

[24] Oracle, “Acid compliant transaction,” accessed 2019-04-24. [On-line]. Available: h�ps://www.oracle.com/technetwork/database/nosqldb/overview/nosql-transactions-497227.html

[25] Oracle, “Chapter 1. introduction to oracle nosql database,” 2019, accessed 2019-04-24. [Online]. Available: h�ps://docs.oracle.com/database/nosql-12.1.3.2/AdminGuide/introduction.html

[26] Oracle, “Kvstore-arkitetkur for oracle nosql,” accessed 2019-04-24. [Online]. Available:h�ps://docs.oracle.com/database/nosql-12.1.3.2/AdminGuide/KVStoreArchitecture.jpg

[27] Oracle, “Replikeringsgrupper i kvstore for oracle nosql,” accessed 2019-04-24. [Online].Available: h�ps://docs.oracle.com/database/nosql-12.1.3.2/AdminGuide/RepGroups.jpg

[28] Oracle, “Ge�ing started with nosql database table java driver,” accessed 2019-04-24. [On-line]. Available: h�ps://docs.oracle.com/en/database/other-databases/nosql-database/18.1/java-driver-table/se�ing-durability-guarantees.html

[29] V. Anand and C. M. Rao, “Mongodb and oracle nosql: A technical critique for design de-cisions,” in 2016 International Conference on Emerging Trends in Engineering, Technologyand Science (ICETETS), Feb 2016, pp. 1–4, accessed 2019-04-26.

[30] “Mongodb count - mongodb manual,” accessed 2019-05-24. [Online]. Available:h�ps://docs.mongodb.com/manual/reference/command/count/#dbcmd.count

[31] C. J. Tauro, S. Aravindh, and A. Shreeharsha, “Comparative study of thenew generation, agile, scalable, high performance nosql databases,” Inter-national Journal of Computer Applications, vol. 48, no. 20, pp. 1–4, 2012,accessed 9 June 2019. [Online]. Available: h�ps://s3.amazonaws.com/academia.edu.documents/30869512/pxc3880336.pdf?response-content-disposition=inline%3B%20�lename%3DComparative Study of the New Generation.pdf&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWOWYYGZ2Y53UL3A%2F20190610%2Fus-east-1%2Fs3%2Faws4 request&X-Amz-Date=20190610T152051Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=7199e15ed2b9cc6367ea8e79614c057395b5eca7a825b3fec86cde1a13a896e8

[32] A. Boicea, F. Radulescu, and L. I. Agapin, “Mongodb vs oracle–databasecomparison,” in 2012 third international conference on emerging intelligentdata and web technologies. IEEE, 2012, pp. 330–335, accessed 9 June 2019.[Online]. Available: h�ps://www.researchgate.net/pro�le/Alexandru Boicea/publication/261040647 MongoDB vs Oracle -- Database Comparison/links/55c2132b08aebc967defd053/MongoDB-vs-Oracle--Database-Comparison.pdf

[33] “db.collection.deleteone() - mongodb manual,” accessed 2019-05-24. [On-line]. Available: h�ps://docs.mongodb.com/manual/reference/method/db.collection.deleteOne/#db.collection.deleteOne

33

[34] “db.collection.deletemany() - mongodb manual,” accessed 2019-05-24. [Online]. Avail-able: h�ps://docs.mongodb.com/manual/reference/method/db.collection.deleteMany/#db.collection.deleteMany

[35] “Mongodb crud operations,” accessed 2019-05-24. [Online]. Available: h�ps://docs.mongodb.com/manual/crud/

[36] “Ge�ing started with oracle nosql database key/value api,” accessed 2019-07-23. [On-line]. Available: h�ps://docs.oracle.com/en/database/other-databases/nosql-database/18.3/java-driver-kv/durability-guarantees.html

[37] “Ge�ing started with oracle nosql database key/value api,” accessed 2019-07-23. [On-line]. Available: h�ps://docs.oracle.com/database/nosql-12.2.4.4/Ge�ingStartedGuide/consistency.html

34

A Appendix

Tabell 2 Generella skillnader mellan Relationella och NoSQL databaserRelationsdatabaser NoSQL

Datarepresentation Sparar strukturerad data itabeller och rader

Manga olika, till exempel:nyckel-varde, dokument, grafer,kolumner.

Schema Struktur och datatyper arforde�nierade. For a� skapa enny typ av objekt maste storadelar av databasen forandras

Vanligtvis mycket dynamiskoch �exibel. Objekt inomsamma grupp kan innehallavalbart antal och typ av data.

Skalning Vertikal skalning. Uppdat-era hardvara for a� utokadatabasen

Horisontell skalning. Utokninggenom a� lagga till y�erligaremaskin eller server.

�ery sprak SQL - strukturerat och stan-dardiserat sprak som anvandsav samtliga relationelladatabaser

Har inget standardiserat sprak.Olika databas leverantorerskapar o�a egna sprak somanvands till varje speci�klosning.

Transaktioner Stod for ACID transaktioner Stodet for ACID transaktionervarierar beroende pa leverantor

Konsistens och tillganglighet Stark konsistens uppra�halls.Konsistens prioriteras hogre antillganglighet och prestanda.

Eventuell till stark konsistenserbjuds. Valbara nivaer pa kon-sistens, tillganglighet och pre-standa kan tillampas beroendepa anvandningsomrade.

Prestanda Da stark konsistens uppra�hallsblir prestandan for insa�ning-och uppdateringsoperationerberoende av hur snabba skriv-operationer ar. Prestandankan maximeras genom a�forba�ra hardvara och anvandaarbetsminnet for a� utforaoperationer.

Kan maximera prestandangenom a� reducera konsisten-snivan.

Da information om e� objektkan vara uppdelat i �era olikatabeller och rader kan multi-pla sammanslagningar kravasfor uppdatering eller las opera-tion.

Vanligtvis ligger all informa-tion om e� objekt samlat i e�foremal vilket tillater uppdater-ing med endast en operation.

35

UMEÅ UNIVERSITET