SORTERINGSALGORITMER FÖR
STRÖMMAD DATA
Algoritmer för sortering av spatio-temporal data i
JSON-objekt
SORTING ALGORITHMS FOR
STREAMING DATA
Algorithms for sorting spatio-temporal data in
JSON objects
Examensarbete inom huvudområdet Informationsteknologi
Grundnivå 30 högskolepoäng
Vårtermin 2020
Joakim Apelqvist
Handledare: Henrik Gustavsson
Examinator: Yacine Atif
Sammanfattning
Data från positioneringssystem som GPS är alltmer vanlig, men är svårhanterlig i traditionella datalagringssystem. Sådan data består av spatiala och temporala attribut och representeras i vissa fall i JSON-format. Sortering av JSON objekt sker via inbyggda sorteringsfunktioner, vilka kräver att hela JSON objektet finns avserialiserat i minnet. Om datan strömmas måste hela datamängden tas emot innan sortering kan ske. För att förebygga detta krävs att en utvecklare utvecklar metoder för sortering av strömmad data medans strömmen pågår. Den här studien identifierar tre lämpliga sorteringsalgoritmer, och jämför dessa på hur snabbt de sorterar den strömmade datan samt deras minnesanvändning. En klientapplikation och en serverapplikation jämfördes även för att se om sortering på servern genererade bättre resultat. De slutsatser som drogs av experimentets resultat var att merge sort var snabbast men använde mest minne, medans heap sort var långsammast men hade lägst minesanvändning. Klientapplikationens sorteringstider var något snabbare än serverapplikationens.
Innehållsförteckning
1
Introduktion ... 1
2
Bakgrund ... 2
2.1 Geografiska informationssystem ... 2 2.1.1 Spatio-temporal data ... 2 2.2 JSON ... 3 2.3 Sorteringsalgoritmer ... 5 2.3.1 Bubble sort ... 6 2.3.2 Quick sort ... 6 2.3.3 Bucket sort ... 72.3.4 Strömmad och serialiserad data ... 8
3
Problemformulering ... 10
3.1 Frågeställning ... 10 3.2 Hypoteser ... 11 3.3 Delmål ... 114
Metodbeskrivning ... 12
4.1 Etiska aspekter ... 135
Genomförande ... 14
5.1 Litteraturstudie ... 14 5.1.1 Sorteringsalgoritmer ... 14 5.1.2 Webbapplikationer ... 14 5.2 Progression... 14 5.2.1 Simulering av GPS-data ... 14 5.2.2 Strömning av JSON-data ... 16 5.2.3 Utveckling av applikationer ... 165.2.4 Script och verktyg för mätning ... 20
5.3 Pilotstudie ... 21
6
Utvärdering ... 24
6.1 Specifikationer ... 24 6.2 Experiment... 24 6.2.1 Klientapplikationen ... 25 6.2.2 Serverapplikationen ... 27 6.3 Analys ... 30 6.4 Slutsatser ... 327
Avslutande diskussion ... 34
7.1 Sammanfattning ... 34 7.2 Diskussion ... 34 7.2.1 Etik ... 35 7.3 Framtida arbete... 36Referenser ... 37
1
Introduktion
Mängden geografisk data som genereras har de senaste åren ökat i samband med användandet av positioneringssystem som exempelvis GPS (Barroudi, Harwood & Karunasekera, 2012). Data från positioneringssystem är komplex och består av spatiala och temporala attribut, vilket gör den nästintill omöjlig att lagras och analyseras i en relationsdatabas (Pant, Fouladgar & Elmasri, 2018). Icke-triviella uträkningar på spatio-temporal data som exempelvis hastighet mellan två punkter, högsta höjd över havet närmast en specifik punkt, eller vilken tid på dagen högst hastighet nåddes kräver alltså en annan metod (Pant, Fouladgar & Elmasri, 2018). Spatio-temporal data används bland annat i geografiska informationssystem, som bland annat analyserar och illustrerar spatio-temporal data (Miller, 2006). Google Maps är en webbapplikation som hanterar stora mängder geospatial data med hjälp av GeoJSON, ett JSON-baserat format för hantering av geospatial data (Chen, Hong & Luo, 2019).
JavaScript Object Notation (JSON), är en datastruktur som är vanligt förekommande som överföringsformat på webben (Petković, 2017). Ett JSON-objekt består av ett eller flera nyckel/värde-par och kan innehålla primitiva datatyper samt objekt och arrayer (Chausseur, Li & Patel, 2013). JSON har tack vare sin lättviktighet och naturliga koppling till JavaScript blivit en standard för dataöverföring på webben (Chausseur, Li & Patel, 2013).
Sortering av data är användbart för att effektivisera sökning, lagring, och borttagning av data i en datastruktur (Yang, Yu & Gan, 2011). Sorteringsalgoritmer utför sorteringen på olika sätt och är lämpade för olika sorters data. Inbyggda sorteringsfunktioner av datastrukturer kräver att hela datasetet är avserialiserat i minnet (Maeda, 2012). Chasseur, Li & Patel (2013) konstaterar att avserialisering av stora JSON-objekt är kostsamt resursmässigt, därför behöver en utvecklare implementera en algoritm som kan sortera utan att avserialisera hela objektet (Bourhis, Reutter & Vrgoč, 2019).
Problemet om man vill sortera stora mängder spatio-temporal data i JSON-format ligger alltså i hur man på effektivast sätt sorterar utan att ha hela datasetet i minnet. Pétković (2017) föreslår i sin studie lagring av JSON i en relationsdatabas, men eftersom relationsdatabaser inte är lämpliga att hantera spatio-temporal data krävs en annan lösning (Pant, Fouladgar & Elmasri, 2018). Den undersökning som kommer genomföras i den här studien är en jämförelse av sorteringsalgoritmer tillämpade på spatio-temporal data i JSON-format. Eftersom komplexitetsteori förutsätter att hela datasetet är lagrat i minnet när algoritmen tillämpas är resultatet inte självklart.
Den vetenskapliga metod som kommer att användas för undersökningen är ett tekniskt experiment. Experimentets faktorer är sorteringsalgoritmerna och plattformarna, JavaScript och ASP.NET. Variablerna som kommer att mätas i undersökningen är responstid och minnesanvändning.
Merge sort, heap sort, och tree sort valdes ut som sorteringsalgoritmer att jämföras. En websocketserver i node.js skapades för att strömma data till en klientapplikation och en
2
Bakgrund
2.1 Geografiska informationssystem
Geografiska informationssystem (GIS) har de senaste decennierna utvecklats och använts i allt större utsträckning i akademiska, civila, och politiska sammanhang (Miller, 2006). Dessa system används främst för att analysera och illustrera geografisk data (Miller, 2006).
Google Maps är en webbapplikation som knappt kan klassas som ett GIS, men som tack vare sin användbarhet och snabba responstider är populärt bland amatörer för att visualisera och söka bland geografisk data (Miller, 2006). Eftersom Google Maps tillåter användare att delta i projektet och tillföra information och bilder med mera, menar Miller (2006) att Google Maps kan klassas som ett PPGIS (Public Participation Geographical Information System).
Figur 1
Skärmbild från Google Maps med longitud och latitud
Figur 1 visar hur Google Maps användargränssnitt ser ut i skrivande stund, här har användaren markerat en punkt på kartan och Google Maps svarar med att visa bland annat longitud och latitud för den markerade punkten. Google Maps använder GeoJSON, ett JSON-baserat format för hantering av geografisk data (Chen, Hong & Luo, 2019).
2.1.1 Spatio-temporal data
Global Positioning System (GPS) har de senaste åren blivit alltmer utvecklat och förbättrat, samtidigt som användingen ökat i förhållande till användande av smarta enheter (Hess et al, 2012; Barroudi, Harwood & Karunasekera, 2012). Data från positioneringssystem som GPS har spatiala och temporala attribut och är nästintill omöjligt att lagra i relationsdatabaser på
grund av komplexiteten av spatio-temporala objekt (Pant, Fouladgar & Elmasri, 2018). Det finns dock verktyg och lösningar för att lagra och analysera stora mängder spatial data i relationsdatabaser (Lisowski, Piórkowski & Leśniak, 2017).
GPS tillverkaren Garmin använder filformatet .gpx för att lagra loggar i systemets interna minne. Dessa loggar innehåller så kallade ”waypoints”, punkter eller noder, som representerar en specifik geografisk punkt vid en specifik tidspunkt (Van der Spek, Van Schaick & De Bois, 2009).
Figur 2 Exempeldata i XML-format från en Garmin GPS
Som man kan se i figur 2 representerar varje ”trkpt”-element en geografisk punkt vid ett specifikt klockslag, vilket gör det möjligt att sortera objekten både på deras geografiska punkt men också beräkna hur många sekunder som passerar mellan två geografiska punkter. Ett annat format för representering av geografisk data som används av bland andra Google Maps och OpenStreetMap är JSON (Chen, Hong & Luo, 2019).
2.2 JSON
JSON står för JavaScript Object Notation och är en datastruktur som är vanligt förekommande som överföringsformat på webben. Ett JSON-objekt består av ett eller flera nyckel/värde-par, där nyckeln är separerad från värdet med en kolontecken (se figur 3) . JSON innehåller vanligtvis flera arrayer eller objekt (Petković, 2017). Värdet kan även vara ett nytt JSON-objekt vilket innebär att JSON-objekt kan vara nästlade i flera nivåer (Bourhis, Reutter & Vrgoč (2019). En array är en lista av värden, medans ett objekt består av ett eller flera nyckel- och värde-par. Dessa datastrukturer är globala klasser inom JavaScript, som har egna metoder och egenskaper. En av de mest användbara metoderna i arrayklassen är ”sort”-metoden,
På grund av JSON’s lättviktighet och naturliga koppling till JavaScript har JSON blivit en de facto standard för dataöverföring bland webbtjänster (Chausseur, Li & Patel, 2013). JSON är det mest populära dataformatet för att ta emot och skicka data via API (Pezoa, Reutter, Suarez, Ugarte & Vrgoč, 2016).
De datatyper ett JSON-objekt kan bestå av är fyra primitiva samt två strukturerade typer (Chausseur, Li & Patel, 2013):
String: Unicodetecken mellan citationstecken (rad 3 & 4 i figur 3)
Number: Siffra eller siffror med eller utan decimaltecken (rad 6 i figur 3) Boolean: True eller false (rad 8 i figur 3)
Null: Nullvärde, inget värde alls (rad 9 i figur 3)
Object: En samling attribut i form av nyckel/värde par, omsluten av klammerparenteser (rad 2 till 5 i figur 3)
Array: En kommaseparerad lista av värden, omsluten av hakparenteser (rad 7 i figur 3)
Figur 3 Exempelstruktur på ett JSON-objekt
JSON-objektet är omsluten av klammerparenteser, och följer strukturen för arrayer och objekt som finns i JavaScript (Petković, 2017).
JSON har som fördel mot XML att dess strukturer är likadana som de strukturer som finns i programmeringsspråk (Severance, 2012). Figur 4 visar hur GPS-datan från figur 2 skulle kunna representeras i JSON.
Figur 4 Exempeldata i JSON-format från en GPS
Bourhis, Reutter & Vrgoč (2019) menar att trots JSON’s popularitet finns det väldigt få studier som berör det och det saknas ett allmänt accepterat ramverk för hantering av JSON. De föreslår i sin artikel en datamodell för JSON i form av ”JSON-träd” för att hantera tillkortakommanden i JSON. Ett exempel av en sådan begränsning är avsaknaden av sorteringsmetod för JSON-objekt.
2.3 Sorteringsalgoritmer
Sortering av data är användbart för att effektivisera sökning, lagring, och borttagning i en lista av data (Yang, Yu & Gan, 2011). Det finns två huvudkategorier av algoritmer för att sortera data, intern och extern. Intern sortering sparar data i huvudminnet medans extern sortering sparar data på hårddisken (Yang, Yu & Gan, 2011). Interna sorteringsalgoritmer kan delas in i ytterligare två kategorier, jämförelsebaserade och icke-jämförelsebaserade algoritmer (Yang, Yu & Gan, 2011). Jämförelsebaserade algoritmer inkluderar bland andra bubble sort, insertion sort, merge sort och quick sort. Icke-jämförelsebaserade algoritmer inkluderar bland andra bucket sort, counting sort, och radix sort (Joshi, Panwar & Pathak, 2013).
Yang, Yu & Gan gjorde år 2011 en studie som jämförde fem sorteringsalgoritmer, bubble, selection, insertion, merge, och quick sort. De genererade slumpmässiga tal i sju storleksordningar från 2000 till 128000 och utvärderade de fem algoritmerna ur ett tidskostnadsperspektiv och ur ett minnesperspektiv. Deras slutsats var att för små datamängder är insertion sort eller selection sort bra alternativ, medans större datamängder gynnade merge sort och quick sort (Yang, Yu & Gan, 2011). Den data de applicerade
Yang, Yu & Gan (2011) menar att sorteringsalgoritmer kan bedömas på dess tidskomplexitet och minneskomplexitet. Dessa representeras vanligtvis med Big O notation, ett notationssystem som bedömer hur komplex en funktion är i relation till inputstorleken (Joshi, Panwar & Pathak, 2013).
2.3.1 Bubble sort
Bubble sort, kallas ibland för sinking sort, är en av de långsammaste jämförelsebaserade sorteringsalgoritmerna och fungerar genom att jämföra två element åt gången, och byta plats på dem om det första är större än det andra (Cheema, Sarwar & Yousaf, 2016).
Bubble sort är olämplig för stora dataset då tidsåtgången ökar markant med inputvolymen (Cheema, Sarwar & Yousaf, 2016).
Figur 5 Flöde för bubble sort
Tidskomplexiteten av bubble sort är för sortering av heltal i en array O(n²), medans minneskomplexiteten inte påverkas av inputstorlek och därför är O(1) (Yang, Yu & Gan, 2011). Min (2010) analyserade två dubbelriktade bubble sort optimiseringar, och fastställde att optimisering av bubble sort är möjlig i relativ tidsåtgång, men att tidskomplexiteten och minneskomplexiteten förblev densamma.
2.3.2 Quick sort
Quick sort är en av de snabbaste jämförelsebaserade sorteringsalgoritmerna (Xiang, 2011). Den fungerar genom att välja en “pivot” från elementen i en lista. Sedan partitioneras elementen på båda sidor om pivoten så att element med mindre värde flyttas till vänster om pivoten och de element med högre värde flyttas till höger. Denna process återupprepas sedan rekursivt på partitionerna tills alla partitioner är sorterade. Slutligen sätts partitionerna ihop tillsammans med den initiala pivoten och bildar en sorterad lista (Xiang, 2011).
Quick sort använder en rekursiv algoritm. Detta är användbart för implementering och analys av algoritmen, men innebär även att algoritmen kan kräva mycket stackutrymme beroende på volym av input (Xiang, 2011).
Figur 6 Flöde för quick sort med 7 som initial pivot
Medelvärdet för tidskomplexiteten av quick sort tillämpat på en array med heltal är O(n log n), och med sämsta möjliga konfiguration av element O(n²). Minneskomplexiteten är O(log n) (Yang, Yu & Gan, 2011).
2.3.3 Bucket sort
Bucket sort är en icke-jämförelsebaserad sorteringsalgoritm som delar upp en lista av objekt i ett antal ”hinkar” baserat på en viss egenskap hos objektet. När alla objekt är uppdelade i respektive hinkar kan algoritmen tillämpas rekursivt på varje hink, eller så tillämpas en annan sorteringsalgoritm på objekten i hinkarna. Slutligen sätts objekten ihop i ordning av hinkarnas egenskaper (Joshi, Panwar & Pathak, 2013).
Joshi, Panwar & Pathak (2013) jämförde i sin studie tre icke-jämförelsebaserade sorteringsalgoritmer: bucket sort, counting sort, och radix sort. Resultatet visade att bucket sort kan vara snabbare än quick sorts medeltidskomplexitet, men att det kräver värden jämnt distribuerade i den osorterade listan.
Figur 7
Bucket sort flöde med fem hinkar som representerar nummervärden
Flödet i figur 7 visar inte hur hinkarnas värden sorteras då det kan vara en rekursiv bucket sort eller en annan sorteringsalgoritm.Tidskomplexiteten för bucket sort är linjär, alltså O(n) i bästa fall, men kan bli så komplex som O(n²) (Joshi, Panwar & Pathak, 2013).
2.3.4 Strömmad och serialiserad data
Serialisering innebär transformering av data till ett format för bestående lagring (Gao, Qi & Hou, 2019). De vanligaste serialiseringsformaten på webben är JSON och XML (Severance, 2012). JSON har som fördel mot XML att strukturer i ett JSON-objekt är likadana i programmeringsspråk (Severance, 2012). För att inbyggda sorteringsfunktioner ska fungera krävs det att hela datasetet är avserialiserat i minnet (Maeda, 2012). Chausseur, Li & Patel (2013) konstaterar att avserialisering av stora JSON-objekt kan bli kostsam resursmässigt, därför krävs det att utvecklaren kringgår detta om ett stort JSON objekt behöver sorteras (Bourhis, Reutter & Vrgoč, 2019).
Figur 8 Serialisering och avserialisering av JSON i JavaScript
Som man kan se i figur 8 serialiseras JSON i JavaScript med metoden ”stringify()”, och avserialiseras med ”parse()”. Avserialiserad JSON tolkas som objektet som definieras på rad 1, medans serialiserad JSON är en textsträng lagrad direkt i minnet.
Figur 9 Serialisering och avserialisering av XML i JavaScript
Figur 9 visar hur XML serialiseras och avserialiseras i JavaScript, där avserialiserad XML är ett DOM-träd och avserialiserad XML är likt JSON en textsträng.
Strömmad data är data genererad från exempelvis sensorer som skickar data kontinuerligt (Le-Phuoc, Dao-Tran, Parreira & Hauswirth, 2011). Denna form av data kan genereras av bland annat mobiltelefoner, bilar, eller positioneringssystem som GPS. Datan som strömmas är svårhanterlig och för processering som sortering krävs det att en utvecklare skapar särskilda metoder (Le-Phuoc et al, 2011).
Zunke och D’Sousa (2014) jämförde JSON och XML på hur effektivt de hanterade strömmad data, och JSON var klar vinnare i experimentet. Plattformen de genomförde experimentet på var dock Java, vilket innebär att resultatet inte nödvändigtvis är det samma i JavaScript eller ASP.NET.
3
Problemformulering
Eftersom avserialisering av stora JSON-objekt är resursintesivt och strömmade JSON-objekt ej enkelt kan hanteras behöver en utvecklare hitta ett sätt att hantera stora JSON-objekt utan att avserialisera hela objektet (Bourhis, Reutter & Vrgoč, 2019; Le-Phuoc, Dao-Tran, Parreira & Hauswirth, 2011).Pétković (2017) föreslår lagring av JSON i en relationsdatabas som en lösning på detta problem. Relationsdatabaser som använder exempelvis MySQL har dock egna begränsningar, och en sådan är att det är i princip omöjligt att analysera och utföra beräkningar på spatio-temporal data (Pant, Fouladgar & Elmasri, 2018). Uträkningar som exempelvis sortering på spatio-temporal data är alltså icke-triviella och kräver någon form av algoritm. De inbyggda sorteringsfunktioner som finns tillgängliga kräver att hela datasetet är lagrat avserialiserat i minnet (Maeda, 2012), men om detta inte är möjligt på grund av storleken av datasetet behöver en sorteringsalgoritm implementeras som kan sortera datasetet utan att ha allt i minnet. Det är inte självklart under dessa omständigheter vilken sorteringsalgoritm som resulterar i snabbast responstid. Detta dels eftersom komplexitetsteori förutsätter att hela datasetet är lagrat i minnet, och dels eftersom de flesta experiment och jämförelser av sorteringsalgoritmer har genomförts på datastrukturer, och inte på ett serialiserade eller strömmade JSON-objekt (Yang, Yu & Gan, 2011; Cheema, Sarwar & Yousaf, 2016).
Problemet den här studien avser att lösa är hur man effektivast sorterar större (100mb+) strömmade JSON-objekt innehållandes spatio-temporal data. För att utvärdera detta måste tidskomplexitet, minnesanvändning, och faktisk tid det tar att utföra sorteringen analyseras. Xiang (2011) understryker vikten av tidskomplexitet för sorteringsalgoritmer, och Cheema, Sarwar & Yousaf (2016) hävdar att en effektiv sorteringsalgoritm bedöms på sin tids och minneskomplexitet. Bounnady, Phanthavong, Pathoumvanh & Sinhalath (2016) visade att processeringstider för sortering på serversidan kan skilja betydligt beroende på vilket ramverk som används, därför är det även relevant att jämföra sortering via klienten kontra servern.
3.1 Frågeställning
Det huvudsakliga syftet med undersökningen i den här avhandlingen är att analysera och jämföra olika tillvägagångssätt för sortering av stora mängder strömmad spatio-temporal data i JSON-format. Minnesanvänding och responstid är de två variabler som kommer att avgöra vilken algoritm på vilken plattform som bedöms prestera bäst eftersom det enligt Cheema, Sarwar & Yousaf (2016) är dessa som karaktäriserar en effektiv sorteringsalgoritm. Då komplexitetsteori förutsätter att hela datasetet redan är lagrat i minnet är det inte uppenbart vilket algoritm som kommer att prestera bäst.
Den här studien ämnar besvara följande frågeställningar:
- Vilken sorteringsalgoritm har lägst minnesanvändning vid tillämpning på strömmad spatio-temporal data i JSON-format?
- Vilken sorteringsalgoritm sorterar strömmad spatio-temporal data i JSON-format med lägst responstid?
- Hur stor är skillnaden i responstid när sorteringen sker på servern istället för på klienten?
3.2 Hypoteser
En hypotes har tagits fram från frågeställningarna och förväntas bevisas eller motbevisas genom den här studiens undersökning:
Sortering implementerad i ASP.NET resulterar i lägre responstid än sortering implementerad i JavaScript när den tillämpas på ett strömmat JSON-objekt med spatio-temporal data
Hypotesen understöds av experimenten utförda av Abdullah (2010), och Bounnady et al. (2016) som jämförde processeringstider och konkluderade att JavaScript och PHP inte hade någon markant skillnad, respektive att ASP.NET var betydligt snabbare än PHP.
Klientapplikationens resultat i mätningarna kommer att agera som baslinje för studien.
3.3 Delmål
Ett antal delmål har identifierats för att kunna genomföra undersökningen. Delmålen kommer att hjälpa till att styra arbetet och uppnå ett värdefullt resultat. Nedan följer 9 delmål som kommer ingå i arbetsprocessen:
1. Välj ut lämpliga sorteringsalgoritmer för sortering av strömmad data 2. Simulera spatio-temporal GPS-data i JSON-format
3. Implementera strömning av JSON-data
4. Implementera sorteringsalgoritmer för sortering av den strömmade JSON-datan 5. Utveckla script för mätningar och insamling av responstider
6. Identifiera verktyg för mätning av minnesanvändning 7. Utför mätningar och lagra värden
8. Sammanställ och visualisera resultaten från mätningarna 9. Analysera och utvärdera resultaten
4
Metodbeskrivning
Fallstudier är evidensbaserade undersökningar där man med flera akademiska källor som utgångspunkt undersöker ett eller flera specifika fenomen. Datainsamling fortgår under studien för att till sist utföra statistisk analys på datan. Fallstudier är oftast inriktade på en specifik egenskap hos ett subjekt, eller att fastställa relationer mellan egenskaper. En fallstudie är lämplig för utvärdering av metoder och verktyg, och är till skillnad från experiment lättare att planera och är mer realistiskt grundade. Nackdelarna med denna metod är dock att resultaten är svårare att generalisera och tolka (Wohlin et al, 2012).
Användarstudier är inriktade på att samla information från användare av ett system eller verktyg. Denna metod används oftast när ett verktyg eller system har använts ett tag. Frågeformulär och intervjuer är de främsta källorna av data i den här metoden, och datan kan vara antingen kvantitativ eller kvalitativ. En fördel med användarstudier är att de genererar stora mängder variabler att utvärdera, dock kan svarens kvalitet försämras ju fler frågor som ställs. För den här studiens undersökning är en användarstudie inte lämplig eftersom den kvantitativa datan som ska utvärderas kan genereras på egen hand (Wohlin et al, 2012). Litteraturstudier ämnar att samla och analysera all tillänglig forskning relaterad till en specifik forskningsfråga. Dessa studier kräver ett rigoröst och vetenskapligt arbetssätt och är lämpliga när undersökaren vill identifiera och förstå ett forskningsområde helt och hållet. För undersökningen i den här studien är en litteraturstudie opassande på grund av forskningsfrågans specifika natur samt tidsbegränsningen (Wohlin et al, 2012).
Ett experiment är en empirisk undersökning som manipulerar en variabel eller faktor i en kontrollerad miljö. Genom att ändra en faktor eller variabel medans andra faktorer är oförändrade kan man mäta effekten av ändringen och utifrån detta genomföra en statistisk analys för att dra en generell slutsats av resultaten. Experiment utgår från ett antagande att det finns en relation mellan orsak och verkan på ett objekt. Från detta antagande kan en hypotes bildas, som sedan kan bevisas eller motbevisas med experimentet. Tekniska experiment innefattar användandet av olika verktyg på samma objekt, exempelvis två sorteringsalgoritmer på samma JSON-objekt. En stor fördel med experiment som vetenskaplig metod är en hög nivå av kontroll som kan uppnås genom att utföra experimentet i en kontrollerad miljö såsom ett laboratorium. Detta är dock inte alltid möjligt, och i de fallen där en helt kontrollerad miljö är ouppnåbar kan vissa omständigheter vara omöjliga att kontrollera. Nackdelen med experiment som vetenskaplig metod är nivån av förberedelse och den relativa svårigheten i genomförandet och analysen av resultaten (Wohlin et al, 2012). Kvantitativ forskning innebär forskning som innefattar kvantitativ data, och utförs ofta i form av kontrollerade experiment. Kvantitativa undersökningar är lämpliga när effekten av en ändring eller aktivitet ska mätas, vilket är vad den här studiens undersökning ämnar att göra. Eftersom kvantitativ data ska analyseras och jämföras i studien, samt att en hög nivå av kontroll i undersökningen är att föredra, är ett tekniskt experiment den metod som är lämpligast för den här undersökningen, och därför också den metod som kommer att användas för undersökningen (Wohlin et al, 2012). Faktorerna i experimentet är de sorteringsalgoritmer som kommer att implementeras, samt två plattformar: en JavaScript-klient och en ASP.NET server. Den kvantitativa datan, variablerna, som mäts i undersökningen kommer att vara responstid från sorteringsalgoritmen samt den totala minnesanvändningen.
4.1 Etiska aspekter
Wohlin et al (2012) menar att alla empiriska undersökningar som har någon mänsklig faktor måste ta hänsyn till etiska aspekter. De nämner att subjekt måste ge frivilligt medgivande att delta i undersökningen, att studien bör ha ett vetenskapligt värde när människor delar med sig av potentiellt känslig data, att konfidentialiteten av känslig information är forskarens ansvar, samt att fördelarna med studien måste väga tyngre än riskerna. Sortering av JSON-data är i sig självt inte konfidentialitetsmässigt relevant, men om äkta GPS-JSON-data används som dataset och sorteras blir dessa principer relevanta. Sortering av GPS-data kan resultera i eventuellt känsliga uppgifter om en privatperson, såsom hemaddress eller jobbaddress, eftersom GPS-data består av bland annat koordinater och tidsstämpel (Rundle et al, 2016). Potentiellt kan äkta GPS-data även användas för att spåra eller kartlägga en persons rörelser. Därför är det viktigt att den data som används kommer från en medgivande källa. Källan kan vara öppen data från internet med specifikt medgivande från uppladdaren, eller från en privatperson som skrivit under ett medgivandeformulär. Alternativt kan GPS-datan helt eller delvis simuleras, vilket mitigerar konfidentialitetsrisken.
En annan viktig aspekt är återskapning eller upprepning av experimentet. Wohlin et al (2012) bedömer att en återskapning är en sann återskapning om det är möjligt att återskapa både designen och resultaten. Detta är relevant för eventuella framtida arbeten som bygger vidare eller utgår från undersökningens experiment. För att uppnå sann återskapbarhet i den här studien kommer all kod som skrivs i genomförandet presenteras på GitHub. Utöver koden behöver den data som används redovisas. Hårdvaruspecifikationer, mjukvara, och använda verktyg är också relevant att redovisa då dessa kan bidra till att resultatet i återskapningen ändras. För att underlätta återskapning av experimentet och mitigera konfidentialitetsrisken kommer det GPS-dataset som används i experimentet inte att vara äkta och istället simuleras helt.
5
Genomförande
5.1 Litteraturstudie
5.1.1 Sorteringsalgoritmer
För att uppnå de delmål som identifierats i tidigare kapitel behövs först och främst information och kunskap om olika sorteringsalgoritmer för att kunna välja de som har potential att prestera väl under experimentets förutsättningar. Sorteringsalgoritmer är ett populärt forskningsområde och många studier jämför och beskriver ingående hur olika algoritmer fungerar. Yang, Yu & Gan (2011) jämförde i sin studie fem olika jämförelsebaserade algoritmer som de ansåg vara de mest populära för användning i applikationer. Desvärre hänvisar de endast till kodexempel och erbjuder ingen förklaring till hur algoritmerna fungerar. Cheema, Sarwar & Yousaf (2016) och Wang (2011) går i sina respektive studier mer djupgående in på analys av bubble sort, merge sort, och quick sort vilket kompletterar Yang, Yu & Gan’s studie. Joshi, Panwar & Pathak (2013) analyserade och jämförde fem icke jämförelesebaserade sorteringsalgoritmer, de förklarar även hur algoritmerna fungerar och redovisar analys som kan vara hjälpsam för att välja sorteringsalgoritmer för denna studie. En sökning på ”sorting streaming data” på StackOverflow resulterar i flera goda råd från användare som föreslår algoritmerna ”tree sort”, ”merge sort”, och ”heap sort”. Kodexempel för varje algoritm finns tillgängligt på diskussionsforumet StackOverflow, med algoritmens namn som sökterm. Dessa tre algoritmer håller under sorteringsförloppet en delvis sorterad lista, vilket är önskvärt för strömmad data.
5.1.2 Webbapplikationer
De två applikationer som ska utvecklas är en klientapplikation i JavaScript, och en serverapplikation i ASP.NET. Båda applikationerna måste kunna kommunicera med en websocketserver för att ta emot data. För att implementera en websocketklient i JavaScript finns Wang, Salim & Moskovits’ (2013) bok ”The Definitive Guide to HTML5 WebSocket” som referens. Websocketklienten på ASP.NET servern kan implementeras med hjälp av Microsofts dokumentation (Microsoft.com, 2019) och användare på StackOverflow med söktermen ”asp.net clientwebsocket”.
Applikationerna kommer att sortera geografiska punkter utifrån förbestämda koordinater, därför behövs en formel som kan räkna ut detta. En sökning på StackOverflow på ”distance between coordinates” resulterar i ”Haversine formula” med kodexempel.
5.2 Progression
5.2.1 Simulering av GPS-data
Det dataset som ska användas för experimentet kommer att vara delvis simulerat från en existerande GPX-fil (LenaSYS, 2018). Eftersom GPX-filen använder XML måste först den existerande filen konverteras till JSON. För att utföra konverteringen utvecklades ett bash-script (Appendix A). 1
Figur 10 GPX-data före och efter konvertering till JSON
Den ursprungliga GPX-filen var 3.2mb stor och den konverterade JSON-filen blev 1.3mb stor. För den här studien behövdes en större fil, så mängden simulerad data behöver vara ungefär 99mb. Antalet objekt i JSON-filen var cirka 9635, alltså behövdes ytterligare 990,000 objekt simuleras.
För att utföra simuleringen utvecklades ett bash-script som inkrementerade eller dekrementerade latitud, longitud och altitud.2 Detta script var dock väldigt långsamt och
kunde endast generera ett objekt i sekunden, vilket hade inneburit 275 timmar för 990,000 objekt. Eftersom 275 timmar inte är optimalt utvecklades ett python-script med samma funktionalitet.3 Scriptet ökar eller minskar värdena för longitud, latitud, och altitud för varje
nytt objekt som skapas, samt lägger till en tidsstämpel med den nuvarande tiden. Detta innebär att datan blir ganska orealistisk som GPS-data, men den är passande för studiens ändamål. Slutprodukten av simuleringen blev en 155mb stor JSON-fil innehållandes ungefär 1,210,000 objekt.
Ett problem som uppstod med detta script var att alla simulerade objekt hade samma skillnad i latidud, longitud, altitud, samt tidsstämpel. Detta gör det omöjligt att sortera på ett meningsfullt sätt eftersom sorteringen sker på spatio-temporala variabler. Med hjälp av randombiblioteket i python genererades slumpmässiga inkrement för alla variabler, vilket resulterar i mer användbar data för sortering.4 När de första sorteringstesterna gjordes på
datasetet blev det uppenbart att mängden data var för stor, så mängden data delades med tre och den slutliga mängden data blev 400,000 objekt i en 51mb stor fil. Scriptet ändrades även till att fullt simulera datan då de ursprungliga objekten inte användes för simuleringen (Appendix B).5
5.2.2 Strömning av JSON-data
För att strömma JSON-data behövs någon form av serverapplikation utvecklas som kan kommunicera med klientapplikationen. Websocket är ett protokoll för full-duplex tvåvägskommunikation via en ”socket” och möjliggör effektiv kommunikation mellan server och klient (Pimentel & Nickerson, 2012). En websocketserver i NodeJS utvecklades därför för att kunna strömma JSON-data. Servern läser in hela JSON-filen och väntar på att användaren skickar ett meddelande via websocketprotokollet. När detta sker skickar servern ett objekt i taget till klienten för att simulera en ström av data.6 Detta blev snabbt ohållbart då det tog för
lång tid att skicka 400,000 objekt en åt gången, istället togs beslutet att skicka 100 objekt varje meddelande.7 För att underlätta mätningar och göra applikationen mer användbar gjordes det
möjligt att skicka flera förfrågningar efter varandra.8
Figur 11 Funktion för att skicka meddelanden från websocketserver
5.2.3 Utveckling av applikationer
5.2.3.1 JavaScript
Två applikationer utvecklades i studien, en klientapplikation i JavaScript och en serverapplikation i ASP.NET. Den första applikationen som utvecklades var den i JavaScript. Inledningsvis implementerades websocketklienten med hjälp av grundlig dokumentation och en uppsjö av googleträffar på websocket tack vare protokollets populäritet. 9
Websocketklienten i JavaScript bygger på ett WebSocket-objekt som initieras med websocketserverns address. Sedan kan objektets metod ”onmessage” användas för att hantera inkommande meddelanden. 6https://github.com/a17joaap/Examensarbete/commit/b1bb97c 7https://github.com/a17joaap/Examensarbete/commit/994be8c 8https://github.com/a17joaap/Examensarbete/commit/9e2dd9a 9https://github.com/a17joaap/Examensarbete/commit/b1bb97c
Figur 12 Websocket-objektets “onmessage” metod
Som figur 12 visar är det mottagna meddelandet alltid ett objekt med flera olika fält, bland annat vilken address det kom ifrån och vilken tid, samt själva meddelandet.
När denna funktionalitet var klar utvecklades sorteringsalgoritmerna.10 Tree sort och heap
sort är två annorlunda algoritmer som bygger upp en datastruktur innan själva sorteringen sker. Tree sort bygger upp ett ”Binary Search Tree”, som är en datastruktur fylld av noder. Varje nod har två subträd, ett med noder av lägre värden samt ett med noder av högre värden. Figur 13 visar hur det är uppbyggt, med noden med lägst värde längs till vänster, och noden med högst värde längst till höger.
Figur 13 Binary Search Tree
För att implementera detta skapades två klasser, Node och BinarySearchTree.11 Med hjälp av
metoder i BinarySearchTree-klassen kan nya instanser av Node-klassen enkelt lagras i datastrukturen. Sorteringen sker när strömmen har tagit slut och alla noder är lagrade, med hjälp av en metod i BinarySearchTree som går igenom hela strukturen från det lägsta värdet till det högsta.
Heap sort implementerades på ett liknande sätt eftersom den också bygger upp en datastruktur, en såkallad max heap.12 En max heap är likt binary search tree ett binärt träd,
datastrukturen fullt uppbyggd kan sorteringsalgoritmen flytta det första elementet i strukturen sist i listan och fortsätta så tills alla element är sorterade.
Merge sort implementerades genom att sortera varje meddelande som kom från strömmen, och sammanfoga sorterade segment när det var möjligt. 13 När strömmen upphörde
sammanfogades de resterande segmenten till en slutgiltig sorterad lista.
Till sist skapades markup och styling, och möjligheten för användaren att välja en sorteringsalgoritm och sedan klicka på en knapp för att starta strömningen.1415
Figur 14 Applikationens design
Figur 15 CSS animering visas när strömmen hanteras
13https://github.com/a17joaap/Examensarbete/commit/453296b 14https://github.com/a17joaap/Examensarbete/commit/8b08154 15https://github.com/a17joaap/Examensarbete/commit/52b8f11
Figur 16 De tio första elementen i den sorterade listan visas för användaren
Figur 14, 15, och 16 visar flödet i applikationen, från att användaren väljer sorteringsalgoritm och startar strömmen, tills att resultatet presenteras för användaren.
5.2.3.2 ASP.NET
Serverapplikationen skrevs i C# ASP.NET Core MVC med hjälp av Visual Studio. Likt progressionen för JavaScript-applikationen implementerades websockets först.16 Websockets
fungerar på ett annorlunda sätt i C#, och kräver att man använder asynkrona funktioner för att ansluta och motta meddelanden. När ett meddelande tas emot måste det buffras i en ”ArraySegment” struktur, som sedan kan konverteras till en array av bytes som representerar meddelandet (se Figur 17).
Sorteringsalgoritmerna kunde portas över till C# från JavaScript med enkelhet då språken har liknande syntax, och tack vare den objektorienterade lösningen av tree sort och heap sort.1718
Den första versionen av applikationen använde i princip samma JavaScript-fil som JavaScript-applikationen men med sorteringslogiken borttagen.19 Detta innebar dock att två
websocketklienter anslöt till websocketservern samtidigt vilket skapade problem. Lösningen var att byta ut websocketanslutningen i JavaScript-filen mot två AJAX förfrågningar till Controllern.20 Controllern har två funktioner som hanterar dessa förfrågningar, den ena
startar strömningen medans den andra väntar på att sorteringen blir klar och skickar sedan tillbaka resultatet.21
5.2.4 Script och verktyg för mätning
Ett script utvecklades med Chrome-tillägget Tampermonkey som automatiskt begär nya strömmar via ett button-element (Appendix C).22 Det använder sig av ”InteractionObserver”,
ett API som låter en hänvisa till en callback-funktion när ett element rör vid ett annat element eller viewport. Med detta API körs en funktion varje gång elementet som innehåller laddningsanimationen (se Figur 15) i applikationen blir synligt eller osynligt. Laddningsanimationen blir synlig när användaren klickar på strömknappen och göms när resultatet av sorteringen tas emot. Klockslaget i millisekunder sparas vid start och stopp, och subtraheras från varandra för att få ut sorteringstiden. Resultatet sparas i en array och en ny ström begärs. När ett visst antal resultat har sparats i arrayen skrivs resultaten till en CSV-fil som automatiskt laddas ned.
Figur 18 Kod som exekveras när ström startar eller sortering är klar
För att mäta minnesanvändning i de olika applikationerna togs två metoder fram. För klientapplikationen utvecklades ett nytt Tampermonkey script som mäter den i Chrome
globala variabeln window.performance.memory.usedJSHeapSize (Appendix D). 23
Denna variabel visar det antal bytes som den aktiva JS Heapen består av. Genom att mäta denna vid strömmens start samt när resultatet visas kan den totala minnesanvändningen för 19https://github.com/a17joaap/Examensarbete/commit/479f66c 20https://github.com/a17joaap/Examensarbete/commit/1c287a0 21https://github.com/a17joaap/Examensarbete/commit/31c6584 22https://github.com/a17joaap/Examensarbete/commit/3f4c11f 23https://github.com/a17joaap/Examensarbete/commit/4822f09
algoritmen räknas ut. För att få tillgång till objektet window.performance.memory med aktuell data krävs det att Chrome startas med flaggan ” --enable-precise-memory-info”. Ett problem uppstod dock på grund av skräphanteringen i JavaScript. Eftersom skräphantering sker automatiskt kan man inte säkerställa att skräphanteringen inte aktiveras under pågående ström, vilket påverkar resultaten i mätningen. Därför behövs Chrome startas med ytterligare en flagga: ”--js-flags="--expose-gc". Denna flagga ger tillgång till skräphanteringsfunktionen i JavaScript så att man manuellt kan aktivera den via
window.gc(). Med hjälp av denna funktion kan man alltså manuellt aktivera
skräphanteringen efter varje hanterad ström, vilket säkerställer en korrekt mätning.
Serverapplikationen använder en liknande metod för mätning av minnesanvändning, istället för ett script är lagringen av värden inbyggd i programmet. Programmet använder
GC.GetTotalMemory() för att räkna ut minnesanvändningen, samt GC.Collect() för att
manuellt aktivera skräphanteringen.
5.3 Pilotstudie
För att säkerställa att studien är genomförbar med den kod som skrivits och att mätningar är möjliga att genomföra startades en pilotstudie. I pilotstudien mättes varje sorteringsalgoritm 100 gånger per plattform. Figur 19 visar hur sorteringstiderna i klientapplikationen ser ut, medans figur 20 visar serverapplikationens motsvarighet. Det uppkom ett antal spikar i tiderna på serverapplikationen, där vissa punkter visade sorteringstider på mindre än 100 millisekunder. Dessa kan bero på hur koden i serverapplikationen är skriven, eftersom websockets i ASP.NET använder asynkrona funktioner för meddelanden kan en ny ström ha startat innan koden hunnit återställa alla datastrukturer och därmed gett ett svar direkt. De spikar som visar på dubbla sorteringstiden är svårare att förklara men kan bero på nätverksproblem. Antalet spikar är dock relativt lågt och kan tas bort från kommande analyser utan att resultatet påverkas.
Figur 20 Sorteringstider i serverapplikationen
Resultaten från figur 19 och figur 20 verkar indikera att heap sort är långsammast, medans merge sort och tree sort är snabbast på varsin plattform. Tidskomplexiteten för alla tre algoritmer är O(n log n) så här kan man se en antydan på att tidskomplexiteten är annorlunda när algoritmerna appliceras på strömmad data.
Efter att ha tagit bort spikarna från serverapplikationens resultat togs följande diagram fram som en jämförelse mellan klientapplikationen och serverapplikationen.
Som figur 21 visar kan en skillnad mellan de två applikationerna antydas och resultatet verkar indikera att klientapplikationen sorterar strömmen av data något snabbare än serverapplikationen.
För minnesanvändningen togs endast ett stapeldiagram fram som visar hur mycket minne, representerat i megabyte, varje algoritm använde. Även här användes 100 mätningar per algoritm.
Figur 22 Minnesanvändning för vardera algoritm
I figur 22 presenteras medelvärdet av de 100 mätningarna samt standardavvikelse för respektive algoritm. Resultatet verkar illustrera att heap sort använder minst minne medans merge sort använder klart mest. Detta stämmer överrens med minneskomplexiteten på algoritmerna då heap sort har O(1) medans merge sort och tree sort har O(n).
Pilotstudien har visat att studien är genomförbar och att ytterligare mätningar kan utföras. Antal mätpunkter kommer att ökas till 500 för varje algoritm på vardera plattform, och storleken på strömmen kommer att ökas och minskas för att upptäcka eventuella mönster.
6
Utvärdering
Pilotstudiens resultat visar att vidare experiment är möjliga och att resultaten skiljer sig åt mellan plattformarna. De spikar som uppkom i Figur 20 gick inte att återskapa, detta kan bero på en uppgradering av hårdvara som gjordes mellan pilotstudien och utvärderingen. Metoden för att mäta minnesanvändningen på serverapplikationen ändrades efter pilotstudien från GC.GetTotalMemory() till GC.GetTotalAllocatedBytes() för att ge ett mer precist resultat. 24
6.1 Specifikationer
Tabell 1 presenterar de hård- och mjukvaruspecifikationer som användes i experimentet.
Tabell 1 Tekniska specifikationer för experimentet
Hårdvara Specifikation
Operativsystem Windows 10 Pro 64-bit
Processor Intel i5-9400F 4GHz
RAM 2 x 8GB DDR4 2400Mhz
Grafikkort NVIDIA GeForce GTX 960
Lagring Seagate 320GB ST320820AS
Mjukvara Specifikation
Visual Studio Version 16.5.2
Tampermonkey Version 4.9
Google Chrome Version 83.0.4103.61
Node.js Version 8.10.0
.NET Core Version 3.1
6.2 Experiment
För varje mätserie i experimentet mättes 500 mätpunkter, tabell 2 visar en överblick över de olika testfallen som ingick i experimentet. Totalt genomfördes 12 testfall, där varje testfall utfördes med de tre sorteringsalgoritmerna merge sort, heap sort, och tree sort. Faktorerna i experimentet är storleken på strömmen, plattformen, och sorteringsalgoritmerna. Variablerna som mäts i experimentet är sorteringstid samt minnesanvändning.
Tabell 2 En överblick över de testfall som ingår i experimentet Klientapplikation
Sorteringstid Klientapplikation Minnesanvändning Serverapplikation Sorteringstid Serverapplikation Minnesanvändning
25MB
data Testfall 1.1 Testfall 2.1 Testfall 3.1 Testfall 4.1
50MB
data Testfall 1.2 Testfall 2.2 Testfall 3.2 Testfall 4.2
75MB
data Testfall 1.3 Testfall 2.3 Testfall 3.3 Testfall 4.3
6.2.1 Klientapplikationen
Testserierna 1 och 2 består av mätningar på klientapplikationen med varierande storlek på den strömmade datan.
Figur 23 Medelvärde och standardavvikelse för sorteringstid i
klientapplikationen
Figur 23 visar hur snabbt de olika sorteringsalgoritmerna kunde hantera strömmar av varierande storlek på klientapplikationen. Resultaten tyder på att merge sort är snabbast och att skillnaden i tid mellan merge sort och de andra algoritmerna ökar allt eftersom storleken på strömmen ökar. Resultaten verkar även antyda att standardavvikelsen ökar i takt med strömmens storlek. Figur 24 visar ett linjediagram över ökningen i sorteringstid när storleken på strömmen förändras. Medelvärdena för varje algoritm vid de olika strömstorlekarna har
Figur 24 Ökning av sorteringstid i klientapplikationen baserad på strömstorlek
Figur 25 representerar medelvärdet för minnesanvändning hos sorteringsalgoritmerna. Heap sort är den algoritm som har lägst medelvärde för minnesanvändning i alla testfall, men skillnaden från tree sorts minnesanvändning är väldigt liten när strömmens storlek är 25 samt 75 MB.
Figur 25 Medelvärde och standardavvikelse för minnesanvändning i
Minnesanvändningens relativa ökning baserad på den strömmade datans storlek visas i figur 26. Likt figur 24 visar även här merge sort tecken på linjär ökning medans heap sort tyder på exponentiell utveckling, och resultaten för tree sort tyder på logaritmisk utveckling. Dock kan inga slutsatser dras av den här datan, eftersom flera mätpunkter skulle behövas för meningsfull statistik.
Figur 26 Ökning av minnesanvändning i klientapplikationen baserat på
strömstorlek
6.2.2 Serverapplikationen
I de tredje och fjärde testserierna utvärderades serverapplikationens sorteringstider och minnesanvändning. Samma metod användes för att testa båda applikationerna, med undantag för mätningen av minnesanvändning. Eftersom sorteringen sker på servern kan inte ett klientscript mäta minnesanvändningen, därför användes istället en inbyggd metod i C#. Figur 27 presenterar resultaten i testserie 3, där sorteringstid för de olika sorteringsalgoritmerna mättes. Resultaten tyder på att merge sort och tree sort sorterar strömmad data snabbare än heap sort. Pilotstudien visade tecken på att tree sort var snabbare än merge sort på serverapplikationen, vilket detta resultat verkar motbevisa.
Figur 27 Medelvärde och standardavvikelse för sorteringstid i
serverapplikationen
Figur 28 visar hur ökningen i sorteringstid ser ut när storleken på den strömmade datan växer. Alla tre algoritmer ökar i sorteringstid linjärt i takt med växande strömstorlek. Heap sort, som var den långsammaste algoritmen, verkar öka i sorteringstid i snabbare takt än de två andra algoritmerna.
Minnesanvändningen för algoritmerna presenteras i figur 29. Minnesanvändningen här är väldigt hög jämfört med resultaten från klientapplikationen, vilket kan förklaras genom att serverapplikationen involverar mer overhead än klientapplikationen. En jämföring mellan applikationerna på minnesanvändning kommer därför inte att ge ett meningsfullt resultat.
Dock kan skillnaden mellan sorteringsalgoritmernas minnesanvändning på
serverapplikationen jämföras. Merge sort presterade bra tidsmässigt, men använde betydligt mer minne än de andra algoritmerna. Heap sort och tree sort liknar varandra rent strukturellt, och dess snarlika resultat i det här testet är därför inte förvånande.
Figur 29 Medelvärde och standardavvikelse för minnesanvändning i
Den ökning i minnesanvändning som genererades från ökningen i storlek på den strömmade datan visas i figur 30. Så som ökningen i sorteringstid för serverapplikationen är även ökningen av minnesanvändning för alla tre algorimter linjär.
Resultaten från testserierna ger antydan på att merge sort är den snabbare algoritmen av de tre som jämförs i det här experimentet, samt att heap sort använder minst minne. För att statistiskt säkerställa dessa resultat behöver vidare analys genomföras.
6.3 Analys
För att kunna besvara frågeställningarna som tagits fram i problemformuleringen och för att statistiskt säkerställa resultaten i föregående kapitel behöver resultaten analyseras. Om konfidensintervall överlappar varandra behövs ett Analysis of Variance (ANOVA) test utföras för att bedöma om skillnaden är stor nog att betraktas som statistiskt meningsfull. Samtliga testfall resulterade i konfidensintervall små nog att inte överlappa med något annat intervall (Appendix E & Appendix F), därmed behövs inget ANOVA-test utföras och en statistisk säkerställd skillnad mellan sorteringsalgoritmerna i de olika testfallen kan fastställas. Resultaten visar i alla testfall att merge sort är den snabbaste av de tre sorteringsalgoritmerna. Då alla tre algoritmer har en tidskomplexitet på O(n log n) är detta ett resultat som inte var uppenbart. Testserierna visar även att heap sort var den långsammaste i alla testfall, något som heller inte var uppenbart. Merge sort kan ha presterat snabbast på grund av dess implementation, i programmet sorteras och sammanfogas de delar av datamängden som tas emot direkt. Heap sort och tree sort har en liknande struktur där den data som tas emot bygger upp en delvis sorterad datastruktur som sedan sorteras när strömmen är mottagen. Resultaten visar även en tydlig skillnad i minnesanvändning mellan sorteringsalgoritmerna. Heap sort var den algoritm som använde minst minne i alla testfall, medans merge sort använde mest. Heap sort har som egenskap att inget extra utrymme behöver användas för sorteringen, så detta resultat var någorlunda väntat. Merge sort använde betydligt mycket mer utrymme än heap sort, vilket kan bero på implementationen och att det i algoritmen skapas ett flertal extra arrayer.
För att identifiera eventuella mönster utfördes experimentet med en varierande datamängd. Resultaten i testserie 3 & 4 verkade tyda på en linjär ökning för alla tre sorteringsalgoritmer, medans testserie 1 & 2 visade tecken på exponentiell och logaritmisk ökning för specifika algoritmer. Dessa resultat kan dock inte säkerställas statistiskt eftersom det endast finns tre datapunkter för varje algoritm. För att få ett meningsfullt resultat krävs ytterligare datapunkter, vilket betyder att fler datamängder behöver testas. Detta kunde dock inte genomföras i den här studien på grund av tidsbrist.
En jämförelse mellan resultaten från klientapplikationen och resultaten från serverapplikationen behövs för att besvara frågeställningarna. Figur 31 visar skillnaden i sorteringstid för algoritmerna på båda applikationerna när strömstorleken är 25MB. Klientapplikationen genererar lägre sorteringstider än serverapplikationen med alla tre algoritmer när strömmens storlek är 25MB, något som kan statistiskt säkerställas då konfidensintervallen ej överlappar (Appendix G). Samma resultat återfinns i figur 32 som visar skillnaden i sorteringstid när strömstorleken är 50MB. Konfidensintervallen överlappar inte heller här, så detta resultat är att se som fastställt.
Figur 31 Jämförelse av sorteringstid på 25MB data med medelvärde och
Figur 33 visar resultaten i jämförelsen av sorteringstider när storleken på den strömmade datan är 75MB. Här är återigen merge sort och heap sort snabbare på klientapplikationen, men en antydan till ett mönster visar sig i resultaten för tree sort. Tree sort är något snabbare på serverapplikationen, vilket kan betyda att tree sort sorterar snabbare på serverapplikationen när datamängden är 75MB eller större. Konfidensintervallen för resultaten i figur 33 överlappar inte (Appendix G), och resultaten är därmed säkerställda. Det går dock inte att säkerställa mönstret tree sort antyder, så man kan ej med säkerhet fastställa att en större datamängd innebär snabbare sortering på serverapplikationen.
Figur 33 Jämförelse av sorteringstid på 75MB data med medelvärde och
standardavvikelse
6.4 Slutsatser
Undersökningens syfte var att identifiera hur man effektivast sorterar strömmad JSON med spatio-temporal data. Tre frågeställningar togs fram som grund för arbetet.
Den första frågeställningen var:
”Vilken sorteringsalgoritm har lägst minnesanvändning vid tillämpning på strömmad spatio-temporal data i JSON-format?”
Efter utförda experiment och analys av resultaten kan det säkerställas att heap sort använder minst minne jämfört med merge sort och heap sort. Förändring av experimentets faktorer, strömstorlek och plattform, genererar samma resultat. Merge sort använde mest minne, och använde mer än dubbelt så mycket minne som heap sort på serverapplikationen.
Den andra frågeställningen var:
”Vilken sorteringsalgoritm sorterar strömmad spatio-temporal data i JSON-format med lägst responstid?”
Merge sort visade sig vara klart snabbast av de tre algoritmerna som testades. Experimentets faktorer hade ingen påverkan på resultatet. Den tredje och sista frågeställningen var:
”Hur stor är skillnaden i responstid när sorteringen sker på servern istället för på klienten?”
Genom analys av sorteringstiderna på klientapplikationen och serverapplikationen (Figur 31-33) kan man konstatera att skillnaden består av millisekunder i fallen för heap sort och tree sort. Merge sort visar tecken på att öka klyftan mellan klientapplikationen och serverapplikationen när strömmens storlek ökar. Vid 75MB strömstorlek är skillnaden över 1 sekund till fördel för klientapplikationen. Hypotesen att sortering på serverapplikationen resulterar i lägre sorteringstider än på klientapplikationen kan därmed ses som motbevisad när storleken på datan är 75MB eller mindre.
Cheema, Sarwar & Yousaf (2016) beskriver att en effektiv sorteringsalgoritm har låg tids- och minneskomplexitet. I det här experimentet mäts inte komplexitet, men nedanstående tabell har tagits fram för att representera sorteringsalgoritmernas resultat i testerna.
Tabell 3 Jämförelse av de tre sorteringsalgoritmernas resultat Merge sort Heap sort Tree sort
Minnesanvändning #3 #1 #2
Sorteringstid #1 #3 #2
Utifrån denna jämförelse är det svårt att säga vilken algoritm som är effektivast. Merge sort visade sig vara klart snabbast, men använde mest minne. Heap sort var långsammast men hade lägst minnesanvändning, och tree sort genererade resultat som varken var bäst eller sämst i något av testen.
Sammanfattningsvis kan ingen direkt slutsats dras för vilken algoritm som är effektivast på att sortera strömmad data i JSON format. De tre algoritmerna har olika styrkor och svagheter som gör det omöjligt att med klarhet säga att en är bättre en de andra. Om sorteringstid är den viktigaste variabeln för användningsområdet så är merge sort det bästa alternativet. Om å andra sidan minnesanvändningen är det viktigaste att ta hänsyn till är heap sort den algoritm som bör användas. Klientapplikationen presterade bättre i detta experiment, men serverapplikationen visade tecken på bättre resultat jämförelsevis när storleken på strömmen ökade, men denna studien kan inte bevisa det.
7
Avslutande diskussion
I det här kapitlet presenteras en sammanfattning och undersökningens resultat diskuteras för att ge en klar bild av arbetet. Etiska aspekter som arbetet berör samt framtida möjligheter att förbättra eller bygga vidare på arbetet kommer att diskuteras.
7.1 Sammanfattning
Spatio-temporal data är data med spatiala och temporala aspekter, vanligtvis förekommande i olika GPS system. Denna data är svårhanterlig i den mening att vanliga relationsdatabaser inte har stöd för uträkningar på spatio-temporala attribut. Strömmad data är data som genereras av exempelvis sensorer och skickas kontinuerligt över ett nätverk, vilket gör det svårt att hantera och bearbeta den inkommande datan som en helhet. Sortering av data är användbart för att förenkla sökning, lagring, och borttagning av data i en lista. Många sorteringsalgoritmer finns för just detta. Det problem som ligger som grund för det här arbetet är hur man effektivast kan sortera en ström av spatio-temporal data i JSON format.
Ett antal delmål togs fram för att strukturera arbetet, där det första var att välja ut lämpliga sorteringsalgoritmer. Merge sort, heap sort, och tree sort visade sig vara lämpade för strömmad data eftersom de under sorteringsprocessen håller en delvis sorterad lista, vilket innebär att hela datamängden inte behöver sorteras på en gång. Efter att sorteringsalgoritmerna valts ut byggdes artefakten upp. För att strömma data användes en websocketserver i node.js som skickade objekt från datasetet till en websocketklient. Två applikationer byggdes för att jämföra klientapplikationer och serverapplikationer, en JavaScript klient och en ASP.NET serverapplikation. Experimentet som utfördes hade plattformarna, storleken på den strömmade datan, och sorteringsalgoritmerna som faktorer. De variabler som mättes var sorteringstid och minnesanvändning. Varje algoritm mättes 500 gånger per plattform och strömstorlek.
Resultatet som uppstod från experimentet visade att merge sort var den snabbaste av de tre algoritmerna i alla testfall, men hade högst minnesanvändning. Heap sort använde minst minne men hade högst sorteringstid. Resultaten indikerar även att sorteringstider på klientapplikationen var lägre en de på serverapplikationen, vilket motbevisar hypotesen som framtogs i arbetet.
7.2 Diskussion
Resultatet av undersökningen utförd i det här arbetet visar på en viss avvikelse från komplexitetsteori. Alla tre algoritmer som har jämförts i studien har samma tidskomplexitet, men en klar skillnad uppstod i testfallen. Detta kan bero på algoritmernas implementation, och olika implementationer kan innebära olika resultat. Datamängden visade sig vara mer betydelsefull än förväntat för resultaten, då klyftorna mellan algoritmernas resultat i många fall ökade när storleken på strömmen växte. Heap sort och tree sort har en liknande struktur i det att de bygger på binära träd, medans merge sort inte strukturerar datan alls innan sorteringen sker. Cheema, Sarwar & Yousaf (2016) menar att en effektiv sorteringsalgoritm har låg tidskomplexitet samt minneskomplexitet, och kom i sin studie fram till att merge sort var ett effektivt val för stora dataset. Den här studien visar att merge sort var klart snabbast, men minnesanvändningen blev väldigt hög i takt med att strömmens storlek växte.
Le-Phuoc et al. (2011) nämnde i sin artikel att hantering av strömmad data är svårt och arbetsintensivt och kräver att utvecklaren skapar egna metoder för dess hantering. Detta stämde överrens med hur uppbyggnaden av artefakten i det här arbetet såg ut, då implementationen av sorteringsalgoritmerna behövdes anpassas för att ta emot strömmad data. Dessa egengjorda metoder kan ha haft direkt inverkan i hur algoritmerna presterade och därför ha påverkat resultatet. Det finns väldigt få vetenskapliga artiklar och studier som berör sortering av strömmad data, och någon standard eller allmänt accepterad praxis finns inte i dagläget.
Resultaten för sorteringstid kan antas som riktiga då konfidensintervallen var mycket låga, och metoden för insamlandet av datan var robust och likadan för båda applikationerna. Resultaten för minnesanvändning kan dock vara opålitliga, eftersom både JavaScript och ASP.NET använder sig av automatisk skräpinsamling och speciella metoder behövdes användas för att minimera mätfel i detta anseende. För serverapplikationen var minnesanvändningen väldigt hög jämfört med klientapplikationen, och ingen klar anledning har lyckats identifieras.
7.2.1 Etik
En av de etiska aspekter som nämns i kapitel 4 är konfidentialiteten i datan som används. GPS data består av bland annat koordinater och tidsstämpel (Rundle et al, 2016), något som kan användas för att spåra eller kartlägga en persons rörelser i ett tidsspann. Wohlin et al (2012) nämner att subjekt måste ge frivilligt medgivande att delta i undersökningen och att studien bör ha ett vetenskapligt värde när människor delar med sig av potentiellt känslig data. Den GPS data som har använts som grund för experimentet var helt simulerat, vilket innebär att ingen konfidentialitet har brytits eller medgivande behövts.
En annan etisk aspekt är arbetets återupprepbarhet. All kod som skrivits i det här arbetet har laddats upp till GitHub, och alla script för simulering och insamling av data återfinns i Appendix A – D. De tekniska specifikationer som hör till enheten arbetet utfördes på redovisas i tabell 1, kapitel 6. Wohlin et al (2012) menar att man bör kunna återskapa design och resultat av arbetet, och med denna information är det möjligt.
Sortering av data är mycket användbart och effektiviserar bland annat sökning i en lista (Yang, Yu & Gan, 2011). Den data som har använts för det här arbetet har varit simulerad GPS data, och innehåller därför ingen känslig information. Detta arbete innehåller dock teoretiska och praktiska exempel på hur äkta GPS-data skulle kunna strömmas och sorteras, vilket kan utnyttjas av illasinnade. Sortering är inte ett nytt koncept men i en tid då mängden data som produceras växer för varje dag som går är det sunt att ha i åtanke vilka samhälleliga risker som finns med de verktyg som annars kan tas för givet.
Den samhälleliga nyttan som detta arbete erbjuder är smal, men arbetet skulle kunna hjälpa utvecklare av webbapplikationer som hanterar strömmad data att välja en sorteringsalgoritm som passar dennes behov. I dagsläget är det alltmer viktigt att tänka på miljön och hur vi använder de resurser som finns. Detta arbete har fokus på effektivitet, och även om det endast rör sig om minimalt med resurser i praktiken i form av elförbrukning kan varje lite del vara till nytta i ett helhetsperspektiv.
7.3 Framtida arbete
Den här studien har jämför tre sorteringsalgoritmer och dess möjliga hantering av strömmad JSON-data. Det finns många olika sorteringsalgoritmer som skulle kunna anpassas för att hantera data, och många möjliga implementationer av dessa för att hantera strömmad data. Vid vidare arbete på studien hade man kunnat utvärdera fler algoritmer och implementationssätt, på så vis hade man kunnat få en klarare helhetsbild på vilken typ av sorteringsalgoritm som är bäst lämpad för strömmad data.
Kanske mest intressant vore att öka strömmens storlek mer och på så vis få fler mätpunkter och förhoppningsvis kunna urskilja mönster i algoritmernas prestanda när datamängden ökar. Tecken på olika utvecklingar i algoritmerna visade sig i den här studien, men på grund av det fåtal datamängdsstorlekar som jämfördes kunde ingen slutsats dras. De datamängdsstorlekar som jämfördes i studien var alla under 100MB, och det intressantaste tecknet på ett mönster visade sig under testerna på 75MB strömmad data.
Utöver algoritmerna och datamängden användes plattformarna som en faktor i experimentet. Studien använde en JavaScript-klient och en ASP.NET-server, men dessa är bara ett fåtal av de möjligheter som finns. En studie hade kunnat göras för olika serverapplikationer, och en annan hade kunnat jämföra olika klientapplikationer.
Ett större arbete som bygger vidare på detta arbetets grundidé skulle kunna utveckla en realtidsapplikation som tar emot faktisk GPS-data i en ström och sorterar den data som tagits emot för att visualisera något mönster i applikationen. En annan idé hade varit att bygga in en karta i applikationen som uppdateras med GPS-punkter beroende på förbestämda variabler, som till exempel mellan vilka GPS-punkter som hastigheten var över 100km/h.
