Jämförelse av Neo4j och MySQL för en traditionell informationsapplikation

Teknik och samhälle Datavetenskap Examensarbete 15 högskolepoäng, grundnivå Jämförelse av Neo4j och MySQL för en traditionell informationsapplikation A comparison of Neo4j and MySQL for a traditional information application Raheb Naisan Examen: Kandidatexamen 180 hp Huvudområde: Datavetenskap Program: Spelutveckling Datum för slutseminarium: 2013-08-30 Handledare: Johan Gustavsson Andrabedömare: Bengt Nilsson

Sammanfattning Grafdatabasen och NoSQL-rörelsen har på senaste tid fått mycket uppmärksamhet och popularitet. Grafdatabasen har ett rykte om sig att vara snabb och eektiv för applikationstyper som innehåller enorma mängder data och många komplexa relationer. Studier undersökta i denna rapport visar att de tidigare utförda experimenten jämför databaserna för applikationer som har gynnat grafmodellen. Denna rapport har som syfte att dels undersöka databaserna men även att utföra ett experiment. Syftet med experimentet är att ta reda på ifall grafdatabasen Neo4j kan ersätta relationsdatabasen MySQL för en traditionell informationsapplikation som vanligtvis implementeras med en relationsdatabas. Studiens resultat visar att Neo4j presterar väldigt bra vid insättning och sökning, dock tar studien upp era faktorer som spelar roll för valet av databas. Bristen av säkerhet och stöd är sådana faktorer som gör att relationsdatabasen kan vara det optimala valet för en traditionell informationsapplikation.

Abstract Graph databases and the NoSQL movement has recently gained much attention and popularity. Graph databases has a reputation for being fast and ecient for application types that contain huge amounts of data and many complex relationships. Studies examined in this report show that the previous conducted experiments compare databases for applications that have favored the graph model. This report aims to examine both databases, but also to perform an experiment. The purpose of this experiment is to nd out if the graph database Neo4j can replace the relational database MySQL for a traditional information application which is usually implemented using a relational database. Results demonstrate that Neo4j performs very well at insertion and retrieval, however, the study addresses several factors that play a role in the choice of database. The lack of security and support are some factors that could make the relational database the best choice for a traditional information application.

Innehåll 1 Inledning 1 1.1 Bakgrund..................................... 1 1.2 Problembeskrivning................................ 1 1.3 Syfte........................................ 2 1.4 Frågeställning................................... 2 1.5 Avgränsningar................................... 2 1.6 Målgrupp..................................... 2 2 Grundteori 3 2.1 Databaser..................................... 3 2.2 Databashanterare................................. 3 2.3 Relationsmodellen................................ 3 2.3.1 Relationsdatabasen............................ 4 2.3.2 SQL.................................... 5 2.3.3 MySQL.................................. 5 2.3.4 JOIN-Problematiken........................... 5 2.4 ACID....................................... 5 2.5 BASE....................................... 6 2.6 CAP........................................ 6 2.7 NoSQL....................................... 7 2.7.1 NoSQL-Modeller............................. 7 2.8 Graf-modellen................................... 8 2.8.1 Grafteori................................. 8 2.8.2 Graf-databasen.............................. 8 2.8.3 Kritik mot grafdatabasen........................ 8 2.8.4 Neo4j................................... 9 2.8.5 Cypher Query Language......................... 9 3 Metod 10 3.1 Litteratur och söktermer............................. 10 3.2 Experimentet................................... 11 3.2.1 Experimentets syfte........................... 11 3.3 Val av utrustning samt mjukvara........................ 11 3.4 Applikationstypen................................ 11 3.5 Implementation.................................. 12 3.5.1 Implementation av MySQL....................... 13 3.5.2 Implementation av Neo4j........................ 13 3.6 Testfallen..................................... 14 3.6.1 Testfall för Insättning.......................... 14 3.6.2 Testfall för Sökning och ltrering av data............... 15 3.7 Metodkritik.................................... 15

4 Litteraturstudiens resultat 17 4.1 Litteratur..................................... 17 4.2 Resultaten..................................... 17 4.3 Vilka jämförelser av relations och NoSQL -databaser nns redan och hur har de utförts?.................................. 17 4.3.1 A comparison of a graph database and a relational database..... 17 4.3.2 SQL databases v. NoSQL databases.................. 18 4.3.3 Comparative Analysis of Relational And Graph Databases...... 18 4.3.4 SQL vs NoSQL.............................. 19 4.3.5 Using MongoDB to implement textbook management system instead of MySQL............................... 19 4.4 En beskrivning av nyckelegenskaperna för MySQL och Neo4j........ 19 4.4.1 Mognad och nivå av stöd........................ 19 4.4.2 Skalning.................................. 20 4.4.3 Flexibilitet................................ 20 4.4.4 Säkerhet.................................. 21 4.5 Vilka applikationstyper passar bäst för databaserna?............. 21 5 Experimentets resultat 22 5.1 Resultat...................................... 22 5.1.1 Resultat för Insättning.......................... 22 5.1.2 Resultat för sökning och ltrering.................... 22 6 Analys och diskussion 24 6.1 Analys av litteraturstudien........................... 24 6.2 Analys av experimentet............................. 25 6.3 Svar på frågeställningen............................. 26 6.4 Delmål 1: Undersökning av relation- och grafdatabasen............ 26 6.4.1 Vilka jämförelser av relations- och NoSQL-databaser nns redan och hur har de utförts?............................ 26 6.4.2 En beskrivning av nyckelegenskaperna för MySQL och Neo4j.... 26 6.4.3 Vilka applikationstyper passar bäst för databaserna?......... 26 6.5 Delmål 2: En applikationstyp som vanligtvis implementeras med en relationsdatabas.................................... 26 6.5.1 Vilken av databaserna presterar snabbast inom operationerna: insättning och sökning?.......................... 26 6.5.2 Kan grafdatabasen ersätta relationsdatabasen för en traditionell informationsapplikation?.......................... 27 7 Slutsats 28 Referenser 29 8 Bilagor 31

1 Inledning I detta avsnitt presenteras uppsatsens bakgrund, problembeskrivning, frågeställning samt syfte. 1.1 Bakgrund Relationsmodellen har använts inom databasvärlden länge och är den databasmodell som dominerat längst [4, 16]. Modellen använder sig utav språket SQL och modellerar delar av världen i form av tabeller. Dessa tabeller existerar idag i nästan alla sammanhang där sammanhängande data sparas elektroniskt. Oavsett om du använder en bankomat, använder dig utav ett register eller stoppar in mynt i en biljettautomat så är det förmodligen en relationsdatabas som hanterar informationen. Tabellerna i en relationsdatabas är ett utmärkt sätt att hålla informationen organiserad och med rätt struktur kan databasen prestera snabbt och eektivt. Det är inte förrän på senare år alternativ till denna modell vuxit fram och tagits emot med stora framgångar. De nya konkurrenterna tillhör den så kallade NoSQL-rörelsen, dvs databaser som inte använder sig utav språket SQL. Det är inte bara språket som skiljer databaserna åt, relationsdatabasen anses vara föråldrad och anses inte kunna hantera den stora mängd data som dagens applikationer kräver. Förutom att kunna hantera stor mängd data eektivt så anses NoSQL-databaserna vara skalbara och dynamiska till skillnad från relationsdatabasen [2, 9, 22]. En av de mer populära NoSQL-databaserna och även den databas som kommer att stå i centrum för denna uppsats är grafdatabasen. Istället för att spara data i form av tabeller kan data nu sparas i sammankopplade nätverk av noder. Dessa nätverk har fått mycket uppmärksamhet i och med framväxten av de sociala nätverken. Applikationer som Facebook, Twitter och Google Plus är bra exempel på när NoSQLdatabaser används och prestandaskillnaden mot relationsdatabasen visas tydligt. NoSQLrörelsen menar att relationsdatabasen brister på era punkter, några av de mest kritiserade punkterna är: Skalbarhet. Att kunna växa och hantera stora datamängder med snabb prestanda. Relationsdatabasen kan innehålla enorma datamängder men vid operationer som till exempel sökning och ltrering påverkas prestandan negativt av mängden data. Tabeller. All data passar inte in i tabeller, data som ständigt ändrar storlek och form eller data som helt enkelt är ostrukturerad. Varietet. Att ändra strukturen i en relationsdatabas som körs kan vara väldigt kostsamt och undviks ofta, dagens applikationer uppdateras och ändras kontinuerligt. 1.2 Problembeskrivning Just nu sker det en trend inom databasvärlden. Allt er väljer att jobba med NoSQLdatabaser, främst grafdatabasen istället för den klassiska relationsdatabasen. En av anledningarna till att detta sker nu är för att det är så extremt stora mängder data som sparas i dagens applikationer. En vanlig åsikt bland NoSQL-rörelsen är att relationsdatabasen inte 1

