Jämförelse mellan graf- och relationsdatabas

(1)

Jämförelse mellan graf- och relationsdatabas

En studie av prestanda vid sökning av kortaste vägen mellan två givna platser i ett rälsbundet nätverk

Comparison between graph and relational database:

A study of performance when searching for the shortest path between two given places in a rail network

Jimmy Nilsson Johan Hansson

Handledare: Jerker Westin

Daniel Öster (Trafikverket) Karl Åkerlund (Trafikverket) Examinator: Rikard Land

Examensarbete för filosofie kandidatexamen i Informatik 1 juni 2021

Högskolan Dalarna – www.du.se Publicerad i fulltext, fritt tillgängligt

(2)

Abstract

Traditional relational databases store data in tabular form and have existed for several decades. The new requirements for data such as high availability and scalability have led to an increase in NoSQL databases in popularity. NoSQL databases meet these requirements as they use other methods for handling and storing data, for example document databases and graph databases are two of these variants.

This study examined the difference in performance between the SQL Server 19 relational database and the Neo4j graph database. An experiment with the hypothesis: "Graph databases have faster response times compared to relational databases when retrieving the shortest route between two specified lo- cations" was performed by executing a function on a dataset provided by the study's partner the Swe- dish Transport Administration. The data set represents Sweden's railway network and consists of 1320 places and 2788 associated connections. The function searched for the shortest route between two locations for four selected sections in each database architecture.

The observed and analyzed response times show that Neo4j has an average response time that is 50 times faster than SQL Server 19, which verifies the hypothesis. The response times from the two databases were also tested with a Wilcoxon test which showed that the median response times differ from each other at a 1 % significance level. In addition, the results show that the average response time for SQL Server 19 will increase more than Neo4j as more sites and connections become involved in the search.

Relational databases have slower response times than graph databases as they use join statements to find current relationships between its tables, which means that they must search all the data to find the shortest path between two places. Unlike relational databases, graph databases only use relationships directly connected to the current node where the algorithm is located, which means that response times are shorter.

Keywords: Relational Database, Graph Database, SQL Server, Neo4j, Comparison, Performance, Re- sponse Times

(3)

Sammanfattning

Traditionella relationsdatabaser lagrar data i tabellform och har existerat i flera årtionden. De nya kraven på data som hög tillgänglighet samt skalbarhet har gjort att NoSQL databaser ökat i popularitet.

NoSQL databaser tillgodoser dessa krav då de använder andra sätt för hantering och lagring av data, exempelvis är dokument-databaser samt grafdatabaser två av dessa varianter.

I denna studie undersöktes skillnaden i prestanda mellan relationsdatabasen SQL Server 19 och graf- databasen Neo4j. Ett experiment med hypotesen: “Grafdatabaser har snabbare svarstider i jämförelse mot relationsdatabaser vid hämtning av kortaste vägen mellan två angivna platser” genomfördes ge- nom att exekvera en funktion på ett dataset som tillhandahållits av studiens samarbetspartner Trafik- verket. Datasetet representerar Sveriges järnvägsnätverk och består av 1320 platser och 2788 tillhö- rande förbindelser. Funktionen sökte efter den kortaste vägen mellan två platser för fyra utvalda sträckor i varje databasarkitektur.

De observerade och analyserade svarstiderna visar att Neo4j har en genomsnittlig svarstid som är 50 gånger snabbare än SQL Server 19 vilket verifierar hypotesen. Svarstiderna från de två databaserna testades även med ett Wilcoxon-test som visade att svarstidernas median skiljer sig från varandra på en 1 % signifikansnivå. Därtill visar resultatet att den genomsnittliga svarstiden för SQL Server 19 kommer att öka mer än Neo4j då fler platser och förbindelser blir involverade i sökningen.

Relationsdatabaser har långsammare svarstider än grafdatabaser då de använder join-satser för att hitta aktuella relationer mellan dess tabeller vilket gör att de måste söka igenom all data för att hitta kortaste vägen mellan två platser. Till skillnad från relationsdatabaser använder grafdatabaser endast relationer direkt anslutna till den nuvarande noden där algoritmen befinner sig vilket gör att svarstiderna blir mindre.

Nyckelord: Relationsdatabas, Grafdatabas, SQL Server, Neo4j, Jämförelse, Prestanda, Svarstider

(4)

Förord

Vi vill tacka vår samarbetspartner Trafikverket. Ett stort tack till Joakim Wibrand som möjliggjorde detta arbete samt ett tack till Daniel Öster och Karl Åkerlund. Slutligen ett extra stort tack till vår handledare på Högskolan Dalarna, Jerker Westin som väglett oss genom detta arbete.

(5)

Begreppslista

SQL SQL är ett standardiserat frågespråk som används för att ställa frågor till relationsdatabaser (IDG, 2021).

DBMS Database Management System används för att data ska kunna hanteras, läsas och manipuleras (Oracle, 2021).

Nod - Allmän definition Knutpunkt i ett nätverk (IDG, 2021).

Nod I denna studie definierar vi Nod som en given plats i ett rälsbundet nätverk.

Kant - Allmän definition Linje som går mellan två noder i ett nätverk (IDG, 2021).

Kant I denna studie definierar vi kant som en förbindelse mellan två platser i ett rälsbundet nätverk.

Benchmarking Är en jämförelse och utvärdering av teknisk utrustning (IDG, 2021).

CSV Comma-Separated-Values är ett filformat för kommaavgränsade data (IDG, 2021).

Skript Ett program som utför uppgifter som exempel automatisera arbets- uppgifter (IDG, 2021).

CRUD Create, Read, Update, Delete – Grundläggande funktioner i en databashanterare (IDG, 2021)

(6)

Innehållsförteckning

1 INLEDNING ... 1

1.1 BAKGRUND ... 1

1.2 PROBLEMFORMULERING OCH FRÅGESTÄLLNING... 2

1.3 SYFTE ... 2

1.4 AVGRÄNSNING ... 2

2 TEORI - REFERENSRAM ... 3

2.1 DATABASER... 3

2.2 RELATIONSDATABASER ... 3

Primärnyckel... 3

Främmande nyckel ... 3

Index ... 4

SQL ... 4

Microsoft SQL Server... 4

2.3 GRAFDATABASER ... 5

Neo4j ... 5

Index free adjacency ... 6

Cypher ... 6

Native vs Non-native ... 6

2.4 DIJKSTRA’S ALGORITM ... 6

2.5 SVARSTID ... 6

2.6 PYTHON ... 6

2.7 TIDIGARE FORSKNING ... 6

3 FORSKNINGSMETOD ... 8

3.1 FORSKNINGSPROCESS ... 8

3.2 LITTERATURGENOMGÅNG ... 8

Litteratursökning ... 8

3.3 FORSKNINGSSTRATEGI ... 9

(7)

3.4 DATAINSAMLING ... 9

3.5 DATAANALYS ... 10

3.6 ETIK OCH DATASET... 10

Datasetets objekt ... 10

Objektens attribut ... 10

4 EXPERIMENTELLT GENOMFÖRANDE ... 11

4.1 FÖRBEREDELSER ... 11

Python - Extrahera platser och grannar ... 11

SQL Server 19 - Läs in CSV-filer till platserTEMP och grannarTEMP ... 11

SQL Server 19 - Läs in från temporära tabeller till slut-tabeller ... 11

Neo4j - Läs in platser och förbindelser ... 11

SQL Server 19 - Shortest path ... 12

Neo4j - Dijkstra’s algoritm ... 12

4.2 GENOMFÖRANDE ... 12

Konfiguration av hårdvara och mjukvara ... 13

Version av databaser ... 13

Genomförandet ... 13

5 RESULTAT ... 14

5.1 PLATSER OCH FÖRBINDELSER ... 14

5.2 SVARSTIDER ... 14

5.3 JÄMFÖRELSE MELLAN SQLSERVER OCH NEO4J ... 14

5.4 SVARSTIDERNAS FUNKTION VID ANTAL PLATSER OCH FÖRBINDELSER ... 15

6 DISKUSSION ... 16

6.1 RESULTATDISKUSSION ... 16

6.2 METODDISKUSSION ... 18

7 SLUTSATS & FÖRSLAG TILL VIDARE FORSKNING ... 20

7.1 SLUTSATS ... 20

7.2 FÖRSLAG TILL VIDARE FORSKNING ... 20

(8)

8 KÄLLFÖRTECKNING ... 21

Tabellförteckning

TABELL 4-1:SAMMANSTÄLLNING AV PLATSER SOM ANVÄNDS I EXPERIMENTET ... 13

TABELL 5-1:STRÄCKOR MED ANTAL PLATSER OCH FÖRBINDELSER. ... 14

TABELL 5-2:SVARSTIDER OCH STANDARDAVVIKELSE FÖR SQLSERVER 19 SAMT NEO4J. ... 14

TABELL 5-3:JÄMFÖRELSE MELLAN SQLSERVER 19 OCH NEO4J. ... 14

Figurförteckning

FIGUR 2-1:TABELL OCH RELATIONER MED TILLHÖRANDE NYCKLAR... 4

FIGUR 2-2:NODER MED TILLHÖRANDE KANTER ... 5

FIGUR 3-1:FORSKNINGSPROCESS ... 8

FIGUR 4-1:KÄLLKOD FÖR SQLSERVER 19SHORTEST PATH ... 12

FIGUR 4-2:KÄLLKOD FÖR NEO4J SHORTEST PATH ... 12

FIGUR 6-1:JÄMFÖRELSE AV SVARSTIDER MELLAN NEO4J OCH SQLSERVER 19 ... 17

(9)

Högskolan Dalarna 1

1 ^Inledning

I detta kapitel beskrivs bakgrunden till studien samt dess problemformulering och frågeställningar. Här beskrivs syftet med arbetet och avgränsningar som gjorts. Även en kort beskrivning om samarbetspart- nern presenteras.

1.1 ^Bakgrund

Den årliga summan av skapat, återskapat och fångat data kallas för “Global Datasphere” och förutspås av International Data Corporation att motsvara 175 Zettabyte år 2025 (Reinsel et al., 2018). Den ökade mängden genererat data ställer förändrade krav på hantering och lagring vilket resulterat i att såväl gamla som nya tekniker utvecklats för att tillgodose dessa behov.

Traditionella relationsdatabaser har existerat och använts i flera årtionden för lagring och hämtning av data med hjälp av frågespråket Structured Query Language (SQL). Relationsdatabaser fungerar väl med data som ej består av många relationer då hämtning av sådan data ofta kräver komplicerade och kostsamma join-satser (Vicknair et al., 2010). Data i relationsdatabaser lagras i tabellform, där varje tabell innehåller rader och kolumner. Rader representerar en insättning i tabellen och kolumnerna motsvarar ett attribut (Codd, 2002).

Med de förändrade kraven på hantering och lagring av data har NoSQL (Not Only SQL) databaser enligt DB-Engines (2021) ökat i popularitet de senaste åren. NoSQL databaser tillgodoser ökad tillgänglighet samt skalbarhet och använder därtill andra sätt för lagring och hämtning av data jämfört med mer traditionella relationsdatabaser. NoSQL databaser finns i olika varianter, grafdatabas är en av dessa (Lourenço et al., 2015).

Chen et al. (2020) beskriver en problematik med att databaser nästan uteslutande har designats efter den relationsmodell som Edgar F. Codd introducerade på 70-talet då modellen kräver att data är nor- maliserat. Detta innebär många tabeller som kräver kostsamma join-satser vid efterfrågning av data med komplexa relationer. Författarna skriver vidare att grafdatabaser har enklare att hantera relationer och därför krävs inte några join-satser vid efterfrågning av data i grafdatabaser. De nämner där- emot att många av de ansedda fördelarna med en grafdatabas kontra en relationsdatabas endast är teoretiska utan förankring i praktiken. De jämför i sin studie relationsdatabasen PostgreSQL med grafdatabasen Neo4j och finner att PostgreSQL snabbare läser in både mindre och större dataset där det största datasetet innehöll 36 968 noder med tillhörande kanter. Vid sökning av kortaste vägen mellan två platser användes tre olika algoritmer och där presterade Neo4j snabbare svarstider än PostgreSQL.

Medhi & Baruah (2017) skriver att grafdatabaser ofta används när data har en hög sammankoppling likt till exempel sociala och biologiska nätverk. Författarna skriver vidare att det är lättare att ändra och lägga till relationer i en grafdatabas kontra en relationsdatabas. De jämförde relationsdatabasen MySQL med grafdatabasen Neo4j där de ställer tre frågor till varje databas och mätte hur lång tid det tog för respektive databas att hitta data samt presentera resultatet. Resultatet visade att grafdatabasen presterade snabbare redan vid mindre mängd data men att skillnaden växte med storleken på datasetet.

Trafikverket Borlänge är samarbetspartner i denna studie. Trafikverket är en svensk statlig förvalt- ningsmyndighet vars uppdrag i samhället är att ansvara för infrastrukturen av vägtrafik, järnvägstrafik, sjöfart och luftfart samt för byggande och drift av statliga vägar och järnvägar (Trafikverket, 2020).

Studiens samarbetspartner använder till stor del Microsofts version av relationsdatabas som heter

“SQL Server”. Den första versionen av SQL Server släpptes 1988 och gick under namnet “SQL Server 1.0” (Spenik & Sledge, 2003). Med det ökade behovet av databaser som effektivt kan hantera grafdata med många relationer introducerade Microsoft stöd för detta i version 14 av SQL Server 2017.

(10)

Vi har ej lyckats finna någon studie som klarlägger hur väl Microsofts relationsdatabas SQL Server 2017 och senare versioner presterar i jämförelse med en grafdatabas likt Neo4j vid beräkning av kortaste vägen i data representerat som ett rälsbundet nätverk.

Trafikverket är intresserade av att undersöka skillnad i prestanda mellan relations- och grafdatabaser.

För att undersöka vilken typ av databas som är bäst lämpad för att tillfredsställa Trafikverkets behov kommer svarstider att kartläggas och analyseras. Detta kommer genomföras med mätning av de svars- tider det tar för databaserna att genomföra följande beräkning: Kortaste vägen mellan två platser.

1.2 Problemformulering och frågeställning

Trafikverket använder i stor utsträckning Microsoft SQL Server. Med den ökande populariteten av grafdatabaser och brist på kunskap om vilken skillnad det är i prestanda mellan relationsdatabaser och grafdatabaser har denna studie försökt svara på detta genom att undersöka följande frågeställning:

Hur skiljer sig prestanda mellan graf- och relationsdatabaser vid beräkning av kortaste vägen mellan två angivna platser i ett rälsbundet nätverk?

1.3 ^Syfte

Syftet med denna studie är att planera och utföra ett experiment där resultatet kommer belysa vilken skillnad det är i svarstid mellan grafdatabaser och relationsdatabaser för att beskriva hur prestanda skiljer sig i Sveriges järnvägsnät.

1.4 Avgränsning

Det dataset som använts för att mäta prestandan hos de olika databaserna i denna studie har tillhan- dahållits av studiens samarbetspartner Trafikverket. Datasetet är en representation av det svenska järnvägsnätet och innehåller data om dess platser samt förbindelser

och

ses som statiskt då räls- bundna nätverk ej genomgår snabba och stora förändringar. Studien avgränsar sig till att inte presentera eller diskutera detaljerad information om specifika platser och förbindelser i datasetet på grund av sekretesskäl.

Relationsdatabasen som använts under experimentet är Microsoft SQL Server 2019 då studiens samarbetspartner i stor utsträckning använder Microsofts tekniker, därtill har Microsoft SQL Server 2017 och framåt stöd för hantering av grafdata (Microsoft, 2021).

Grafdatabasen Neo4j (Network Exploration and Optimization 4 Java) ligger på första plats i DB-Engines ranking över de populäraste grafdatabaserna (DB-Engine, 2021). Neo4j version 4.2.1 har därför an- vänts i studiens experiment.

I denna studie kommer prestanda att utvärderas baserat på svarstider från graf- och relationsdataba- serna.

(11)

2 Teori - Referensram

I detta kapitel beskrivs relevanta teoretiska begrepp för studien inom graf- och relationsdatabaser på en övergripande nivå.