kan hantera stora mängder data eektivt och att grafdatabasen i rätt applikation kan utföra en sökning som tar minuter i MySQL på endast millisekunder. Dock kan informationen om vad som är en rätt applikation anses vara bristfällig. Detta ger stöd till en studie på vilka egenskaper som är viktiga inför ett databasval. Egenskaper för en så kallad rätt applikation kan hittas utspritt men att hitta ett tydligt test eller experiment har visat sig vara svårt. De experiment som studerats i den tidigare forskningen för denna rapport har testat en grafdatabas mot en relationsdatabas för en applikation vars datamodell varit till fördel för grafmodellen. Detta ger stöd till ett experiment där grafdatabasen testas mot en relationsdatabas där applikationstypen besitter egenskaper som teoretiskt gynnar relationsmodellen. 1.3 Syfte Studiens syfte är att undersöka grafdatabasen och relationsdatabasen för att ta reda på vilka applikationstyper de hanterar bäst. Studien ska även genom en jämförelsestudie av Neo4j och MySQL undersöka hur grafdatabasen presterar för en applikation som vanligtvis implementeras med en relationsdatabas. 1.4 Frågeställning Denna studies frågeställning har delats upp i två delmål och dess underfrågor. Delmål 1: Undersökning av relation- och grafdatabasen a) Vilka jämförelser av relations- och NoSQL-databaser nns redan och hur har de utförts? b) En beskrivning av nyckelegenskaperna för MySQL och Neo4j c) Vilka applikationstyper passar bäst för databaserna? Delmål 2: En applikationstyp som vanligtvis implementeras med en relationsdatabas. a) Vilken av databaserna presterar snabbast inom operationerna: insättning och sökning? b) Kan grafdatabasen ersätta relationsdatabasen för en traditionell informationsapplikation? 1.5 Avgränsningar Denna rapport fokuserar på relationsdatabasen MySQL och grafdatabasen Neo4j. Valet av MySQL beror på databasens enorma stöd och popularitet. Neo4j har under dem senaste åren vuxit enormt och är idag en av de största databaserna inom grafdatabas-teknik [21]. 1.6 Målgrupp Denna rapport är avsedd för alla med intresse för IT och databasteknik. Rapporten kan intressera databasanvändare som är osäkra inför val av databastyp. 2

2 Grundteori Detta avsnitt är avsett att ge läsaren en grundläggande förståelse för databasteknik. 2.1 Databaser I Fundamentals of Database Systems [10] denieras en databas som A database is a collection of related data. Data i detta fallet står för viken typ av information som helst. Denitionen menar att data måste vara relaterad för att få kallas för en databas, till exempel uppgifter som namn, personnummer och adress anses vara relaterad och beskriver en person. Detta är en bred denition av ordet databas. I boken Fundamentals of Database Systems nämns även tre egenskaper som kan tillämpas för att få kalla sin samling av data för en databas [10]. Egenskaperna är följande: Databasen ska beskriva någon aspekt av den riktiga världen Databasen ska innehålla logiskt sammanhängande data Databasen ska ha ett tydligt ändamål Dessa egenskaper beskriver en databas som kan representera en del av världen genom sammanhängande data. Databasen hanteras och uppdateras av en bestämd grupp för ett specikt ändamål. 2.2 Databashanterare En databashanterare (Database Management System) är ett program eller ett system som lagrar och hanterar databaser. Databashanterarens primära uppgifter är att deniera, konstruera, manipulera och att dela med sig av databasen [10]. Genom databashanteraren strukturerar användaren databasen och denierar dess datatyper. Detta sker oftast genom databasens skriptspråk men kan även att uppnås genom ett medföljande graskt verktyg. Databasen lagras på ett eller era fysiska medium och administreras ifrån databashanteraren. Att manipulera en databas kan innebära att göra en insättning, förfrågning av något slag, uppdatering eller att generera en visning av data. Databashanteraren delar med sig av databasen till alla tillåtna användare. Vissa databashanterare erbjuder även olika säkerhetsåtgärder. Detta kan t. ex vara olika skyddstekniker inför systemkraschar och andra fel eller administrering av tillåtna användare. Några databashanterare som anses vara välkända är MySQL, Microsoft SQL Server, Oracle, PostGreeSQL och IBM DB2 [14]. 2.3 Relationsmodellen Relationsmodellen är idag den vanligaste databasmodellen och den modell som har dominerat databasvärlden längst [4, 16]. Modellen grundades 1969 av Edgar F. Codd. Relationsmodellen går ut på att data lagras i relationer. En relation är samma sak som en tabell [11]. Databashanterare som hanterar just relationsdatabaser kallas relationsdatabashanterare (Relational Database Management System). 3

2.3.1 Relationsdatabasen Relationsdatabasen kan bestå utav en eller era tabeller innehållande kolumner och rader. Tabellens kolumner berättar vilken typ av data tabellen får innehålla. Var kolumn får endast innehålla samma typ av data. Varje rad i tabellen håller en bit data. För att enklare kunna föreställa sig tabellen kan varje rad ses som en post och varje kolumn som postens attribut. Tabell 1 representerar en anställd på ett företag. Tabellens kolumner är anställningsnummer, förnamn och efternamn. Varje rad i tabellen beskriver en unik anställd på företaget. Tabell 1: Tabellen representerar en anställd anställningsnummer förnamn efternamn 001 Johan Nilsson 002 Raheb Naisan 003 David Batra Det är vanligt förekommande att tabellen använder sig utav en eller era nycklar. Den vanligaste nyckeln är primärnyckeln som fungerar som en sorts pekare för tabellen. Den kolumn som sätts som primärnyckel måste vara unik. I tabell 1 vore det naturligt att tilldela anställningsnummer som primärnyckel. Tabellen kan då inte innehålla era rader med samma anställningsnummer. För att koppla samman tabell 1 med en annan tabell krävs det att man använder sig utav främmande nycklar. En främmande nyckel är en referens till en primärnyckel i samma eller en annan tabell. Tabellen Avdelningar (tabell 2) beskriver företagets olika avdelningar och vem som är chef över avdelningen. Tabellen har kolumnerna Avdelningsnummer, benämning och chef. Tabell 2: Tabellen Avdelningar Avdelningsnummer benämning chef A kundservice 002 B försäljare 001 I tabell 2 är kolumnen chef en främmande nyckel för nyckelattributet anställningsnummer i tabell 1. Vi kan alltså utifrån tabell 2 läsa av att Raheb är chef för avdelningen kundservice och att Johan är chef för avdelningen försäljare. En tredje tabell (tabell 3) visar vilken anställd som tillhör vilken avdelning genom att ha kolumnerna Anställd som främmandenyckel till anställningsnummer i tabell 1 och Avdelning som främmandenyckel till Avdelningsnummer i tabell 2. I tabell 3 utgör båda kolumnerna tillsammans primärnyckeln. Tabell 3: Tabellen håller reda på vilken avdelning de anställda tillhör Anställd Avdelning 001 B 002 A 002 B 003 B Utifrån denna tabell 3 kan vi enkelt se att Johan tillhör avdelningen försäljare, Raheb tillhör båda avdelningarna och David tillhör avdelningen försäljare. 4

2.3.2 SQL SQL eller Structured Query Language som det heter är standard skriptspråket för relationsmodellen. Språket utvecklades på IBM av Donald D. Chamberlin och Raymond F. Boyce i början av 1970 talet [13]. SQL tillåter "cross-platform", dvs att det fungerar oberoende av plattform. Språket tillåter användaren att hantera databasen med kommandon som t.ex CREATE och DELETE som skapar och tar bort tabeller, INSERT och UPDATE som lägger till och uppdaterar data. Förfrågningar (Queries) är den främsta operationen inom språket. En förfrågning är en kallelse eller fråga till databasen att få en viss data representerad. Förfrågningarna inleds med kommandot SELECT och kan tilldelas vissa ltreringar. T.ex SELECT name FROM kunder WHERE kundid = '03'. Här hade databasen tagit fram namnet på kunden med kundid 3. 2.3.3 MySQL MySQL är en av världens mest använda databaser [16]. MySQL är en så kallad opensource databas vilket innebär att användaren själv har tillgång till källkoden. Detta har bidragit till att MySQL idag har hundratals olika implementeringar på många olika plattformer, det som knyter dem alla samman är språket SQL. MySQL skeppas tillsammans med databashanteraren MySQL WorkBench som är ett graskt administrativt verktyg för att bland annat skapa, hantera, modellera och dela databasen [15]. MySQL följer ACIDmodellen genom automatiska åtgärder och kan hanteras av era användare samtidigt. 2.3.4 JOIN-Problematiken MySQL hanterar sin data med hjälp av tabeller. En större databas kan innehålla hundratals eller till och med tusentals tabeller. Om det sker en förfrågning om data som nns på era tabeller så slås dem tillfälligt ihop med en så kallad JOIN operation. Med en JOIN operation kan man alltså generera nya temporära tabeller genom att slå samman tabeller och ge dem villkor för att nnas i den nya tabellen [12]. Detta är en väldigt nödvändig och förekommande operation inom hantering av relationsdatabaser. Dock är den väldigt kostsam och ses av många som en av relationsdatabasens största nackdelar [3]. 2.4 ACID ACID är namnet på en samling av egenskaper som databasens transaktioner kan ha. En transaktion är en följd av olika operationer som automatiskt utförs av databashanteraren. ACID-egenskaperna garanterar användarna att databasen håller en viss standard [11]. AC- ID har länge setts som en garantimall för endast relationsdatabaserna, fast på senare år har de även tillämpats mer eller mindre på NoSQL databaser. ACID står för Atomic : (Atomicitet) innebär att en transaktion antingen ska fullföljas eller inte ske alls. Egenskapen garanterar att databasen inte lämnas med delar av information vid t. ex el-avbrott eller annan störning [11]. 5

Consistent : (Konsistens) Om databasen är konsistent innan en transaktion så måste den även vara konsistent efter transaktionen. Databasen måste alltså kontrollera så att alla integritetsvillkor är uppfyllda [11]. Isolated : (Isolering) Samtliga transaktioner ska hållas isolerade ifrån varandra. Oavsett om det sker era transaktioner samtidigt så ska dem alltså ske för sig [11]. Durable : (Hållbarhet) Efter en lyckad transaktion ska ändringen som genomförts aldrig försvinna ut databasen, tex vid krasch av dator eller disk. Efter en slutförd transaktion ska alltså ändringen som genomförts vara permanent [11]. 2.5 BASE BASE är en samling garantier som många NoSQL databaser tillämpar istället för ACIDgarantierna. BASE står för Basic Availability : (Tillgänglighet) Databasen antas att alltid vara tillgänglig fast än delar av den kan vara otillgängliga [12]. Soft-state : Databasen behöver inte var konsekvent [12]. Eventual consistencty : Databasen kan vara konsistent vid en senare tidpunkt [12]. BASE egenskaperna är inte lika skärpta som ACID egenskaperna. Användare av NoSQLdatabaser kan alltså inte längre lita på att databashanteraren sköter de tidigare garantierna. 2.6 CAP CAP Theorem är en teori som föreslogs av Brewer år 2000 [2]. Brewer menar med CAP att en databashanterare inte kan ta hänsyn till följande tre garantier samtidigt. Det är värt att notera att Consistency inom CAP inte betyder samma sak som Consistency för ACID ( se 2.4). Consistency Availability Partition tolerance Consistency innebär att all ny-inlagd data i en databas alltid ska vara tillgänglig samtidigt för alla användare. Availabilty står för att databasen alltid ska vara tillgänglig för att hanteras. Partition tolerance innebär att databasen fortfarande ska kunna läsas och skrivas till fastän delar av den är otillgängliga [2]. 6

2.7 NoSQL NoSQL eller Not Only SQLsom det står för beskriver en databas som inte använder sig utav relationsmodellen och hanteras med SQL. Detta fenomen har vuxit fram under de senaste åren för att bemöta de utmaningar som skapats ifrån moderna webb-applikationer och andra tjänster som handskas med enorma databaser som är dynamiska i både struktur och data [12]. De mest drivande faktorerna för att NoSQL har slagit igenom är Volym Hastighet Varietet Behovet av att hantera större volym av data har varit en av de största faktorerna för NoSQLs framgång. Relationsdatabasen hanterar de stora volymerna dåligt då databasen blir långsam och behovet av JOIN-tabeller ökar. Moderna databaser har inte bara mer volym än tidigare, hastigheten i hur ofta datatypen och databasens struktur ändras har också ökats. Att en databas ändras över tiden är inget konstigt men det är svårt att förutse vilken typ av data databasen ska kunna hantera i framtiden. Att modiera en databas har tidigare varit väldigt kostsamt, NoSQL hanterar ändringarna mycket mer eektivt. Data kan se ut på många olika sätt, oavsett om det handlar om dokument, skrivna objekt eller annan form så behöver data inte längre formas och modeleras i tabeller [12]. 2.7.1 NoSQL-Modeller NoSQL modellerna kan se ut och hantera data på många olika sätt. Ett exempel på detta är Dokument-databasen som kan innehålla dokument av olika slag, dessa behöver inte vara sammanhängande på något sätt. De fyra största databas-modellerna inom NoSQL är Document : Dokument-databasen kan ses som en elektronisk bokhylla där var bok har ett unikt id. Dokumenten söks efter och hämtas med hjälp av sitt id. En av databasens styrka är att dokumenten är självständiga. Det innebär att databasen inte behöver kostsamma transaktioner. Dokument-databasen är också välkänd för att kunna skalas väl och delas upp i era delar (Sharding) [12]. Key-Value : I en Key-Value databas sparas värdet i en hashtable och får en nyckel tilldelad till sig. Key-Value databasen lockar användare då databasen är snabb att konstruera och behöver inga scheman [12]. Column Stores : (Kolumndatabas) I en kolumndatabas sparas värdet i en kolumn. Kolumnen består av ett namn och dess värde. Kolumnen kan gå ihop med era kolumner och bilda en superkolumn. Dessa kolumner kan ingå i en rad som även har en unik radnyckel. Denna rad kan innehålla kolumner och superkolumner som nås genom radens nyckel [12]. Graph-DB : (Grafdatabas) Grafdatabasen kommer att förklaras djupare i nästa sektion. 7

2.8 Graf-modellen Att använda graf-modellen inom databasvärlden har under de senaste åren blivit väldigt populärt. Graf-tänket är dock inte nytt. Det uppkom redan under 1700-talet av matematikern Leonhard Euler som grundade graf-teorin för att försöka lösa det kända problemet The Königsberg Bridges Problem [12]. Euler ck som uppgift att undersöka ifall det fanns en gångväg runt staden Köningsberg som passerade stadens alla sju broar. Broarna ck endast bli passerade en gång. Denna uppgift ledde till att Euler ritade upp ett nätverk med noder som representerade landmassa och bågar som representerade broarna. Euler kunde med hjälp av sin graf komma fram till att det inte fanns en lösning på problemet. Graf-teorin har sedan efter förbättrats och eektiviserats av matematiker och av forskare i andra ämnen. Idag tillämpas graf-teorin på bland annat databaser och är en lösning på många av dagens utmaningar så som stora sociala-nätverk och andra tjänster som är beroende av komplexa kopplingar. 2.8.1 Grafteori En graf består utav punkter och kopplingar. Punkterna kallas för noder och kopplingarna kallas för bågar. En nod kan vara kopplad med en eller era andra noder. Både noderna och bågarna kan ha värden och attribut. Bågarna kan även vara riktade eller oriktade. Dessa komponenter skapar tillsammans ett nätverk som kan traverseras genom väldenierade algoritmer. Med hjälp av grafen kan man modellera alla möjliga olika scenarion där relationerna spelar stor roll. Graf-teorin är också populär i tjänster där den kortaste eller snabbaste vägen är av intresse. Ett exempel på detta är applikationer som olika reseplanerare vars uppgift är att leta fram den snabbaste vägen till ett resemål. 2.8.2 Graf-databasen Noderna i en grafdatabas fungerar som en behållare för egenskaper. Egenskaperna sparas i form av ett key-value par. Nyckeln är oftast av datatypen String och värdet kan vara av vilken datatyp som helst. Bågarna i en grafdatabas måste vara kopplade till en eller era noder. I en Neo4j-grafdatabas måste de även vara riktade [17]. Det innebär att en båg alltid måste ha en start och en slut nod. Bågarna har även en etikett som beskriver kopplingen och dess riktning. En av grafdatabasens största styrkor är att bågarna har egna attribut och värden, relationerna mellan noderna spelar lika stor roll som själva noderna. 2.8.3 Kritik mot grafdatabasen Många som talar för relationsmodellen menar att en grafdatabas inte kan ge ett fullständigt säkert och riktigt svar på förfrågningar. Grafdatabasen följer vanligtvis inte ACIDgarantierna och detta anses vara en av dess största brister [2]. Tidigare har databaser som inte följt ACID-standarden inte setts som riktiga databaser. Dock talas det även om att ACID-standarden inte längre är nödvändig för dagens databassystem. Det är också värt att nämna att grafdatabasen är relativt ny och genomgår många förändringar och uppdateringar. Många säger att det är i tjänst av stora företag som Facebook, Google och Twitter som Graf-databasen hamnat i så stor fokus. 8

2.8.4 Neo4j Neo4j är en open-source grafdatabas och är för tillfället världsledande inom sitt fält [17]. Neo4j sparar data i noder med kopplade och riktade relationer. Databasen är baserad på Java och erbjuder användaren ett ramverk av eektiva och färdigskrivna traverseringsmetoder. Neo4j använder sig utav utav skriptspråket Cypher (se 2.8.5). Neo4j kan drivas genom en medföljande standalone-server eller inbäddad i en Java-applikation [18]. Både implementerings möjligheterna har sina för- och nackdelar. Neo4j REST API låter användaren kommunicera med servern från klientapplikationer skrivna i många olika språk, detta sker genom olika REST-bibliotek som kan hittas på bland annat Neo4js hemsida. Kvalitén skiljer sig ganska mycket på dessa bibliotek och majoriteten av dem är i dagsläget inte färdigskrivna och saknar viss funktionalitet. Implementeras Neo4j inbäddad i Java så får användaren en direkt tillgång till Neo4j Core-API, detta kan leda till högre prestanda vid operationer som bland annat traversering. Den Java inbäddade implementationen låter användare skriva egna traverserings operationer, 2.8.5 Cypher Query Language Cypher Query Language eller bara Cypher som det kallas för är det språk som används för att hantera en Neo4j grafdatabas. Likt SQL är språket ett "Humane query language"[17]. Cypher är menat för utvecklare och professionella databasanvändare. Syftet med Cypher är att enkelt kunna hantera databasen utan att behöva förstå sig på algoritmerna och tekniken som ligger bakom. Förfrågningar om noder och förhållande sköter Cypher automatiskt genom att hitta olika mönster på egen hand. Detta sökande efter det snabbaste eller bästa mönster är kostsamt men kan gå väldigt fort i en välstrukturerad graf. 9