2.1 ^Databaser

Databas är ett datorsystem som möjliggör elektronisk lagring av strukturerad organiserad information, denna information kallas även data. För att data ska kunna hanteras, läsas och manipuleras används vanligen ett databashanteringssystem kallat “DBMS, database management system”. DBMS tillsam- mans med data benämns som ett databassystem men förkortas ofta till endast databas.

Databaser har sedan 1960-talet haft olika egenskaper och funktionalitet. Några av varianterna är så kallade hierarkiska databaser, nätverks databaser, objekt databaser samt relationsdatabaser.

Relationsdatabaser blev populära på 80-talet och dominerade marknaden under en lång tid. Men som svar på ökade datamängder har en ny variant av databas utvecklats som fungerar väl för hantering av olika typer ostrukturerad data, denna variant kallas för NoSQL (Oracle, 2021).

Inom NoSQL finns olika typer av databaser som key-value, kolumn lagring, dokument och grafdatabaser (Lourenço et al., 2015).

2.2 Relationsdatabaser

Relationsdatabaser är baserade på en modell av E. F. Codd från 1970-talet. Modellen föreslår att data kan representeras som en samling av tabeller innehållandes rader samt kolumner där raderna ses som en instans av en enhet och kolumnerna beskriver dess attribut (Beaulieu, 2009).

Primärnyckel

För att hantera en specifik rad i tabellen används primärnycklar. Primärnycklar är ett unikt attribut tilldelat varje rad och används för att identifiera en unik rad i en tabell. Skulle en primärnyckel ej vara unik finns möjligheten att den identifierar en samling av rader vilket omöjliggör åtkomsten till specifika rader. Därtill får en primärnyckel ej innehålla värdet null. Null kan i detta sammanhang ses som värdet

“okänd”. Ett null värde som primärnyckel medför att raden blir svår att få tillgång till (Harrington, 2016).

Främmande nyckel

För att skapa en relation mellan tabeller i en relationsdatabas används attributen främmande nycklar.

Dessa nycklar refererar till primärnycklar i andra tabeller de har koppling till och möjliggör hämtning av information från fler tabeller (Beaulieu, 2009).

Figur 2–1 visar hur en relationsdatabas med tre tabeller: Person, Adress och Stad kan kopplas ihop med primärnycklar (id) och främmande nycklar (adress_id, stad_id). Enligt tabellerna går det att ut- vinna följande information: Personen med id 101 (John Doe, ålder: 25) är bosatt på adress_id 201 (Ser- gels Torg, postnummer: 11 157). Adressen är belägen i staden med stad_id 301 (Stockholm).

(12)

Figur 2-1: Tabell och relationer med tillhörande nycklar Index

Index är en nyckel som är uppbyggd av en eller fler kolumner i en tabell och används av en relationsdatabas för att öka hastigheten vid hämtning av rader. Ett index i en databas går att likna vid en vanlig bok som i slutet har en sorterad lista av nyckelord följt av sidnummer för att förtydliga vilken sida i boken nyckelordet går att finna. Detta förenklar lokalisering av information då det går att undvika en full granskning av boken för att hitta alla sidor där nyckelordet existerar och endast gå till de sidor som är specificerade i bokens index för aktuellt nyckelord (Microsoft, 2021).

Vid skapande av index bör det diskuteras om data i en tabell kommer kontinuerligt förändras genom insättning, borttagning, uppdatering och liknande. Skulle tabellens data förändras ofta måste även index-filen uppdateras ofta vilket medför en ökad kostnad. Index på en liten tabell kan innebära att det tar längre tid att söka igenom index-filen än vad det hade tagit att söka igenom hela tabellen.

Det finns olika typer av index med varierande egenskaper och användningsområden. Klustrat index är baserat på en kolumns nyckelvärde och lagrar datarader sorterat. På grund av dess egenskaper kan en tabell ej inneha flertalet klustrade index då raderna bara kan sorteras i en ordning. En tabell med en kolumn som ofta används för hämtning av data och innehåller en hög grad av unika värden bör ha ett klustrat index (Microsoft, 2021).

SQL

Codd föreslog tillsammans med sin relationsmodell även ett språk för att kunna fråga efter data i relationsdatabaser. Detta språk kallades initialt för DSL/Alpha men blev ändrat till SEQUEL som slutligen blev förkortat SQL. Detta språk för att fråga efter och manipulera data i relationsdatabaser har sedan 1986 varit en standard enligt ANSI.

Resultatet av en SQL-fråga kommer tillbaka i formatet av en tabell vilket gör att språket lämpar sig väl med Codd’s relationsmodell då det är enkelt att skapa en ny tabell genom att lagra resultatet (Beaulieu, 2009).

Microsoft SQL Server

Microsoft SQL Server är en relationsdatabashanterare och första versionen släpptes 1988 under namnet SQL Server 1.0, den nuvarande stabila versionen är SQL Server 2019. SQL Server används för att lagra och hämta data från mjukvaruapplikationer. Som tidigare nämnts med relationsdatabaser (Codd,

(13)

2002) lagras data i SQL Server med användning av tabeller uppbyggda av rader och kolumner. Pro- gramvaran som används för att interagera med databashanteraren är SQL Server Management Studio från Microsoft (Nielsen & Parui, 2011).

Microsoft introducerade stöd för hantering av grafdata med version SQL Server 2017 (14.x) vilket möj- liggör modellering av många-till-många relationer (Microsoft, 2017). En graf i SQL Server 19 innehåller nod-tabeller och kant-tabeller, en nod-tabell representerar en enhet i ett grafschema. När en nod skapas i nod-tabellen får den ett unikt id som används för identifiering i tabellen, en kant-tabell representerar en relation mellan två givna noder. Kanterna riktas och ansluter noder där riktningen kan vara enkel eller dubbelriktad (Microsoft, 2018).

Med den senaste versionen av SQL Server 2019 implementerade Microsoft nya funktioner och uppda- teringar för hantering av grafdata. En av funktionerna de implementerade är “SHORTEST_PATH” som används för att hitta kortaste vägen mellan två noder i en graf baserat på Dijkstra’s algoritm (Microsoft, 2019).

2.3 Grafdatabaser

En graf består av en uppsättning noder och kanter som binder dem samman. Noderna representerar enheter och kanterna representerar hur dessa enheter relaterar till varandra. En kant har en riktning, en typ, en startnod och en slutnod (Hurlburt & Thiruvathukal, 2017). Grafdatabasen är ett system med metoder som Create, Read, Update och Delete (CRUD) för att överblicka och hantera en grafisk data- modell. I figur 2–2 finns tre noder som representerar en person, adress och stad. Noden person har en kant “Bosatt på” som pekar mot adress och adress har kanten “Belägen i” mot stad.

Det finns ett flertal språk för att hantera data i en grafdatabas som till exempel SPARQL, Gremlin och Cypher.

Figur 2-2: Noder med tillhörande kanter Neo4j

Neo4j är en grafdatabas med öppen källkod som är implementerad i Java, den har funnits sen 2007 och är den grafdatabas som är populärast och ligger på plats 18 av dom mest populära databaserna

(14)

i alla kategorier (DB-Engines, 2021). Den använder noder, kanter och attribut för att lagra data. Neo4j används till exempel vid sociala nätverk, spårning av bedrägerier samt identitets och åtkomsthantering (Neo4j, u.å).

Index free adjacency

Index free adjacency innebär att varje nod är medveten om dess ingående och utgående kanter till närliggande noder vilket medför att index likt de som används av relationsdatabaser är överflödiga.

Enligt Robinson et al. (2015) gör detta att hämtning av data går mycket snabbt.

Cypher

Cypher är ett frågespråk designat för att enkelt kunna användas och förstås av utvecklare och databas- användare vid hantering av data lagrat i en grafdatabas. Det möjliggör för en användare att lagra och hämta data från grafdatabasen. En av fördelarna med Cypher är att det är uttrycksfullt och stämmer väl överens med hur vi vanligen beskriver grafer med diagram. Det är ett språk som har inspirerats och lånat sin struktur från SQL. Syntaxen ger ett visuellt och logiskt sätt för att matcha mönster och relationer i grafen (Robinson et al., 2015).

Native vs Non-native

Native grafdatabas är en databas som är designad och optimerad för att lagra och hantera grafer.

Neo4j är en native grafdatabas. En Non-native grafdatabas kan till exempel vara en relationsdatabas som från början inte är skapad för att hantera grafdata. Med en non-native grafdatabas har stödet för hantering av grafdata lagts till i efterhand, därmed är non native grafdatabaser inte lika väl optimerade för detta som native grafdatabaser (Neo4j, 2018; Robinson et al., 2015).

2.4 Dijkstra’s Algoritm

Dijkstra’s algoritm är välkänd när det när det gäller att finna den kortaste och billigaste vägen mellan två angivna platser. Den tillämpar sig på nätverk där dessa typer av problem uppstår som på motor- vägssystem och kommunikationssystem. Vid ett större dataset är dock Dijkstra’s algoritm inte optimal för att hitta kortaste vägen (Noto & Sato, 2000).

2.5 ^Svarstid

Svarstid är den tid det tar från det ögonblick som en användare påbörjar en aktivitet tills datorn presenterar ett resultat. Inom datateknik handlar svarstid om elektriska kretsars snabbhet att utföra tjäns- ter. Det kan exempelvis vara en hårddisk som hämtar data eller en databasfråga (Shneiderman, 1984).

2.6 ^Python

Guido van Rossum började arbeta med Python i slutet på 80-talet och det släpptes först 1991. Det är ett okomplicerat och robust programmeringsspråk med fokus på läsbarhet och använder sig inte av symboler som “;” och “$” för att källkoden ska vara så läsbar som möjligt (Chun, 2000). Språket stödjer objektorienterad, procedurell och funktionell programmering för att möjliggöra skapandet av tydlig och logisk kod som passar små och stora projekt. Chun (2000) nämner att Python är portabelt och fungerar på flera plattformar som Windows, Mac, Linux och Raspberry PI. Det används bland annat för webbprogrammering, matematik och skriptning.

2.7 Tidigare forskning

Vid den initiala litteraturgenomgången som diskuteras under rubrik 3.2 hittades fem artiklar där jäm- förelser mellan relationsdatabaser och grafdatabaser genomförts. En jämförelse mellan grafdatabasen

(15)

Neo4j och Microsofts relationsdatabas SQL Server har däremot ej tidigare gjorts enligt litteraturge- nomgången.

Tidigare forskning visar att grafdatabaser presterar bättre vid beräkning av kortaste vägen mellan två noder samt vid frågor där databaserna måste hämta data genom nodernas kanter. En relationsdatabas kan däremot vara att föredra vid frågor som kräver matematiska beräkningar till exempel summering.

En studie använde ett dataset baserat på Österrikes vägnät för att hitta kortaste vägen mellan två platser. Författarna jämför tre olika algoritmer implementerade i grafdatabasen Neo4j samt relations- databasen PostgreSQL för att besvara frågan: “Kommer en grafdatabas att prestera bättre vid en be- räkning om kortaste vägen än en relationsdatabas?”. Algoritmer för att hitta kortaste vägen kräver många join-operationer i en relationsdatabas vilket gör dessa kostsamma samt att de ofta måste im- plementeras manuellt till skillnad mot grafdatabaser som vanligen har dessa algoritmer implementerade och optimerade. Resultatet från deras experiment visar att Neo4j är snabbare än PostgreSQL (Mi- ler et al., 2014).

I en liknande studie av Chen et al. (2020) visar resultatet att grafdatabasen Neo4j är snabbare än relationsdatabasen PostgreSQL. Studien använder sig av ett dataset med 36 968 noder som representerar Shenzhens stadstrafik-nätverk där dom jämför tre algoritmer för att hitta den kortaste vägen mellan två noder.

Jaiswal och Agrawal (2013) jämför svarstider mellan relationsdatabasen MySQL och Neo4j. De nämner ingenting om hur stort datasetet är som använts i studien. I denna studie ställer de frågor mot respektive databas för att hitta data som är ihopkopplat med relationer, till exempel “Hitta alla vänner till en specifik person”. Resultatet visar att Neo4js svarstider är lägre än svarstiderna från MySQL.

I en annan studie likt ovan genomförd av Batra, S., & Tyagi, C. (2012) jämförs svarstider mellan MySQL med Neo4j vid utsökning av data. I denna studie användes två dataset med etthundra respektive femhundra användare i ett socialt nätverk. Frågor likt följande ställdes till bägge databaserna: ”Hitta en specifik persons väns favoritfilm”. Resultatet visar att Neo4j har kortare svarstider än MySQL och att skillnaden blir större när datasetet med femhundra användare används då MySQL måste söka igenom hela datasetet för att hitta alla relationer. Författarna nämner att relationsdatabaser har börjat tappat sin betydelse på grund av dess beroende av stela scheman vilket gör det svårt att lägga till nya relationer mellan objekten, en annan sak som nämns i denna studie är att data växer i mångfald och att arbeta med relationsdatabaser med stora och komplexa scheman inte fungerar effektivt. Dom föreslår i studien att flytta dessa scheman över till en grafdatabasarkitektur.

Vicknair et al. (2010) genomförde en studie där de konstruerade tolv MySQL databaser och tolv Neo4j databaser med grafer om 1000 upp till 100 000 noder. Noderna i de olika databaserna innehöll information om slumpmässiga heltal, 8KB textsträngar eller 32KB textsträngar. Frågorna som ställde till databaserna var olika beroende på om noderna innehöll heltal eller textsträngar. Varje fråga ställdes tio gånger där den lägsta respektive högsta svarstiden uteslöts för att ingen cachning skulle påverka resultatet. Medelvärdet från de åtta kvarvarande svarstiderna räknades sedan ut. Resultatet visar att Neo4j presterar snabbare vid frågor som kräver att databaserna korsar noder via relationer. Frågor som kräver någon form av beräkning genomförs snabbare av MySQL.

(16)

3 Forskningsmetod

I detta kapitel beskrivs de forskningsmetoder studien har använt. Det omfattar bland annat forsknings- process, litteraturgenomgång och forskningsstrategi.

3.1 Forskningsprocess

Forskningsprocessen inleddes med en utförlig litteraturgenomgång för att ge en djupare kunskap inom det valda området. Genom litteraturgenomgången gavs kännedom om hur tidigare prestanda- tester genomförts med experiment för mätning av svarstider mellan olika databasarkitekturer. En mer djupgående redogörelse finns under kapitel 3.2. För att kunna få svar på frågeställningen ge- nomfördes en benchmarking där data samlades in genom observationer mot de olika databasarkitekturerna, hur datainsamlingen genomfördes återges under kapitel 3.4. De insamlade data som genererades analyserades med en kvantitativ analysmetod för att kunna svara på frågeställningen. En redogörelse över dataanalysens tillvägagångsätt finns under kapitel 3.5. En helhetsbild inspirerad från Oates (2006) över de väg samt metodval denna studie använts sig av i forskningsprocessen finns under figur 3–1.

Figur 3-1: Forskningsprocess

3.2 Litteraturgenomgång

Denna studie inleddes med en genomgång av tidigare forskning och övrig litteratur för att ge en ökad expertis inom ämnet samt en bredare grund av kunskap inför studien.

Litteratursökning

För att hitta litteratur genomfördes en efterforskning på söktjänsterna Summon samt Google Scholar.

De sökord som i första hand användes var “relational database” samt “graph database”. Ytterligare sökord som ”performance”, ”comparison” och ”comparative” togs sedan fram genom en kartläggning av nyckelord för liknande artiklar inom området. För att avgränsa sökningen ytterligare användes fil- trering för peer-review. En bakgrundsundersökning av förlaget samt författarna för de artiklar som

(17)

visades i sökningen genomfördes för att säkerställa en hög kvalitét som Oates (2006) beskriver. Efter detta skedde en genomläsning av abstract för ca tjugo artiklar som matchade sökorden väl vilket gjorde att de presenterades högt upp i sökningens resultatlista samt behandlade jämförelser av relationsdatabaser och grafdatabaser.