3 Metod Utgångspunkten för metodvalet är att undersökningen ska ge en klar bild av databasernas styrkor och svagheter, vilken applikationstyp som passar respektive databas och hur databaserna presterar för en applikationstyp som vanligtvis implementeras med en relationsdatabas. Detta sker genom både en litteraturstudie och ett praktiskt experiment. Litteraturstudien kommer att genomföras genom att söka i relevanta databaser med angivna kriterier för att hitta litteraturen. Tanken är att få en klar bild över hur databaserna har jämförts tidigare samt vilka egenskaper som varit i fokus. Genom analys av artiklarna kommer litteraturstudien att försöka besvara rapportens första delmål av studiens frågeställning. Studiens andra delmål kommer att besvaras genom ett praktiskt experiment. Syftet är att ta reda på hur en Neo4j grafdatabas presterar jämfört med en MySQL relationsdatabas för en applikationstyp som teoretiskt gynnar relationsmodellen. Applikationen för detta experiment är en enkel e-handelssida. Anledningen till valet av applikation är E-handelssidornas kraftiga beroende av databaser men också främst på grund av att applikationstypen anses vara en traditionell informationsapplikation. E- handelssidans databas innehåller få förhållanden och är lätt att modellera i tabeller. Applikationen kommer inte att konstrueras fullständigt i detta experiment, det är endast databasen samt en enklare klient som konstrueras. Grafdatabasen som implementeras är en Neo4j databas och relationsdatabasen är en MySQL databas. MySQL följer den traditionella relationsmodellen, vilket innebär att databasen sparar all sin data i tabeller med kolumner och rader. Grafdatabasen är strukturerad efter grafmodellen. Istället för tabeller, så sparas data i form av noder och relationer mellan noderna. Skillnaderna i strukturen mellan databaserna kan påverka experimentets resultat och därför följer båda databaserna samma applikationsmall. Mallen beskriver vilken data som ska hanteras och har baserats på populära e-handel sidor som www.cdon.se, www.nelly.com och www.komplett.se. Experimentet kommer att utföras genom att mäta exekveringstiderna för fördenierade operationer. Operationerna är insättning och sökning. Dessa operationer har valts då de anses representera verkliga operationer som sker i vardagen. Insättning representerar en operation som sker på den administrativa sidan och sökning är en vanligt förekommande operation på användarens sida. Dessa operationer kommer att ske under olika mängdförhållanden. Tanken är att få en bild av hur snabbt databaserna presterar beroende på storlek av verksamhet. Både litteraturstudiens och experimentets resultat kommer att analyseras och presenteras för vidare diskussion. 3.1 Litteratur och söktermer Litteraturen till denna studie har sökts efter i följande databaser: ACM Digital Library, Malmö Högskolas bibliotek, IEEE Xplore och International Journal of Soft Computing and 10

Engineering. Nedan presenteras en lista över några av de söktermer som används. NoSQL, MySQL, SQL, Neo4j, PostgreSQL relationshipdatabase, graphdatabase, relational model, graph comparison SQL NoSQL, performance test MySQL Neo4j database performance test Kriterierna för att litteraturen har blivit godkänd för denna studie är att artikeln måste ha varit publicerad efter 2010 och ha att göra med antingen MySQL eller NoSQL. Anledningen till att artiklar innan 2010 inte använts är för att minska risken för att studera irrelevanta och utdaterade tekniker. 3.2 Experimentet För att undersöka prestandan av databaserna har två operationer valts, insättning och sökning. Dessa operationer kommer att testas för både databaserna under samma omständigheter. 3.2.1 Experimentets syfte Experimentets syfte är att besvara studiens andra delmål (se 1.4). Experimentet ska alltså jämföra en Neo4j grafdatabas mot en MySQL relationsdatabas genom att mäta exekveringstiderna för operationerna insättning och sökning (se 3). Experimentets resultat kommer att bidra med ökad kunskap inför studiens primära problemställning: Kan grafdatabasen ersätta relationsdatabasen för en traditionell informations applikation? (se 1.4). 3.3 Val av utrustning samt mjukvara Experimentets databaser kommer att köras på samma system fast vid olika tillfällen. Specikationer för systemet är följande. Processor: Intel Core i7-2600 CPU @ 3.40GHz 3.40GHz Installed memory(ram): 16.0GB Samsung SSD Disk 830 Series: 120GB Operativsystem: Windows 8 64-bit 3.4 Applikationstypen Databaserna modelleras för en traditionell informationsapplikation, i detta fallet en E- handelssida. Applikationen ska kunna hantera information om användare, administratörer, kategorier, produkter och beställningar. De olika databaserna som testas i detta experiment hanterar data på olika sätt. MySQL sparar data och relationer i tabeller medan Neo4j 11

sparar data i noder som är sammankopplade med andra noder. För att få ett rättvist resultat måste databaserna följa en gemensam mall som beskriver vilken data de ska kunna hantera. Figur 1 visar både vilken typ av data som databaserna ska kunna hantera och kopplingen mellan informationen. Tabell 4 beskriver applikationens data. Figur 1: En gur över applikationen Tabell/Nod Användare Administratörer Kategorier Produkter Beställningar Orderlistor Tabell 4: Applikationens data Egenskaper namn, adress och inloggningsuppgifter referenser till de användare som är administratörer kategorierna Musik, Spel och Film artikelnummer, beskrivning och pris referens till beställd produkt och referens till orderlistan den tillhör orderid och referens till orderns ägare 3.5 Implementation De valda databaserna (Neo4j och MySQL) kan drivas och implementeras på era olika sätt. I rapportens experiment kommer Neo4j att implementeras på två olika sätt. MySQL kommer att implementeras på ett sätt men testas med två klienter skrivna i olika programmeringsspråk. Dessa implementationer är följande. MySQL Database Server med en Java klient MySQL Database Server med en C# klient Neo4j med servern och klienten inbäddad i Java Neo4j standalone-server med en C# klient. Samtliga klienter kommer att innehålla operationer som: uppkoppling till server, frånkoppling, insättning av medlemmar, produkter, beställningar och sökning efter en given användares samtliga produkter. MySQL servern kommer att drivas som en Windows-tjänst för båda MySQL klienterna och databasen kommer att manipuleras genom skickande av SQL-frågor. Klienterna som 12

manipulerar databasen kommer dock att konstrueras i två olika programmeringsspråk, nämligen i Java och C#. Neo4j servern kan implementeras på två olika sätt. Servern kan drivas inbäddad i Java (Neo4j Embedded Server) men den kan också drivas som en standalone-server. För att öka experimentets validitet kommer båda implementationerna att testas. I den ena implementationen kommer en Neo4j standalone server att drivas och att manipuleras genom en klient skriven i programmeringsspråket C#. Klienten kommer att kommunicera med servern genom Neo4js REST API. Servern kommer att manipuleras av C# klienten genom skickande av Cypher-frågor. I experimentets andra Neo4j implementation kommer både servern och klienten vara inbäddad i en Java applikation. Detta innebär att servern kommer att manipuleras internt ifrån samma applikation. 3.5.1 Implementation av MySQL MySQL Database Server drivs som en Windows-tjänst. För att skapa en databas på servern har applikationen MySQL Workbench används. MySQL Workbench är ett graskt verktyg som låter användaren hantera en eller era databaser. Båda MySQL klienter använder sig utav samma MySQL server. MySQL Workbench har även använts för att exekvera SQL-skript som skapar och återställer databasens tabeller. MySQL-databasen innehåller följande tabeller. Tabell medlem admins kategori artikel bestallning innehaller Tabell 5: Tabeller som ingår i MySQL modellen Beskrivning e-post, namn, adress och inloggningsuppgifter referenser till medlem som är administrator kategorinamn artikelnummer, namn, beskrivning, saldo orderid, datum och referens till beställningens ägare referens till beställningens id, beställda artikeln och antalet Varje rad i tabellen medlem representerar en medlem i databasen. Tabellens nyckelattribut är email. Attributet används för att dels hålla reda på vilken användare som är en administrator men även för att koppla en medlem till en beställning. En beställning innehåller alltså detaljer om: sin beställnings-id, medlemmen som utfört beställningen och datumet beställningen skett. Tabellen innehaller innehåller information om vilken artikel som blivit beställd, antalet och till vilken order den tillhör. Figuren nedanför visar ett klassdiagram över databasens tabeller och kopplingar. 13