Oates (2006) skriver att en bra strategi för litteratursökning är att följa de referenser andra artiklar refererat. Denna metod har använts i litteratursökningen för att komma så nära den ursprungliga litteraturen som möjligt. Detta i samband med genomläsning av abstract resulterade i att fem artiklar valdes ut.

3.3 Forskningsstrategi

Enligt Oates (2006) finns sex möjliga strategier att använda sig av och de kan ses i figur 3–1. Dessa strategier är undersökning, design och skapande, experiment, fallstudie, aktionsforskning och etnografi. Denna studie har använt strategin experiment för att besvara forskningsfrågan hur prestanda skiljer sig mellan graf- och relationsdatabaser vid beräkning av kortaste vägen mellan två angivna platser. Inom akademisk forskning är experiment en strategi som undersöker orsaker och effekter samt efter bevis eller motbevis. Ett experiment är baserat på en hypotes som testas, där hypotesen är ett påstående som inte har blivit testat tidigare. Forskaren verifierar eller falsifierar den utvecklade hypotesen (Oates, 2006). Studiens experiment är ett sant experiment då det är genomfört i en kontrollerad miljö.

Experimentets hypotes är grundad utifrån litteraturgenomgången som finns under rubrik 3.2:

Grafdatabaser har snabbare svarstider i jämförelse mot relationsdatabaser vid hämtning av kortaste vägen mellan två angivna platser.

Det finns oberoende och beroende variabler att ta hänsyn till. Den oberoende variabeln kan knytas ihop med orsak och påverkar den beroende variabeln som därmed knyts ihop med effekt (Oates, 2006). I denna studie är antalet platser och förbindelser i det rälsbundna nätverket den oberoende variabeln och svarstiderna den beroende variabeln. Forskaren ska efter observation av resultatet även ta reda på varför utfallet blev som det blev och förklara utifrån den teori som finns som är kopplade till hypotesen (Oates, 2006). Denna studie kommer utifrån teoriavsnittet förklara experimentets utfall.

Ett utforskande experiment genomfördes för att kontrollera om svarstiderna från SQL Server 19 och Neo4j följer samma funktion vid antal platser och förbindelser.

3.4 Datainsamling

Karolinska Institutet (u.å) definierar datainsamling som “Systematisk insamling av data för ett bestämt ändamål från olika källor, som till exempel enkäter, intervjuer, observationer, befintliga handlingar och elektroniska apparater. De insamlade data ligger som regel till grund för statistisk analys”.

Enligt Björklund & Paulsson (2012) finns det två varianter av data, primärdata generas av metoder som observationer, intervjuer och enkäter. Primärdata är data som forskaren själv framställer och har som syfte att användas i den aktuella studien. Den andra varianten kallas sekundärdata och är den data som forskaren samlar in själv via exempelvis litteraturstudier som tagits fram i ett annat syfte än den aktuella studien. Under denna studie kommer observationer behandlas.

Observationer är en datainsamlingsmetod som forskare använder för att ta reda på vad människor faktiskt gör, snarare än vad avger sig göra. Det finns olika strategier av observation, exempelvis delta- garens observation och systematisk observation. Deltagande observation är när forskaren deltar i si- tuationen och det kan göras antingen öppet där deltagare har vetskap att det bedrivs forskning eller hemligt då deltagarna inte vet att forskning bedrivs (Oates, 2006).

(18)

Studien utgick från strategin systematisk observation där forskaren bestämmer i förväg vilken typ av händelser som ska observeras. I denna studie samlades tio svarstider in från varje databas genom observation. Begränsningen till att använda tio svarstider motiveras av att svarstiderna efter tio exekveringar ej skiljde sig åt så pass mycket att de skulle påverka experimentets resultat. Dessa svarstider sammanställdes sedan i ett dokument för vidare analys.

Litteraturgenomgången delas in i två delar, initialt utforskas litteraturen efter lämpliga forskningsidéer men även relevant material för att ge en känsla om det valda området för att kunna inringa ett forsk- ningsproblem. Den andra delen fortsätter under hela studien för att kunna stödja argument från forskaren (Oates, 2006).

3.5 ^Dataanalys

Kvalitativ och kvantitativ dataanalys är de två huvudsakliga typerna för att analysera de insamlade data (Oates, 2006).

Oates (2006) skriver att kvalitativa data är all data som ej är numerisk. Den kvalitativa data är lågt strukturerad och kan bestå av ord, bilder samt ljudupptagningar. Kvalitativa data genereras bland annat genom enkäter, inspelade intervjuer, dokument och liknande från fallstudier, aktionsforskning och etnografi. För att analysera kvalitativa data måste forskaren tolka ord, bilder och ljud till ett resultat som är viktigt för forskningsämnet.

Kvantitativa data är baserat på siffror och är den huvudsakliga data som genereras vid experiment och undersökningar. En analys av kvantitativa data kan genomföras med statistiska beräkningar samt visu- aliseringar i form av tabeller och diagram (Oates, 2006).

I denna studie har kvantitativa analysmetoder använts. Det högsta och lägsta värdet av de tio insamlade svarstiderna uteslöts för att cachning eller systemprocessaktivitet ej skulle påverka experimentets resultat. Experimentens resultat har därefter analyserats med beskrivande statistiska beräkningar, hy- potestest samt visuellt förtydligats av tabeller och diagram.

3.6 Etik och dataset

Oates (2006) skriver att forskning och uppförande måste vara laglig genom hela arbetet. Datasetet som använts i experimentet är sekretessbelagt och har erhållits av studiens samarbetspartner Trafikverket.

Datasetet representerar det svenska järnvägsnätverket och används av Trafikverket inom olika an- vändningsområden och är därför inte ett dataset enbart framtaget för denna studie.

Datasetets objekt

Datasetet består av objekt som benämns “platser”. Varje objekt har nio attribut: plId, plTyp, plNamn, grannar, northing, easting, driftPlId, plcKod och landsKod. Datasetet innehåller totalt 1320 platser och 2788 förbindelser.

Objektens attribut

För detta experiment är de användbara attributen: plId, plNamn, samt grannar. Övriga attribut tillför ingenting för denna studie och utesluts därmed ur experimentet.

plId består av tre sub-attribut: plNr, plSign samt objTypNr. plNr är en identifierare av datatyp heltal och innehåller ett unikt värde för varje objekt. plSign är objektets signatur av datatyp sträng. Attributet objTypNr tillför ingenting och utesluts. plNamn är av datatypen sträng och innehåller objektets full- ständiga namn. Attributet grannar är en samling av närliggande objekt med information om de närlig- gande objektens plId och dess avstånd i meter till huvudobjektet.

(19)

4 Experimentellt genomförande

I detta avsnitt presenteras förberedelser inför experimentet samt dess genomförande.

4.1 Förberedelser

Under hela experimentets förberedande fas utfördes kontinuerligt utforskande tester och exekveringar för att ge en ökad kunskap om mjukvara, miljö, samt fråge- och programmeringsspråk.

Python - Extrahera platser och grannar

Det erhållna datasetet innehöll flertalet attribut som ej var aktuella för studien då attributen inte skulle påverka svarstiderna. För att underlätta hanteringen togs de oönskade attributen bort och ursprungliga datasetet delades upp i två mindre dataset med två Python-skript som återfinns i Bilaga 1. Ur- sprungliga datasetet “platsForbindelse.json” lästes in för att sedan extrahera de användbara attributen och skriva ut de två nya dataseten till csv-filerna “platser.csv” samt “grannar.csv”.

SQL Server 19 - Läs in CSV-filer till platserTEMP och grannarTEMP

För att möjliggöra inläsning av de genererade CSV-filerna till nod-tabellen “Platser” samt tabellen

“Grannar” som lagrar data om varje plats närliggande grannar användes två tabeller för temporär lag- ring, detta gjordes för att underlätta hantering samt få en bättre visuell överblick av data. Dessa två tabeller användes sedan för att hämta data och läsa in i nod och kanttabellerna.

SQL Server 19 - Läs in från temporära tabeller till slut-tabeller

De temporära tabellerna används för att läsa in data till nod-tabellen “Platser” samt tabellen “Gran- nar”. Dessa två tabeller används sedan för att konstruera kant-tabellen “forbindelser”. SQL-källkod för detta återfinns i Bilaga 2.