Figur 2: Ett klass-diagram över MySQL-databasen 3.5.2 Implementation av Neo4j Neo4j servern kan antingen drivas inbäddad i en Java applikation eller som en standaloneserver. Båda implementationerna kommer att genomföras för rapportens experiment. Standalone-servern kommer att drivas som en Windows-tjänst och hanteras av en klient skriven i C#. Kommunikationen mellan servern och klienten är möjlig genom ett Neo4j.NET bibliotek konstruerad av Neo4js partner Readify [20]. Biblioteket använder sig utav Neo4js REST API och tillåter enkla CRUD-operationer samt skickande av Cypher-frågor. I den andra implementationen kommer Neo4j drivas inbäddad i en Java applikation. Både servern och klienten kommer att drivas och kommunicera i samma applikation. I denna implementation kommer manipuleringen av databasen ske direkt i Neo4j Core-API, det vill säga, det kommer inte att ske ett skickande av Cypher-frågor. Grafdatabasen kommer att följa samma struktur för båda implementationer. Grafdatabasen har delvis modellerats efter en mall som presenterades av Neo4j [19]. Figur 3 visar grafdatabasens struktur. Huvudnoderna users och products (se Figur 3) är kopplade genom en start-nod. Noden users har sedan kopplingar till databasens samtliga användare. En användare kan även vara administrator, detta visas genom att användarnoden har en koppling till noden admins. Noden products har kopplingar till databasens produktkategorier, dessa kategorier har sedan kopplingar till innehållande produkter. I Figur 3 innehåller kategorin music en produkt. För varje produktbeställning skapas det en order-nod kopplad till användaren som utfört beställningen. Denna order-nod har sedan kopplingar till samtliga produkter som ingår i ordern. I Figur 3 har databasens användaren en order som innehåller en produkt ifrån kategorin music. 14

3.6 Testfallen Figur 3: Översiktsmodell över Neo4j modellen Varje testfall kommer att repeteras fem gånger för att kunna beräkna medelvärdet av exekveringstiderna. Samtliga testfall testas för alla fyra implementationer av databaserna. 3.6.1 Testfall för Insättning I detta testfall sparas exekveringstiderna för insättning av produkter. Databasen är tom vid varje testfall då antalet objekt redan sparade i databasen innan testen kan påverka exekveringstiderna. Detta kommer inte att bevisas i detta experiment. För MySQL databaserna kommer rader med produkter att skapas i tabellen Produkter. Varje produkt har en kategori som refererar till en av kategorierna i tabellen kategori. För Neo4j databaserna kommer produkt-noder och relationer med tillhörande kategori-nod att skapas och kopplas samman. MySQL stödjer även en så kallad multi-insättning. Det innebär att en datamängd kan skickas till databasen i ett enda anrop. Detta kommer även att testas för en av MySQL klienterna, dock inte för Neo4j. En liknande insättning nns för Neo4j med namnet Batch-insert, dock fungerar bara en batch-insert som den initiala importen av data. Det innebär att man inte kan skicka in en större datamängd genom ett enda anrop efter första importen. För att en batch-insert ska vara möjlig måste även delar av databasens kod skrivas om. Detta är anledningarna till varför batch-insert inte kommer att testas. Tabell 6: Testfall för Insättning 15

Testfall Data Antal T1 Produkt 100 T2 Produkt 1000 T3 Produkt 10 000 T4 Produkt 100 000 3.6.2 Testfall för Sökning och ltrering av data Sökning och ltrering av data kommer att testas genom att hämta alla beställda produkter som tillhör en viss användare. I varje testfall ökas antalet användare, produkter och ordrar. Användarens position och antal innehavande produkter i databasen kan påverka exekveringstiderna, därför har samma position använts för en användare med sammanlagt fem produkter. Vid nystart av databaserna förekommer det extra höga exekveringsvärden. Detta beror på att databaserna kräver en så kallad uppvärmd cache för att prestera optimalt. För att bevisa detta utförs det även testfall för sökning och ltrering av data då databaserna inte har en uppvärmd cache. MySQL-databaserna kommer att sköta förfrågningarna med Prepared Statements, detta för att få ökad prestanda vid förfrågningar. Frågan som skickades till databaserna är följande: Hitta samtliga produkter som användaren har beställt 3.7 Metodkritik Tabell 7: Testfall för Sökning och ltrering av data Testfall Uppvärmd cache Användare Produkter Ordrar T5 ja 100 200 350 T6 ja 500 1000 1750 T7 ja 1000 2000 3500 T8 ja 10 000 10 000 15 000 T9 nej 100 200 350 T10 nej 500 1000 1750 T11 nej 1000 2000 3500 T12 nej 10 000 10 000 15 000 Fördelarna med att utföra en litteraturstudie är att få fram tidigare analyser och resultat. Det är också en fördel att kunna testa de variabler man anser är av vikt genom att utföra ett eget experiment. Resultatet av experimentet kan inte generaliseras då många av experimentets viktiga faktorer kan se ut på olika sätt. Vissa av dessa faktorer är: applikationens struktur, databasernas struktur, algoritmerna skrivna för klienterna och testfallens frågor. Det nns inte en generell mall som alla följer för applikationstypens struktur eller koden som används. MySQL databasen testas med klienter skrivna i programmeringsspråken Java och C#. Java är vald dels på grund av att Neo4j även implementeras i Java men också på grund av att språket är plattformsoberoende och kan representera en klient på rad olika enheter och system. C# klienten representerar klienter som används i en Windows-omgivning. Att 16

testa databaserna med klienter skrivna i andra språk som till exempel PHP eller Android kan vara relevant för vidare forskning inom detta ämne. Testfallen som valts för denna studie är Insättning och Sökning och ltrering av data. Ett annat testfall som kan vara intressant för vidare forskning kan vara att se hur databaserna presterar för förändringar i databasen. Detta kan testas genom att till exempel ändra namnet på en av kategorierna i databasen. I testfallet Insättning (se 3.6.1) testas funktionen multi-insättning för en av MySQL databaserna. Liknande funktionen Batch-insert har valts att inte användas för grafdatabasens två implementationer. Batch-insert kan endast användas vid den initiala importen av data. Något som kan vara intressant för vidare forskning är att undersöka vilken av operationerna (Multi-insättning och Batch-insert) som presterar bäst. 17

4 Litteraturstudiens resultat I detta avsnitt presenteras litteraturen som studerats och den data som samlats från litteraturen med syfte att besvara studiens frågeställning. Den vetenskapliga litteraturen som har studerats presenteras nedan. 4.1 Litteratur Sökningen av litteratur för litteraturundersökningen resulterade i att åtta vetenskapliga skrifter ansågs vara relevanta för denna litteraturstudie. Av dessa åtta skrifter var endast fyra av de vetenskapliga rapporter, resten vetenskapliga artiklar. Endast två rapporter hittades som jämfört databaserna Neo4j med MySQL genom utförandet av ett experiment. Dessa två var A comparison of a graph database and a relational database: A data provenance perspective [3] Comparative Analysis of Relational And Graph Databases [4] 4.2 Resultaten Litteraturen som samlats för litteraturstudien följer kriterierna för denna studie (se 3.1) och har använts för att besvara första delmålet av studiens frågeställning (se 1.4). 4.3 Vilka jämförelser av relations och NoSQL -databaser nns redan och hur har de utförts? Av artiklarna som presenterades i tabellen har artikel A1 och A3 jämfört en Neo4j-databas mot en MySQL-databas genom utförandet av ett experiment. De resterande artiklarna har utfört en teoretisk jämförelse mellan den klassiska relationsdatabasen och NoSQL databasen. 4.3.1 A comparison of a graph database and a relational database Vicknair m.. [3] har utfört en analys och ett experiment av två olika databaser konstruerade för en applikationstyp som ska spara och hantera information om datahärkomst. Syftet med deras studie är att bestämma vilken av databaserna som presterar snabbast och fungerar bäst för just deras valda applikationstyp. Databaserna som konstrueras är en MySQL- och en Neo4j -databas. Analysen består utav att titta närmare på ett ertal av databasernas faktorer. Dessa faktorer är: nivå av stöd, enkelhet inom utveckling, exibilitet och slutligen säkerheten. Studien ger en detaljerad bild av hur databaserna står inom dessa faktorer. Applikationen som databaserna konstrueras för har som syfte att spara information om datahärkomst. Denna information berättar om en viss datas process och hur den kom till. Datahärkomst har tidigare sparats i grafer, detta då grafens modell enkelt kan vissa data i olika skeden genom kopplingar. Graferna har sedan lagrats i relationsdatabaser. 18

Insättningen av graferna i relationsdatabasen är simpel men att utföra förfrågningar och framför allt traversera den har visat sig vara väldigt tidsineektivt. Artikelns experiment gick ut på att testa databasernas prestanda vid insättning och traversering. Databaserna testades genom att spara exekveringstiderna för insättningar av 1000, 5000, 10 000 och 100 000 noder. Detta test genomfördes för tre olika datatyper. Traverseringen testades genom att förfråga databaserna med fördenierade frågor. Även i detta test sparades exekveringstiden för traverseringen av 1000, 5000, 10 000 och 1000 000 noder. Även detta test genomfördes för tre olika datatyper. Experimentet resulterar i att Neo4j presterar snabbast, dock tittar studiens författare även på de tidigare nämnda faktorerna vid bedömningen av vilken databas som passar deras applikation bäst. Författarna kommer fram till att fastän Neo4j presterar snabbare så är databasen för omogen för att kunna hantera deras applikation. Behovet av en databas som är säker och support-vänlig är större än behovet av snabb prestanda. 4.3.2 SQL databases v. NoSQL databases Stonebraker [1] skriver en artikel som är kritisk till de positiva prestandaargumenten som NoSQL-databaserna fått. Stonebraker menar att den klassiska relationsdatabasen inte presterar sämre (jämfört med NoSQL-databaser) på grund av användandet av SQL utan det istället är implementationen av databasen som felet ligger i. SQL-databaserna kan prestera med nästintill samma hastighet som grafdatabasen ifall den gör sig av med ett fåtal komponenter. Michael utför inget experiment i denna studie men nämner tidigare utförda experiment där detta har testats med lyckat resultat. 4.3.3 Comparative Analysis of Relational And Graph Databases Batra och Tyagi [4] har i sin rapport gjort en jämförelseanalys av relation- och grafdatabaser. Jämförelsen utförs genom analys av teori samt ett experiment. Syftet för deras studie är att ta reda på om grafdatabasen kan ersätta relationsdatabasen för dagens moderna webbapplikationer. Dessa applikationer hanterar stor mängd data och konstruktionen av databasen ändras ständigt på grund av insättning av relationer. Studien tittar närmare på faktorerna: nivå av support, säkerhet och exibiliteten för databaserna. De två förstnämnda faktorerna beskrivs rent teoretiskt medan den tredje förklaras genom ett exempel. Experimentet utförs genom att konstruera en MySQL-databas och en Neo4j-databas för en applikation som efterliknar ett simpelt socialt nätverk. Applikationen hanterar information som användare, vänner, favoritlm och lmens skådespelare. Tanken är att en användare ska kunna ha en vänskapsrelation med andra användare. En användare ska även kunna lägga till sina favoritlmer och lmens skådespelare. Databaserna testas sedan genom att mäta och jämföra exekveringstiderna för operationen sökning med ltrering. Sökningen sker genom att ställa tre fördenierade frågor. Dessa frågor är att hitta vännerna till en användare, hitta favoritlmerna av användarens vänner och slutligen att hitta skådespelarna i användarens vänners favoritlmer. Frågorna ställs för var databas i två olika mängdförhållanden, ett där databaserna innehåller 100 objekt och ett med 500 objekt. 19

Experimentet resulterar i att Neo4j-databasen presterar snabbare i samtliga testfall. Studien kommer fram till att grafdatabasen kan ersätta relationsdatabasen för applikationer som sociala nätverk och länkade webbsidor. Detta beror på att grafdatabasen presterade snabbare i experimentet men även för att den är mer exibel, grafdatabasen behöver inte konstrueras om vid insättning av nya relationer. 4.3.4 SQL vs NoSQL I artikeln SQL vs NoSQL har Bartholomew [2] skrivit om skillnaderna mellan relationsdatabasen och NoSQL-databaserna. Bartholomew beskriver för- och nackdelarna med de olika databasmodellerna. Han går även igenom en del populära åsikter från anhängare till SQL och NoSQL-rörelserna och ger en förklaring till varför man inte ska se de olika databasmodellerna som ersättningar till varandra utan istället se att de löser problemen på olika sätt och med olika förutsättningar. 4.3.5 Using MongoDB to implement textbook management system instead of MySQL Wei-ping m.. [5] har skrivit en rapport som jämför en MongoDB-databas mot en MySQLdatabas. Syftet med studien är att jämföra databaserna genom mätning av prestanda för operationernas insättning och sökning. Databaserna konstrueras för en applikationstyp som ska hantera information om lärare, studenter och läroböcker. Applikationens modell struktureras för att passa MongoDB. Studien presenterar databasernas koncept och förklarar även hur implementationen av respektive databas går till. Experimentet genomförs genom mätning av exekveringstiderna för de två testfallen insättning och sökning. Det första testfallet testar insättning av 100,000 textböcker. I det andra testfallet söks det efter 2,000 textböcker i en databas med sammanlagt 100,000 textböcker. Dessa testfall utförs för båda databaserna. Experimentet resulterade i att MongoDB presterade bättre för båda testfallen. Studien visar att MongoDB passar deras applikation bättre än MySQL. Dock nämns det att det krävdes mera tid för att lösa de problem som uppstod vid utvecklingen av MongoDBdatabasen än MySQL-databasen. 4.4 En beskrivning av nyckelegenskaperna för MySQL och Neo4j Detta avsnitt granskar databasernas viktiga egenskaper och funktioner. 4.4.1 Mognad och nivå av stöd Databasens mognad refererar till dels hur gammal den är men även till hur använd och testad databasen är. Nivån av stöd som erbjuds för en databas ligger oftast i förhållande till databasens mognad. En mogen databas lockar er företag och användare. En viktig fördel för relationsdatabasen är just att den anses vara väldigt mogen. Relationsdatabasen har dominerat längst och har stöd från stora IT-giganter som till exempel Oracle och Microsoft. Dessa två jättar inom IT-branschen har en ekonomisk anledning till att garantera att språket SQL håller sig uppdaterat och fräscht. Det skiljer sig inte mycket mellan 20

de olika SQL-implementationerna, detta innebär att stöd för den ena relationsdatabasen oftast fungerar för den andra. Grafdatabaser har ökat i popularitet men har ännu inte uppnått samma ekonomiska status på marknaden som relationsdatabasen. Saknaden av ett gemensamt skriptspråk för grafdatabaserna gör att stöd för den ena inte kan användas för den andra. Neo4j erbjuder stöd för sin databas genom en wiki på deras hemsida, dock är stödet utanför Neo4js egna sidor begränsat. Om Neo4j skulle kollapsa nns det en risk att majoriteten av stöd för databasen hade försvunnit [3]. 4.4.2 Skalning Batra och Tyagi [4] bevisar att grafdatabasens prestanda inom sökning inte påverkas av mängden data i databasen. Detta bevisades genom utförandet av ett experiment som resulterade i att grafdatabasen utförde hämtning av data snabbare än relationsdatabasen. Detta beror på att relationsdatabasen letar igenom all data för att matcha sökkriterierna medan grafdatabasen endast letar i data som är direkt kopplade till noden som anges som start för sökningen. Databasens skalning har inte bara att göra med mängden data i databasen utan den har även att göra med hur databasen är fördelad. MySQL sköter fördelning av databasen genom replikaktion av data till era maskiner. Ett vanligt sätt att utföra detta på är att låta all skrivning till databasen ske hos en master-server som sedan skickar den nya informationen till slav-databaserna som sköter all läsning. En annan vanligt förekommande fördelning av en MySQL-databas är att använda sharding. Sharding är en uppdelning av relationsdatabasens tabeller där olika delar av tabellerna hamnar på olika maskiner. Detta är dock en en komplicerad process och påverkar databasens prestanda negativt då databas-förfrågningar över era maskiner är kostsamma. Neo4j använder sig också utav sharding för fördelning av databasen [8]. 4.4.3 Flexibilitet Databasens exibilitet beskriver databasens förmåga att prestera utanför sin normal miljö. Både MySQL och Neo4j är plattformsoberoende databashanterare som kan installeras och köras på många olika system. Även applikationer och program som kommunicerar med databasen kan skrivas på ett ertal olika språk, som till exempel genom Java,.Net, Javascript, Android eller Php. Ruin m.. [7] menar att enkelheten av installationen och implementationen av MySQL är en av anledningarna till att databasen används av både små och stora företag. MySQL använder sig utav språket SQL, detta innebär att databasen enkelt kan kommunicera med olika applikationer oberoende av programmeringsspråket eller plattformen som applikationen nns på. [3]. Vid installation av MySQL tillkommer en mängd olika verktyg och funktioner, då detta är bra för stora företag så kan det samtidigt bli onödigt tungt för hemanvändaren. Databashanterarens exibilitet har även att göra med förmågan att kunna förändra databasens struktur under körning. Många av dagens applikationer uppdateras ofta och kan behöva ändra sin struktur för till exempel nya datatyper. Applikationens databaser måste då struktureras om. Det blir oftast en mycket dyr process för relationsdatabasen som måste ändra på sina tabellscheman [3]. Neo4j kan lägga till nya relationer under körning och även ändra strukturen utan större problem [4]. 21

4.4.4 Säkerhet MySQL erbjuder användaren ett omfattande inbyggd support för administration av era användare. Användare kan hanteras, skapas och tilldelas privilegium genom medföljande graska verktyg. Neo4j erbjuder inte någon support för era användare, grafdatabasen antar att den benner sig i en skyddad miljö. Alla säkerhetsåtgärder måste hanteras på applikationsnivå [3]. 4.5 Vilka applikationstyper passar bäst för databaserna? Leavitt [9] menar att relationsdatabasen fungerar bäst för strukturerad data, som till exempel försäljningssiror eller ett kundregister, data som passar tabellstrukturen. Relationsdatabasen följer ACID-mallen (se 2.4)och används därför ofta för applikationer som kräver hög precision och säkerhet. Oavsett informationen en applikation ska hantera så måste applikationens data konverteras till relationsdatabasens tabeller. Ifall applikationens information inte enkelt kan modelleras i tabeller så kan det leda till komplicerade tabeller med många relationer. Detta resulterar i en databas som är slö att traversera. Batra och Tyagi [4] menar att internetsidor är ett exempel på detta. Internetsidor har en komplicerad struktur med massvis av sammankopplade hyperlänkar, en struktur som inte passar relationsdatabasen. Relationsdatabasen passar inte heller applikationer vars data inte är konsekvent, det vill säga, att informationen som sparas inte ser likadan ut [3]. Enligt Vicknair m.. [3] fungerar grafdatabasen bäst för applikationer vars information har en trädliknande struktur. En applikation där sammankopplingarna mellan data har stor vikt. Exempel på dessa applikationer är sociala nätverk, internetsidor eller andra applikationer som kräver många datarelationer. Grafdatabasen kan även lägga till och ta bort relationer utan större omstrukturering, detta gör databasen lämplig för applikationer som ofta uppdateras och förändras. 22