Neo4j - Läs in platser och förbindelser

I bilaga 3 återfinns Cypher källkod för att läsa in platser och förbindelser i Neo4j från dataseten platser.csv och forbindelser.csv som genererades under rubrik 4.1.1.

(20)

SQL Server 19 - Shortest path

Kodexempel på hur en sökning kan se ut i SQL Server 19. I källkoden nedan söker vi efter kortaste vägen mellan Stockholm och Uppsala med SQL Server 19 Shortest Path funktion. Källkoden är ett mo- difierat exempel ursprungligen hämtad från Microsofts officiella hemsida (Microsoft, 2020). Modifi- kationen består av ändring av variabelnamn samt vilket attribut som ska användas vid exekveringen.

SELECT Sign, Förbindelse FROM (

SELECT

Plats1.sign AS Sign,

STRING_AGG(Plats2.namn, '->') WITHIN GROUP (GRAPH PATH) AS Förbindelse, LAST_VALUE(Plats2.nr) WITHIN GROUP (GRAPH PATH) AS LastNode

FROM

Platser AS Plats1,

förbindelse FOR PATH AS förb, Platser FOR PATH AS Plats2

WHERE MATCH(SHORTEST_PATH(Plats1(-(förb)->Plats2)+))

AND Plats1.nr = 430 -- Platsens primärnyckel för snabbare sökning.

) AS Q

WHERE Q.LastNode = 559 -- Platsens primärnyckel för snabbare sökning.

Figur 4-1: Källkod för SQL Server 19 Shortest path Neo4j - Dijkstra’s algoritm

Kodexempel på hur en sökning kan se ut i Neo4j. Här söker vi efter kortaste vägen mellan Stockholm och Uppsala med Neo4j Dijkstra’s algoritm.

MATCH (p1:Plats { plats_sign: 'Stockholm' }) MATCH (p2:Plats { plats_sign: 'Uppsala' })

CALL apoc.algo.dijkstra(p1, p2, 'AVSTAND', 'avstand') YIELD path, weight RETURN path, weight

Figur 4-2: Källkod för Neo4j Shortest path

4.2 Genomförande

Experimentet som genomfördes var att först mäta svarstiderna på SQL Server 19 och sen samma exekvering på Neo4j mellan fyra utvalda rutter, Stockholm och Uppsala, Stockholm och Göteborg, Umeå och Halmstad samt Kiruna och Ystad för att hitta kortaste vägen. I tabell 5–1 visas antalet platser och förbindelser den kortaste vägen innehöll med start- och slutplats inkluderat. SQL Server 19 har endast en funktion för beräkning av kortaste vägen och den använder vid studiens genomförande Dijkstra’s algoritm, vilket gjorde att även denna algoritm användes i Neo4j.

(21)

Konfiguration av hårdvara och mjukvara

• Datormodell: Lenovo Thinkpad L480

• Processor: Intel(R) Core(TM)i-7-8550U CPU @ 1.80GHz

• Primärminne: 8 046 MB

• Operativsystem: Microsoft Windows 10 Pro - OS Version 10.0.19041 N/A Build 19041

• Databashanterare för SQL Server: SQL Server Management Studio 15.0.18358.0

• Databashanterare för Neo4j: Neo4j Desktop 1.4.3

Version av databaser

• Microsoft SQL Server 2019 (RTM) - 15.0.2000.5 (X64)

• Neo4j 4.2.1 Enterprise

Genomförandet

Följande beräkningar genomfördes av databasarkitekturerna:

1. Kortaste vägen mellan Stockholm och Uppsala 2. Kortaste vägen mellan Stockholm och Göteborg 3. Kortaste vägen mellan Umeå och Halmstad 4. Kortaste vägen mellan Kiruna och Ystad

Från och till platserna i Tabell 4–1 nedan används i experimentet och har valts ut baserat på dess geografiska läge samt att avståndet fågelvägen mellan platserna representerar en kort, medelkort, medel- lång och lång distans.

Sträcka Från Till Avstånd (km) Distans

#1 Stockholm Uppsala 63 Kort

#2 Stockholm Göteborg 397 Medelkort

#3 Umeå Halmstad 893 Medellång

#4 Kiruna Ystad 1421 Lång

Tabell 4-1: Sammanställning av platser som används i experimentet

Varje beräkning exekverades tio gånger för varje databasarkitektur, alla svarstider är i millisekunder (ms) och resultatet för varje exekvering noterades i Excel. När tio exekveringar var utförda uteslöts den högsta och lägsta svarstiden från resultatet för att räkna ut medelvärde baserat på de åtta kvarvarande resultaten. Detta gjordes för att säkerställa att ingen cachning eller systemprocessaktivitet skulle på- verka experimentets slutresultat.

De utvalda sträckorna exekverades på både SQL Server 19 och Neo4j för att slutligen jämföras med varandra för att se vilken skillnad det är i svarstiderna mellan SQL Server 19 och Neo4j. Avslutningsvis noterades antalet platser och förbindelser som den kortaste vägen innehöll för att säkerställa att SQL Server 19 och Neo4j uppvisade samma resultat.

För att kontrollera om databasarkitekturernas svarstider följer samma funktion i takt med platser och förbindelser, utfördes ett utforskande experiment med tio exekveringar för tio olika sträckor där antalet platser och förbindelser ökade stegvis från 3 till 256 samt 4 till 510 respektive.

(22)

5 ^Resultat

I detta kapitel presenteras resultaten som framkom under experimenten. Informationen är framtagen av exekveringarna som utförts mot databaserna.

5.1 Platser och förbindelser

Tabell 5–1 visar antal platser och förbindelser som den beräknade kortaste sträckan består av.

Sträcka Platser Förbindelser

#1 23 48

#2 39 136

#3 158 314

#4 256 510

Tabell 5-1: Sträckor med antal platser och förbindelser.

5.2 Svarstider

I tabell 5–2 presentas resultat från de exekveringar mot SQL Server 19 och Neo4j där det framgår att svarstiderna blir längre när fler platser och förbindelser blir involverade. Resultatet tydliggör att Neo4j har kortare svarstider än SQL Server 19.

Sträcka SQL Server 19 Svarstid (ms)

SQL Server 19

Standardavvikelse (ms)

Neo4j Svarstid (ms)

Neo4j

Standardavvikelse (ms)

#1 197 6 14 8

#2 704 26 19 10

#3 1586 101 22 12

#4 1939 65 25 12

Tabell 5-2: Svarstider och standardavvikelse för SQL Server 19 samt Neo4j.

5.3 Jämförelse mellan SQL Server och Neo4j

Tabell 5–3 visar en jämförelse mellan SQL Server 19 och Neo4j. Faktorn mellan SQL Server 19 och Neo4j klargör skillnaden mellan databaserna. Resultatet från hypotestesterna för samtliga sträckor avrunda- des till ett p-värde på 0,0009.

Sträcka SQL Server 19 Svarstid (ms)

Neo4j

Svarstid (ms)

Faktor P-Värde

#1 197 14 14 0,0009

#2 704 19 37 0,0009

#3 1586 22 72 0,0009

#4 1939 25 78 0,0009

Tabell 5-3: Jämförelse mellan SQL Server 19 och Neo4j.

(23)

5.4 Svarstidernas funktion vid antal platser och förbindelser

I figur 5–1 och 5–2 visualiseras exekveringarnas genomsnittliga svarstid för de tio olika sträckorna.

Svarstiderna för SQL Server 19 och Neo4j ökar i takt med antalet platser och förbindelser. Figur 5–1 följer en S-funktion till skillnad från figur 5–2 som följer en mer linjär funktion.

Figur 5-1: SQL Server 19 - Svarstider (ms) - Tio sträckor

Figur 5-2: Neo4j - Svarstider (ms) - Tio sträckor

(24)

6 ^Diskussion

I följande kapitel diskuteras studiens resultat samt metod.

6.1 Resultatdiskussion

Experimentet påvisade att grafdatabaser har snabbare svarstider än relationsdatabaser när det gäller högt sammankopplade data med många relationer vilket stämmer väl överens med tidigare studier presenterade under rubrik 2.7. Dessa studier visar att grafdatabaser är snabbare vid hämtning av data med många relationer likt ett nätverk. Resultaten från de exekveringar som utförts i experimentet med SQL Server samt Neo4j för att möjliggöra kartläggning av prestanda mellan de två databaserna bekräf- tar det som tagits fram av tidigare studier.

Resultatet från exekveringarna mot databasarkitekturen SQL Server 19 visade att svarstiderna ökade i takt med att distansen på sträckorna blev längre, en längre sträcka medför att antalet involverade platser och förbindelser blir fler vilket leder vidare till en längre svarstid. Sträcka #1 består av 23 platser och 48 förbindelser med en genomsnittlig svarstid på 196,9 ms och en standardavvikelse på 7,6 ms.

Sträcka #2 innefattar 39 platser och 136 förbindelser mellan Stockholm och Göteborg där blev svarstiden 704,1 ms i medelvärde med en standardavvikelse på 26,1, detta innebär att svarstiden är 258%

större i jämförelse med sträcka #1. Exekveringen av sträcka #3 mellan Umeå och Halmstad gav en genomsnittlig svarstid på 1586,3 ms med en standardavvikelse på 100,6 vilket gör att svarstiden blir näs- tan dubbelt så stor kontra sträcka #2. Sträcka #4 består av 256 platser och 510 förbindelser med en genomsnittlig svarstid på 1939,4 ms och är därmed 22% större än sträcka #3 men nästan tio gånger större än sträcka #1 med en standardavvikelse på 65,4 ms.

Svarstiderna som uppmätts med Neo4j ökar i samband med antalet platser och förbindelser likt SQL Server 19. Den genomsnittliga svarstiden för sträcka #1 mellan Stockholm och Uppsala baserat på dess 23 platser och 48 förbindelser var 13,8 ms. Sträcka #2 mellan Stockholm och Göteborg gav ett medel- värde i ms på 18,5 vilket ger en ökning jämfört med sträcka #1 på 34%. Genomsnittliga svarstiden för sträcka #3 var 21,9 ms vilket är en ökning på 18% mot sträcka #2 mellan Stockholm och Göteborg, i jämförelse var den genomsnittliga svarstiden för sträcka #4 25,3 ms med 256 platser och 510 förbin- delser. Detta ger nästan en dubblerad ökning i svarstid mellan sträcka #1 och sträcka #4, när antalet platser och förbindelser är ca 11 gånger fler.

Experimentets hypotes “Grafdatabaser har snabbare svarstider i jämförelse mot relationsdatabaser vid hämtning av kortaste vägen mellan två angivna platser.” verifierades då Neo4j har snabbare svars- tider vid beräkning av kortaste vägen mellan två angivna platser. Svarstiderna användes i ett Wilcoxon- test där nollhypotesen var att det inte är någon skillnad i svarstidernas median. Testet visade att det genomsnittliga p-värdet blev 0,0009 vilket gör att vi förkastar nollhypotesen på en 1% signifikansnivå.

I figur 6–1 nedan visualiseras resultaten i ett stapeldiagram där det tydliggörs att svarstiderna ökar i takt med att möjliga platser och förbindelser ökar. Figuren visar även en sammanställning där SQL Server 19 och Neo4s svarstider ställs bredvid varandra för att få en tydligare visuell bild över utfallet av experimentet.

(25)

Figur 6-1: Jämförelse av svarstider mellan Neo4j och SQL Server 19

En jämförelse mellan relationsdatabasen SQL Server 19 och grafdatabasen Neo4j visar att svarstiderna i SQL Server 19 påverkas i större utsträckning än Neo4j beroende på hur många platser och förbindel- ser som är inkluderade i beräkningen. Tabell 5–3 visar att sträcka #1 mellan Stockholm och Uppsala hade en faktor på 14,3 till Neo4j’s fördel och sträcka #4 Kiruna och Ystad hade en faktor på 76,7. Den genomsnittliga faktorn visar att Neo4j är 50,4 gånger snabbare än SQL Server 19 i detta experiment.

I figur 5–1 och 5–2 visualiserades resultatet från det utforskande experiment som genomfördes för att kontrollera om databasernas svarstider följer samma funktion av platser och förbindelser. Svarstiderna från SQL Server 19 ser ut att följa en s-funktion och svarstiderna från Neo4j mer tenderar till att vara linjär. Detta kan bero på att vissa sträckor i norra Sverige endast har få möjliga förbindelser då järn- vägsnätet ej är lika utbrett vilket skulle kunna förklara varför kurvan i figur 5–1 planar ut.

I en studie likt denna används Österrikes vägnät för att hitta kortaste vägen mellan två platser med databasarkitekturen PostgreSQL (Miler et al., 2014). Författarna skriver att relationsdatabaser som kräver många join-operationer i en relationsdatabas gör dessa förfrågningar kostsamma. Resultatet från deras experiment visar att PostgreSQL är långsammare än Neo4j. Detta stämmer överens med vårt experiment som visar liknande resultat att grafdatabaser har snabbare svarstider än relationsdatabaser.

Batra, S., & Tyagi, C. (2012) styrker vår studie som att visar att Neo4j inte påverkas nämnvärt av den ökade mängden platser och förbindelser, däremot i relationsdatabasen MySQL syntes det tydligt att den påverkas. Vid dataset på 100 objekt var det en faktor på 6 och vid dataset på 500 objekt så hade Neo4j en faktor på 30 i jämförelse mot MySql. Detta går att koppla ihop med vårt resultat att gapet mellan relationsdatabaser och grafdatabaser kommer öka ju större datamängden blir.

Experimentet visar likt de resultat Vicknair et al. (2010) fått fram i sin studie att Neo4j är snabbare vid hämtning av data som är högt sammankopplad med många relationer. Enligt Vicknair et al. (2010) beror detta på att relationsdatabaser inte är skapade för att korsa tabeller vid hämtning av data. De nämner även att en hämtning från en databas med 1000 noder gav en svarstid från relationsdatabasen MySQL på 38,9 ms och Neo4j fick en svarstid på 2,8 ms vilket ger en faktor 13,9. Detta stämmer väl överens med vad som framkom under denna studies experiment där Neo4j var snabbare än SQL Ser- ver.

Chen et al. (2020) uppvisar liknande resultat som framkommit under vårt experiment när de använder tre algoritmer för att söka ut den kortaste vägen i relationsdatabasen PostgreSQL och grafdatabasen Neo4j. Studien visar att Neo4j är snabbare än PostgreSQL vid ett mindre dataset om 3300 kanter med

(26)

tillhörande noder men att skillnaden i svarstiden blir större när datasetet innehåller 100 000 kanter med tillhörande noder. Detta förklaras med att PostgreSQL måste söka igenom hela datasetet för att hitta aktuella relationer där Neo4j endast behöver titta på de relationer som är direkt anslutna till den nuvarande noden som algoritmen befinner sig på. Det visade att Neo4j var 30 % snabbare till skillnad från vår studie som visade att Neo4j är 50,4 gånger snabbare. Detta kan bero på att Chen et al. (2020) jämförde tre olika algoritmer och en av dessa var Dijkstra för att få fram en genomsnittlig skillnad i procent. Noto & Sato (2000) nämner att Dijkstra’s algoritm är välkänd vid sökning för att hitta kortaste vägen men att svarstiderna kan bli anmärkningsvärt långa när sökområdet blir för brett.

Neo4j är en native grafdatabas designad och optimerad för lagring och hantering av grafer (Neo4j, 2018; Robinson et al., 2015). Till skillnad mot Neo4j är SQL Server 19 en relationsdatabas där hantering av grafdata lagts till i efterhand från och med version 2017 (Microsoft, 2021). Detta pekar på att resultaten i denna studie innebär att Neo4j lämpar sig bättre för att beräkna kortaste vägen i ett rälsbundet nätverk.

SQL Server 19 har en procentuellt större ökning för varje sträcka i samband med att antalet involverade platser och förbindelser ökar. Vid beräkning av kortaste vägen mellan sträcka #1 och sträcka #2 ökar SQL Server 19 med 258% samtidigt som Neo4j endast har en ökning med 34%. Genomgående i experimentet sker en större ökning procentuellt för SQL Server 19 och den genomsnittliga ökningen är 135% för SQL Server 19 och 23% för Neo4j. Detta stämmer överens med att relationsdatabaser inte är optimerade för att hantera data som innehåller många komplexa relationer (Medhi & Baruah, 2017;