5 Experimentets resultat I detta avsnitt presenteras experimentets resultat. 5.1 Resultat Samtliga testfall genomfördes för de fyra databaserna. Nedan förklaras databasernas förkortningar. MySQL-JC : MySQL Java klienten MySQL-CS : MySQL-C# klienten MySQL-Multi: MySQL-C# klienten med Multi-insättning Neo4j-JE : Neo4j Java Embedded Neo4j-CS : Neo4j C# klient, REST API 5.1.1 Resultat för Insättning Tiderna presenterade i tabell 8 är medelvärdet av exekveringstiden i sekunder för varje insättning. Kolumnen Antal visar antalet insättningar som skett för vart testfall. Tabellen visar att den Java-inbäddade versionen av Neo4j skötte insättningen snabbast när antalet var 10 000 eller mer. MySQL databasen som hanterades av en C# klient och använde sig utav multi-insättning var den databas som hade exekveringstider närmast den Java-inbäddade versionen av Neo4j. Vid högre antal presterade dock MySQL med multiinsättning långsamt. Tabellen visar även att Neo4j databasen som hanterades av en C# klient var den databas som skötte insättningen långsammast. Tabell 8: Resultat för testfallet insättning Testfall Data Antal MySQL-JC MySQL-CS MySQL-Multi Neo4j-JE Neo4j-CS T1 Produkt 100 0,4 0,3 0,005 0,03 3,1 T2 Produkt 1000 3,4 3,1 0,9 0,3 29,3 T3 Produkt 10 000 31,4 28,9 8,4 1,3 261,1 T4 Produkt 100 000 293,4 286,1 1006,6 5,0 2769,8 5.1.2 Resultat för sökning och ltrering Tabell 9 visar hur databaserna presterade inför sökning efter en användares beställda produkter. Tiderna presenterade i tabellen nedan är medelvärdet för exekveringstiderna i millisekunder. Tabellen visar att Neo4j-CS är den databas som presterade snabbast. För att bevisa att databaserna presterar sämre när datorns cache minne inte är uppvärmd har test utförts som visas i tabell 10. 23

Tabell 9: Resultat för testfallen sökning och ltrering med uppvärmd cache Testfall Användare Produkter Ordrar MySQL-JC MySQL-CS Neo4j-JE Neo4j-CS T9 100 200 350 0,4 0,2 0,2 0,2 T10 500 1000 1750 0,6 0,4 0,2 0,2 T11 1000 2000 3500 0,8 0,2 0,2 0,2 T12 10 000 10 000 15 000 1,0 0,4 0,4 0,2 Tabell 10 visar att samtliga databaser presterade med väldigt höga exekveringstider när databaserna var nystartade och ohanterade. Neo4j databaserna påverkades mer än MySQL databasen. Tabell 10: Resultat för testfallen sökning och ltrering med ouppvärmd cache. Testfall Användare Produkter Ordrar MySQL-JC MySQL-CS Neo4j-JE Neo4j-CS T13 100 200 350 2,6 1,0 25,2 7,2 T14 500 1000 1750 2,8 1,0 5 7 T15 1000 2000 3500 2,2 0,6 26,2 7 T16 10 000 10 000 15 000 2,4 1 25,8 7 24

6 Analys och diskussion I detta avsnitt presenteras analysen av litteraturstudien och experimentet. Experimentets resultat har visat att den Java-inbäddade Neo4j implementeringen kan sköta insättningen snabbare än de andra databaserna. Vid sökning och ltrering av E-handelssidan kan MySQL och Neo4j prestera nästan lika snabbt. Resultaten av litteraturstudien (se 4.4)visar att Neo4j fungerar som bäst för applikationer vars information har många och betydelsefulla relationer. Neo4j kan traversera dessa nätverk betydligt snabbare än MySQL då grafdatabasen endast tittar på sammankopplade noder. Rapportens experiment visar dock att om databasen består av få relationer, så kan databaserna prestera nästan lika snabbt. Neo4j är exibel och kan enkelt struktureras om utan större komplikationer, relationer kan enkelt läggas till och tas bort. MySQL är en mognare databas som kommer med ett enormt stöd och färdiga lösningar. 6.1 Analys av litteraturstudien I sökningen hittades åtta relevanta akademiska skrifter. Av dessa åtta var fyra av dem rapporter, resten akademiska artiklar. Endast två av de fyra artiklarna genomförde ett experiment mellan databaserna Neo4j och MySQL. Detta kan ses som positivt då det ökar relevansen för denna studie. Databaserna som söktes igenom innehöll mängder av rapporter om MySQL, dock var majoriteten äldre eller så var rapporterna fokuserade på endast vissa tekniker för databasen. I rapporten [3] har Vicknair m.. bland annat fokuserat på databasernas nivå av stöd, exibilitet, säkerhet och prestanda vid sökning. Samma egenskaper hamnar i fokus i Batra och Tyagis rapport [4]. En skillnad mellan rapporterna är att Vicknair m.. även tar upp för- och nackdelarna med att programmera till de olika databaserna. Resultatet av rapporterna varierar. Batra och Tyagi kom fram till att grafdatabasens exibilitet var av stor vikt och att Neo4j passar för applikationer som sociala-nätverk och applikationer som har en länkad struktur. Vicknair m.. ansåg däremot att Neo4j var för omogen för att hantera deras valda applikation. De konstaterade att Neo4j erbjuder en mycket bättre sökmetod än MySQL fast behovet av att säkra användardata var större. Bristen av stöd för Neo4j var även en viktig faktor. Wei-ping m.. [5] har skrivit en rapport som jämför MySQL med databasen MongoDB. Denna jämförelse sker genom en teoretisk studie samt ett praktiskt experiment. Något som är intressant med rapporten är att likt denna rapport har även de valt att fokusera på en traditionell informationsapplikation. Det vill säga att även Wei-ping m.. är intresserade av att se hur Neo4j presterar utanför sin normala omgivning. Något som skiljer sig mellan Weiping m.. rapport och de ovanstående rapporterna är det stora fokuset på applikationens struktur och implementering. Detta är intressant då även denna rapport lägger stort fokus på just vilken applikation databaserna är konstruerade för. Dock har Wei-ping m.. valt att strukturera applikationens databaser på ett sätt som fungerar bättre för MongoDB. Detta påverkar resultatet av studien då MongoDB får era fördelar över MySQL. Rapportens författare nämner att utvecklingen av NoSQL databasen varit svårare och tagit längre tid än MySQL databasen. 25

Ruin m.. [7] har skrivit en rapport som fokuserar på fem databaser för lagring av social data för applikationer som sociala-nätverk. Rapporten fokuserar främst på databasernas möjlighet att expandera och på hur databaserna hanterar förfrågningar som t.ex hämtning av data. Skalbarheten är en egenskap som artiklarna ovan inte har fokuserat på, dock kan det vara avgörande för valet av databas beroende på applikationens krav. Ruin m.. [7] kommer fram till att det inte nns en given vinnare för vilken databas som passar dessa nätverken bäst. Neo4j kan lagra de sociala kopplingarna i grafer väldigt eektivt, dock är grafdatabasen optimerad för graftraversering, något som sällan används för de sociala nätverken. MySQL ansågs ha problem med att hämta data då stora JOIN-tabeller behövdes, exibiliteten med att ha fasta scheman var även ett hinder. Resultatet av artiklarna nämnda ovan varierar stort. Något som kan konstateras är att applikationen som databaserna konstrueras för spelar stor roll vid valet av databas. Kraven för olika applikationer varierar då vissa applikationer fokuserar på snabb sökning mellan mängder av kopplingar, kan andra fokusera på säkerheten eller exibiliteten av databasen. Det är dessa krav som ligger bakom valet av databas. 6.2 Analys av experimentet Resultatet av experimentets testfall vid insättning (se 5.1.1) visar att den Java-inbäddade Neo4j databasen presterade snabbast. Resultatet visar även att den Neo4j databas som kommunicerar med en C# klient är den databas som presterade sämst. Den Java-inbäddade Neo4j databasen slipper att skicka frågor till en server, istället sker all databas hantering internt. I testen med 100 000 produktinsättningar och er var skillnaden enorm. Figur 4 visar att MySQL databaserna och Neo4j-CS skötte insättningen för 100 000 produkter på över 280 sekunder samtidigt som en likadan insättning endast tog 5 sekunder för den Javainbäddade Neo4j-databasen. MySQL testades även för multi-insättning. Databasen som använde sig av multi-insättning presterade väldigt snabbt vid längre antal, vid högre antal ökade exekveringstiden drastiskt. Snabb prestanda vid insättning är en fördel och kan spela stor roll för många applikationer, dock är det ingen vital faktor för just en E-handelssida. Figur 4: Insättning av produkter 26