Chen et al., 2020).

Resultatet visar också att grafdatabasen Neo4j inte blir nämnvärt påverkad av ökad mängd platser och förbindelser i jämförelse med relationsdatabasen SQL Server 19. Det visar en tydlig skillnad i ökning av svarstiderna för relationsdatabasen och grafdatabasen i takt med att det geografiska sökområdet blir större. Med de olika beräkningarna kommer antalet möjliga vägar öka vilket innebär att antalet involverade platser och förbindelser för varje beräkning kommer bli fler. Resultatet visar även en variation i ökning av svarstider mellan SQL Server 2019 och Neo4j i samband med att platser och förbindelser ökar. Baserat på detta antar vi att ökningen av databasernas svarstider skiljer sig från varandra. Denna studie visar tillsammans med tidigare forskning att grafdatabaser lämpar sig väl mot högt sammankopplade nätverk med många relationer som sociala nätverk och transportnätverk.

6.2 Metoddiskussion

Som forskningsstrategi har experiment använts då vi bedömer det som mest lämpad för denna forskning då andra studier som utfört liknande arbete utgått från experiment. Oates (2006) skriver att experiment möjliggör en hög nivå av precision vid mätning och analysering av data vilket lämpar sig väl för denna typ av experiment då data består av svarstider uppmätta i millisekunder. Därtill menar Oates (2006) att experiment kan ses som en av de mest vetenskapliga strategierna på då den är väletablerad.

Experiment som forskningsstrategi medför även en del nackdelar. En av nackdelarna är att experimenten ofta är konstgjorda miljöer. Oates (2006) nämner också att det är svårt eller nästan omöjligt att kontrollera relevanta variabler. I en verklig miljö sker ofta kommunikation med databaser från flertalet system och användare samtidigt. Dessa variabler skulle kunna påverka svarstiderna.

För att säkerställa tillförlitliga resultat använde sig studien av Microsofts och Neo4j’s officiella databashanterare vid mätning av svarstider för att komma så nära databasen som möjligt utan användning av mellanliggande benchmarking-verktyg. Exekveringarna mot databaserna utgick från dokumentationen för respektive databas då den ansågs som optimerad och uppdaterad.

Både SQL Server 19 och Neo4j använder sig av Dijkstra’s algoritm för att söka kortaste vägen mellan två angivna noder. Microsoft skriver dock inte i dokumentationen vilken algoritm som används då den kan komma att ändras i framtiden. Efter en konversation med en av utvecklarna som arbetar med

(27)

SHORTEST_PATH funktionen hos Microsoft så bekräftar dom att det är Dijkstra’s algoritm som används vid studiens genomförande. Detta medför att återskapande av experimentet i framtiden kan behöva använda exakt samma version av SQL Server som studien använt sig av då algoritmen för SHOR- TEST_PATH kan komma att förändras i framtida versioner.

En svaghet i studien är att endast Dijkstra’s algoritm för beräkning av kortaste vägen användes, ett naturligt steg för vidare forskning är att undersöka hur svarstiderna påverkas av andra algoritmer.

Detta skulle möjliggöra en undersökning av svarstider där varje databas använder sin optimala algoritm vid beräkning av kortaste vägen.

Den datainsamlingsmetod som användes i denna forskning är observationer då den passade väl in med studiens experiment. Observation som datainsamlingsmetod kan ibland kritiseras för att det finns bris- ter i tillförlitligheten eftersom forskningen beror på forskaren själv och att det är svårt att upprepa av en annan forskare (Oates, 2006). Sådan kritik är ej applicerbar på denna studie då det sekretessbelagda datasetet är den begränsande beståndsdelen.

Den data som tillhandahållits av Trafikverket presenteras inte i detalj vilket innebär att utförliga resultat ej går att redovisa, detta kan medföra minskad tillförlitlighet. Data består av begränsat antal platser och förbindelser som med stor sannolikhet inte kommer öka signifikant i framtiden. Därför kan databasarkitekturerna uppnått sin kulmen i svarstid vid frågor om kortaste vägen mellan två angivna noder, då exekveringen av sträcka #4 mellan Kiruna och Ystad är en av de längre sträckorna i det svenska järnvägsnätet. Det som kan antas ske vid ett större dataset med längre sträckor är att relationsdata- basens svarstider kommer fortsätta att växa som påvisat av Chen et al. (2020).

Som en del av experimentets förberedande fas utfördes ett försök av att återskapa det experiment Jaiswal och Agrawal (2013) genomför där de hämtar data baserat på följande fråga: “Hitta alla vänner till en specifik person”. Då det inte fanns några dataset eller kodexempel att följa genererade vi ett eget dataset baserat på de uppgifter som finns beskrivna i studien samt konstruerade en egen SQL- fråga. Försöket resulterade i att de svarstider vi fick fram inte stämde överens med det återskapade experimentets svarstider. Det försök vi genomförde gav betydligt lägre svarstider i SQL Server mot vad författarna presenterar. Studien nämner inte om de använt primärnycklar för att göra sökningarna eller om de använt någon annan datatyp vilket kan medföra en indexering som skiljer sig mot det klustrade index vi skrev om i avsnitt 2.2.3. Författarna presenterar inte heller hur de använt sig av join- satser i sina SQL-frågor vilket kan påverka svarstiderna (Chen et al., 2020; Vicknair et al., 2010).

(28)

7 Slutsats & förslag till vidare forskning

I detta kapitel besvaras studiens syfte och frågeställning i slutsatsen. Därtill diskuteras förslag till vidare forskning.

7.1 ^Slutsats

Syftet med studien var att undersöka vilken skillnad det är i prestanda mellan relationsdatabasen SQL Server 2019 och grafdatabasen Neo4j vid beräkning av kortaste vägen mellan två platser när data representeras som ett rälsbundet nätverk. För att kunna besvara denna fråga gjordes en djupdykning i litteraturen för att få kunskap inom det valda området. Efter litteraturgenomgången genomfördes ett experiment för att svara på studiens frågeställning.

Experimentet visar att både relations- och grafdatabaser kan hantera data som är högt sammankopp- lat med många relationer, där grafdatabaser verkar ha en fördel gentemot relationsdatabaser.

Resultatet visar att grafdatabasen Neo4j har snabbare svarstider i jämförelse mot relationsdatabasen SQL Server 19 samt att skillnaden blir större vid längre sträckor då fler platser och förbindelser är involverade. De statistiska beräkningar samt hypotestestets p-värde på 0,0009 bekräftar detta. Med ökat antal platser och förbindelser är ökningen av Neo4j’s svarstider linjär samtidigt som svarstiderna från SQL Server 19 har en större ökning i början för att sen avta. Detta avtagande fenomen kan vi ej förklara. Ökningen i svarstid från sträcka #1 till sträcka #4 i SQL Server gick från 197 till 1939 ms, i jämförelse ökade Neo4j sin svarstid från 14 till 25 ms. Detta beror på att relationsdatabaser använder join-satser för att hitta aktuella relationer och måste därför söka igenom hela datasetet till skillnad från grafdatabaser som endast använder relationer direkt anslutna till den nuvarande noden där algoritmen befinner sig vilket gör att svarstiderna blir mindre.

SQL Server 19 och Neo4j kan båda hantera denna typ av data och den slutsats som kan dras är att Neo4j är mer linjär och effektiv vid frågor om kortaste vägen i ett rälsbundet nätverk.

7.2 Förslag till vidare forskning

Förslag till vidare forskning är att utföra flera experiment där grafdatabaser jämförs mot andra databasarkitekturer som till exempel GIS databaser eller dokumentdatabaser. Andra alternativ är att simu- lera tågtrafik i en grafdatabas så frågorna blir mer komplexa. Ett liknande experiment på signifikant större dataset med fler platser och förbindelser kan ge djupare kunskap om hur förändring i svarstider mellan graf och relationsdatabaser förhåller sig till varandra. Implementera och jämföra algoritmer med olika tidskomplexitet.

Jämförelse mellan graf- och relationsdatabas