Resultatet av experimentets testfall vid sökning och ltrering (se 5.1.2) visar att prestandan inte skiljer sig mycket mellan databaserna. Detta är märkvärdigt då Neo4j presterar bättre än MySQL vid samtliga experiment utförda bland rapportens tidigare forskning som studerats. Detta kan bero på att de experimenten testat databaserna för en applikationstyp som stödjer grafdatabasen. Figur 5 visar tydligt att Neo4j grafdatabasen som hanterats av C# klienten håller nästan samma hastighet oavsett databasens storlek. För rapportens valda applikation presterar databaserna nästan lika väl, detta kan bero på att applikationen teoretiskt gynnar relationsmodellen. Den innehåller få relationer vilket gör att Neo4js eektiva traverseringsmetoder inte verkar märkvärdiga jämfört med relationsdatabasens tabellsökning. Resultaten av testfallen med en ickeuppvärmd cache visar även att databaserna presterar med väldigt höga exekveringsvärden. Detta kan spela roll för applikationer som inte alltid har en uppkopplad server, dock är det inte relevant för en E-handelssida. Figur 5: stapeldiagram över testfallen för sökning och ltrering 6.3 Svar på frågeställningen Denna sektion presenterar svaren på studiens frågeställning (se 1.4). 6.4 Delmål 1: Undersökning av relation- och grafdatabasen 6.4.1 Vilka jämförelser av relations- och NoSQL-databaser nns redan och hur har de utförts? Svaret på frågan presenteras i sektion 4.3. Sammanlagt hittades åtta akademiska skrifter. Dessa skrifter resulterade i en ökad kunskap för databaserna och dess nyckelegenskaper. 6.4.2 En beskrivning av nyckelegenskaperna för MySQL och Neo4j Nyckelegenskaperna för databaserna presenteras i sektion 4.4. Egenskaper som anses vara viktiga för databaserna är: mognad och nivå av stöd, skalning, exibilitet och säkerheten. Dessa är egenskaper som ofta nämns vid jämförelser av databaser. 27

6.4.3 Vilka applikationstyper passar bäst för databaserna? Litteraturstudien visade att applikationer som kundregister, försäljningssiror eller annan typ av strukturerad data som enkelt kan modelleras i tabeller passar bäst för relationsdatabasen. Grafdatabasen bör hantera data med trädliknande struktur och data som har många betydelsefulla relationer. Exempel på applikationer av denna sort är sociala nätverk eller länkade sidor på webben. Experimentet visar att Neo4j även kan hantera traditionella informationsapplikationer. 6.5 Delmål 2: En applikationstyp som vanligtvis implementeras med en relationsdatabas 6.5.1 Vilken av databaserna presterar snabbast inom operationerna: insättning och sökning? Denna fråga besvarades genom utförandet av experimentet (se 3.2). Vid insättning presterade den Java-inbäddade Neo4j databasen bäst. Vid sökning och ltrering presterade databaserna nästan lika snabbt. 6.5.2 Kan grafdatabasen ersätta relationsdatabasen för en traditionell informationsapplikation? Beslutet i frågan om grafdatabasen eller om relationsdatabasen passar en traditionell informationsapplikation bäst har att göra med applikationens krav. Grafdatabasen kan ersätta relationsdatabasen, dock kan precision och säkerhet oras för möjligheten att prestera väldigt snabbt med enorma datamängder. Är det en applikation där databasen behöver traverseras frekvent och där hastigheten är i fokus så kan grafdatabasen vara ett bra alternativ. Handlar det dock om en applikation som hanterar känslig information där informationen som hanteras måste sparas i databasen direkt så är det relationsdatabasen som är det självklara valet. Stödet för databaserna kan även vara en viktig faktor för valet av databas, att satsa på Neo4j kan innebära en risk för större företag då stödet för databasen inte är stor i nuläget. 28

7 Slutsats Studiens analys och resultat pekar på att en traditionell informationsapplikation kan modelleras för en grafdatabas. Rapportens experiment visar att Neo4j presterar väldigt snabbt även i strukturer med få relationer. Skillnaden var inte alltid stor mellan MySQL och Neo4j men i testfallen där stor datamängd handskades presterade Neo4j snabbare än MySQL. Dock måste man se på andra faktorer vid byte av databas. Säkerheten och nivån av stöd är viktiga sådana faktorer. Neo4j brister i båda då grafdatabasen inte kan erbjuda samma stöd som nns för MySQL. MySQL är väldokumenterat och har enormt stöd från era håll medan Neo4j är relativt ny på marknaden och det mesta stödet för databasen hittas på företagets egen sida. MySQL har dominerat längst på marknaden och i och med grafdatabasens popularitet undrar många databasanvändare ifall de ska ha kvar den traditionella relationsdatabasen eller byta den mot den nyare och modernare relationsdatabasen. Svaret på frågan beror på vilka krav användaren har på databasen. Är prestanda och behovet av att söka i enorma nätverk de viktigaste faktorerna för databasen så kan bytet till en grafdatabas fungera väldigt bra. Är det inte det så är relationsdatabasen fortfarande ett givet val. 29

Referenser [1] M. Stonebraker, SQL databases v. NoSQL databases. In Communications of the ACM CACM Homepage archive Volume 53 Issue 4, year 2010 [2] D. Bartholomew, SQL vs. NoSQL. In Linux Journal Issue 195, year 2010. [3] M. Macias,Z. Zhao,Z. Nan,Y. Chen, D. Wilkins, A comparison of a graph database and a relational database: a data provenance perspective. In ACM SE '10 Proceedings of the 48th Annual Southeast Regional Conference Article No. 42, year 2010 [4] S. Batra, C. Tyagi, Comparative Analysis of Relational And Graph Databases. In International Journal of Soft Computing and Engineering Volume-2, Issue-2, year 2012. [5] Z. Wei-ping, C. Huan, L Ming-xin, Using MongoDB to implement textbook management system instead of MySQL. In Communication Software and Networks (ICCSN) year 2011 [6] A. Schram, K. M. Anderson, MySQL to NoSQL data modeling challenges in supporting scalability. In Proceedings of the 3rd annual conference on Systems, programming, and applications year 2012 [7] N. Ruin, Social-data storage-systems. In DBSocial '11 Databases and Social Networks year 2011. [8] M. Rys, Scalable SQL. In Communications of the ACM year 2011. [9] N. Leavitt, Will NoSQL Databases Live Up to Their Promise? In IEEE, Computer year 2010. [10] R. Elmasri, S. B,V. Navathe, Fundamentals of Database Systems. Pearson 4th edition, year 2004. [11] T. Padron-McCarthy, T. Risch, Databas-Teknik. Studentlitteratur AB, Lund 1:6, year 2010 [12] I. Robinson, J. Webber, E. Eifrem, Graph Databases. O'Reilly Media, Inc Early release revision, year 2013 [13] A. Kriegel, Discovering SQL. Wrox, USA year 2011 [14] Wikipedia The Free Encyclopedia: Database management system. URL: http : //en.wikipedia.org/wiki/database m anagement s ystem Retrieved year 2013. [15] Oracle MySQL Workbench URL: http : //www.mysql.com/products/workbench/ Retrieved year 2013. 30

[16] Oracle MySQL URL: http : //www.mysql.com/about/ Retrieved year 2013. [17] Neo4j URL: http : //www.neo4j.org/ Retrieved year 2013. [18] Graph Databases and the Value They Provide URL: http : //www.dbta.com/articles/columns/notes on NoSQL/Graph Databases and the V alue T hey P rovide 74544.aspx Retrieved year 2013. [19] Modeling categories in a graph database URL: http : //blog.neo4j.org/2010/03/modeling categories in graph database.html Retrieved year 2013. [20] Neo4jClient Readify URL: http : //hg.readif y.net/neo4jclient/wiki/home Retrieved year 2013. [21] Neo Technology URL: http : //www.neotechnology.com/about/ Retrieved year 2013. [22] ComputerSweden: Ny Databas räddning för webben URL: http : //computersweden.idg.se/2.2683/1.285190/ny databas raddningen f or webben Retrieved year 2013. 31

8 Bilagor Bilaga 1: Java kod för att koppla upp, alternativt skapa Neo4j-databasen Bilaga 2: C# kod för att söka efter en användares alla beställda produkter i en Neo4j grafdatabas 32

Bilaga 3: C# kod för att skapa en eller era person-noder i en Neo4j grafdatabas Bilaga 4: Java kod för att skapa en eller era person-noder i en Neo4j grafdatabas 33

Bilaga 5: Java kod för insättning av en person i en MySQL databas Bilaga 6: En visualisering av Neo4j grafdatabasen efter en insättning med 100 produkter 34

Bilaga 7: En visualisering av Neo4j grafdatabasen med endast 10 användare och 25 produkter 35