Datamigratie-algoritme voor op- slagservers van zorginstellingen

(1)

Bachelor Informatica

Datamigratie-algoritme voor

op-slagservers van

zorginstellin-gen

Abdel-Jaouad Aberkane

8 juni 2016

Supervisor(s): Jurgen Deege (ChipSoft)

Inf

orma

tica

—

Universiteit

v

an

Ams

terd

am

(2)

(3)

Samenvatting

De hoeveelheid mediadata binnen zorginstellingen stijgt enorm en daardoor is de behoefte ontstaan om efficiënt om te gaan met de opslagservers van deze zorginstellingen. In dit onderzoek wordt een efficiënt data-algoritme gepresenteerd in opdracht van ChipSoft. Het algoritme beschrijft een methode om data te migreren binnen een tiered storage structuur. Het doel is om een optimum te vinden tussen het vergroten van de efficiëntie en het verlagen van de kosten van het opslagsysteem. De data wordt binnen het algoritme onderworpen aan een aantal tests met als doel de data te classificeren in hot en cold data. De hot data wordt gemigreerd naar de toplaag van de tiered storage, de cold data wordt naar de overige lagen gemigreerd. De resultaten geven aan dat het algoritme een sterke winst behaald op het gebied van het verlagen van de gemiddelde leestijd van een mediabestand. Het algoritme bewijst efficiënter te zijn dan de huidige implementatie binnen zorginstellingen verbonden aan ChipSoft.

(4)

(5)

Inhoudsopgave

1 Inleiding 7

1.1 Inleiding . . . 7

1.2 Over dit project . . . 8

1.2.1 Onderzoeksvraag . . . 9 2 Probleemanalyse 11 2.1 Kosten . . . 11 2.2 Effici¨entie . . . 12 2.3 Het doel . . . 12 3 Aanpak 15 3.1 Model . . . 15 3.1.1 Dataset . . . 15 4 Algoritme 19 4.1 Stappen . . . 19 4.1.1 Pad vaststellen . . . 19

4.1.2 Lagen en de bijbehorende dossiers . . . 20

4.1.3 Policy . . . 20 4.1.4 Doelpercentage . . . 21 4.2 Tricks en optimalisaties . . . 22 4.3 Aannames . . . 22 5 Metingen en resultaten 25 5.1 Meting I . . . 25 5.1.1 Opstelling 1 . . . 26 5.1.2 Opstelling 2 . . . 28 5.1.3 Opstelling 3 . . . 31 5.1.4 Opstelling 4 . . . 33 5.2 Meting II . . . 36 6 Conclusie 39 6.1 Conclusie . . . 39 6.2 Toekomstig onderzoek . . . 40

(6)

(7)

HOOFDSTUK 1

Inleiding

1.1 Inleiding

De digitalisering van zorginstellingen in Nederland neemt grote vormen aan. Het Academisch Medisch Centrum, ´e´en van de grootste ziekenhuizen in Nederland, kreeg in 2014 bijvoorbeeld, een dotatie van 4,4 miljoen euro bestemd voor groot onderhoud van de ICT afdeling. Het bedrag was voornamelijk bestemd voor het aanleggen van een data storage netwerk volgens het jaarver-slag van 2014, ”ter modernisering van de communicatie infrastructuur”[3]. Dit tekent de groei van de hoeveelheid opgeslagen data en de mate van belangrijkheid van dit onderwerp binnen ziekenhuizen.

E´en van de redenen van dit verschijnsel is de grote hoeveelheid data die tegenwoordig wordt opgeslagen. Van verwijsbrieven tot aan echo’s, alles wordt opgeslagen op de storage servers. Een andere reden is de ontwikkeling in de technologie op het gebied van het vastleggen van beelden. De resoluties van bijvoorbeeld camera’s worden steeds beter en deze verbetering gaat vaak gepaard met een grotere bestandsgrootte. Volgens een intern onderzoek van het adviseursbedrijf M&I [11], uitgevoerd bij enkele ziekenhuizen in Nederland, is meer dan de helft van de opslag in gebruik door beeldinformatie. “Het overgrote deel van de storagecapaciteit wordt in beslag genomen door beelddata, beeldinformatie die wordt beheerd door het PACS1_{, inclusief archief. Gewoonlijk is}

dit zo tussen de 50% en 65% van de gebruikte storagecapaciteit.”Hieruit valt af te leiden dat storage servers een significante rol spelen met het oog op de functionaliteiten binnen ziekenhuizen.

Figuur 1.1: Schematische weergave van de lagen van een tiered storage.

Binnen ziekenhuizen bestaan de storage servers dikwijls uit zo-genaamde storage tiers. Een tiered storage is een opslagsysteem waarbij de storage fysiek wordt verdeeld over verschillende parti-ties, volgens de definitie van SNIA2 _{dictionary. Die verdeling}

ge-beurt voornamelijk op basis van de kosten en performance van een server. Gebruikelijk bestaat een tiered storage uit drie lagen, zoals weergegeven is in figuur 1.1. De bovenste laag van een tiered stor-age bestaat uit een schijf met een hoge performance, tegenwoordig steeds vaker in de vorm van een Solid State Drive (SSD) [1]. Deze laag is traditioneel het duurst binnen de tiered storage en wordt voornamelijk gebruikt voor de opslag van zogenaamde hot data, data die regelmatig geraadpleegd wordt. Binnen de context van ziekenhuizen, valt er voor te stellen dat de leestijd van bepaalde fi-les op bepaalde tijdstippen heel laag moet zijn. Neem bijvoorbeeld een chirurg, die tijdens een consult van een pati¨ent het dossier van

1_{Picture Archiving and Communication System, is een beeldverwerkingssysteem dat de omgang met medische}

beelden door medisch specialisten vergemakkelijkt.

2_{Storage Networking Industry Association, een instelling die jaarlijks een woordenboek uitbrengt waarin vooral}

(8)

de betreffende pati¨ent tevoorschijn wil halen. Met een schuin oog gericht naar het uurloon van de chirurg, is het niet onlogisch dat een ziekenhuis in dit geval wil dat het betreffende dossier zich op de bovenste laag bevindt: de laag met de snelste leestijd. Dit in tegenstelling tot een dossier waar een geruime tijd niet meer om is gevraagd. In deze situatie is het juist zaak om het dossier zo goedkoop mogelijk op te bergen. De voornaamste plek om dit te doen is de laatste laag. De laatste laag is vaak een Hard Disk Drive (HDD), de kracht van deze laag ligt niet bij de performance, maar bij de opslagcapaciteit en de lage kosten per gigabyte. Deze laag wordt voornamelijk gebruikt voor data die zelden wordt opgevraagd, zogenaamde cold data. Ook de middelste laag is vrijwel altijd een HDD. Evenals laag 1, beschikt laag 2 ook over een hoge per-formance, doch niet van dezelfde orde als de eerste laag. Op de middelste laag worden zowel hot als cold data opgeborgen. Het moge duidelijk zijn dat er veel bij komt kijken bij het beheren van zo een storage.

1.2 Over dit project

In dit verslag wordt een strategie gepresenteerd waarbij het doel is om zo effici¨ent mogelijk om te gaan met de opslag van een zorginstelling. Deze strategie is bedacht en ge¨ımplementeerd in opdracht van ChipSoft. ChipSoft is een software bedrijf dat gespecialiseerd is op het gebied van ziekenhuis-informatiesystemen. Het bedrijf ontwikkelt innovatieve software voor de zorgsector in zowel het binnen- als buitenland. ChipSoft is de grootste ZIS/EPD-leverancier van Nederland en heeft steeds vaker te maken met mediadata binnen pati¨entendossiers. Ook ChipSoft heeft dus te maken met de groei3 van de hoeveelheid data die wordt opgeslagen.

Huidige implementatie

Binnen de zorginstellingen die met ChipSoft zijn verbonden, wordt momenteel alle mediadata per tijdseenheid gestructureerd opgeslagen op de verschillende servers. In een poging de struc-tuur wat begrijpelijker te maken voor de leek, volgt er een korte metaforische vergelijking over de omgang met data binnen de huidige implementatie.

Allegorie van Alhazen

We gaan hiervoor terug naar een rustige zomer in middeleeuws Bagdad, naar het Huis der Wijs-heid om precies te zijn. Het Huis is de gehele zomer leeg, op twee personen na. De intellectueel Alhazen en zijn luie assistent. Alhazen gaat zijn kamer nooit uit en is druk bezig met het oplossen van het probleem van Alhazen. Elke dag komen er tientallen brieven binnen voor Alhazen. De afzenders vari¨eren enorm: de ene brief komt van een simpele boer, de andere komt van de groot-vizier. Al deze brieven worden afgehandeld door zijn assistent. De assistent moet deze brieven sorteren in drie bakken: een kleine gouden bak, een grotere zilveren bak en een nog grotere koperen bak. Alle drie de bakken worden geraadpleegd door Alhazen wanneer hij tijd heeft. De gouden bak wordt het snelst geraadpleegd door Alhazen, waar hij als part-time alchemist een voorliefde heeft voor alles wat goud is. De zilveren bak wordt minder snel geraadpleegd en de koperen bak zelfs nog minder dan de zilveren. Het vullen van de bakken heeft echter ook een bijwerkingen, de enveloppen zijn van slechte kwaliteit en maken de bakken snel vies. De gouden bak wordt het snelst vies, de zilveren iets minder en de koperen bak wordt het minst snel vies. Elke keer als de bak vies is wordt er een schoonmaker ingehuurd die betaald wordt naar mate van de hoeveelheid werk die hij moet verrichten. De onderhoudskosten van een bak is dus evenredig met de mate van vuilheid. De brieven moeten gesorteerd worden op basis van enkele regels, van te voren opgesteld door Alhazen. De belangrijkste regel is: “niet storen als ik aan het werk ben”. De luie assistent gaat aan de slag en in al zijn laksheid besluit hij om de enveloppen niet te openen en slechts de afzender af te lezen. Alle brieven worden in de gouden bak gegooid en indien deze vol is verplaatst hij de gehele inhoud naar de zilveren bak. Indien deze ook vol is wordt de inhoud van de zilveren bak overgeplaatst naar de koperen bak. Na enkele dagen krijgt Alhazen onverwachts bezoek. Op een rustige middag klinkt er op eens luid gebons op de voordeur. Zijn boze moeder. Alhazen snelt naar de deur en laat haar binnen. Hij is de bruiloft van zijn zus vergeten, luidt de

(9)

uitleg van zijn moeder. Diep teleurgesteld verlaat ze het Huis. Na alle commotie zit Alhazen later op de avond weer achter zijn bureau en probeert hij de gebeurtenissen te analyseren. Hij komt tot de ontdekking dat er een brief van zijn moeder midden in de pak brieven uit de zilveren bak ligt. Het is de uitnodiging voor de bruiloft. Ook krijgt hij dezelfde avond de rekening gepresenteerd van de schoonmaker. Alhazen komt tot de conclusie dat hij nieuwe regels moet opstellen voor de omgang met de brieven ten behoeve van effici¨entie en de hoge kosten. Hij stelt een manuscript op met de volgende punten: alleen de brieven waarvan de afzender binnenkort een antwoord ver-wacht komen in de gouden bak. Brieven die nog lang niet beantwoord hoeven te worden komen terecht in de overige bakken. De assistent moet voortaan de brieven openmaken en de inleiding lezen. De assistent krijgt naast een reprimande ook het manuscript met de nieuwe regels van Alhazen.

Het probleem dat ontstond bij het sorteren, kwam vooral door de oppervlakkige omgang met de brieven door de assistent. De assistent borg de brieven op basis van tijd op. Een dimensie in de diepte van de brieven waardoor er belangrijke kenmerken uit de brieven gehaald kon worden ontbrak. Alhazen probeert met zijn nieuwe manier de assistent wat bewuster om te laten gaan met de bakken en hun waardes. De assistent is lui en zal dus nooit uit zichzelf een brief openen. Het manuscript met de regels moet daarom goed gedefinieerd zijn. Zo ook binnen de huidige implementatie van ChipSoft. Het opslagsysteem moet fijnmaziger te werk gaan en waarde hech-ten aan de kenmerken van de verschillende bestanden. Op basis van deze kenmerken kan beslist worden waar een bestand terecht komt. Een bestand kan namelijk pas over een halfjaar nodig zijn. Is het dan noodzakelijk om het bestand op de snelste storage laag te laten zitten? Het doel van dit onderzoek is om een oplossing te bedenken waarbij het gebruik van de storage servers op een efficiënte manier gebeurt. Een plausibele gedachtegang is dat, indien deze kenmerken mee worden genomen in de afweging om een databestand ergens te plaatsen, het storage systeem als geheel efficiënter wordt. De precieze definitie van efficiëntie wordt later in de Analyse sectie toegelicht.

1.2.1 Onderzoeksvraag

Het onderzoek dat wordt beschreven in deze scriptie is een simulatie van een algoritme dat er voor zorgt dat de omgang van de opslagservers binnen een zorginstelling veel efficiënter gaat dan bij de huidige implementatie. Het algoritme migreert mediadata over en weer tussen de lagen van de storage, op de juiste momenten. Het doel is om op zo een manier te schuiven met de data, dat het geheel kostenbesparend en efficiënter wordt in vergelijking met de huidige implementatie. Eén van de vragen die hieruit vloeit is, vallen de kosten van het systeem, na de werking van het algoritme, goedkoper uit dan bij de huidige implementatie? Een andere vraag is, wat voor invloed heeft het algoritme op de leestijd4 van hot data. Deze vragen vormen samen de hoofdvraag, namelijk, is de implementatie van een geautomatiseerd mediadata migratie-algoritme daadwerkelijk efficiënter5 dan de huidige implementatie? Een ander doel dat gerealiseerd moet worden is het reserveren van een percentage van de opslag van de toplaag. Dit gedeelte moet gereserveerd worden voor de dagelijkse productie van de mediaproducerende afdelingen binnen een zorginstelling.

4_{Binnen dit onderzoek wordt de performance van het storagesysteem uitgedrukt in leestijd per megabyte.} 5_Effici¨_{enter op het gebied van kostenbesparing en leestijd verlaging van de hot data.}

(10)

(11)

HOOFDSTUK 2

Probleemanalyse

Organisaties denken tegenwoordig steeds vaker na over het gebruik van effici¨ente storage archi-veringstechnieken, waar getracht wordt de meest kost-effectieve oplossing te vinden. De lagen waar data op wordt bewaard, hebben elk een eigen kostenpatroon en performance. Het doel is om een optimum te vinden tussen de minimalisatie van de kosten en de maximalisatie op het gebied van performance. Dit optimum hoeft echter niet het resultaat te zijn waar zorgin-stellingen op zitten te wachten. Het is namelijk niet onlogisch dat zorginzorgin-stellingen kiezen voor een goedkopere opstelling. Het verlies in performance weegt vaak niet zo zwaar als de winst in kostenverlaging. Elke instelling maakt afwegingen, die resulteren in de beste keuze voor de betreffende instelling. De beste oplossing is in dit geval dus relatief aan de wensen van de instelling in kwestie. In de volgende alinea’s volgt er een abstracte analyse van het probleem.

Figuur 2.1: Schematische weergave van de lagen van een tiered storage met een beeld van de kosten.

Een storage systeem bestaat uit verschillende lagen, een wille-keurige laag noemen we Si. De lagen zijn serieel met elkaar

verbon-den op toenemende volgorde van i, met i = (0, 1, 2, . . . , n) en n ∈ Z+. Elke laag Siheeft een bepaalde performance Pi, ook hier geldt

i = (0, 1, 2, . . . , n) en n ∈ Z+_{. Voor elke laag S}

imoet ook een

be-drag gereserveerd worden om de kosten Ki te bekostigen. Dezelfde

regels als bij de lagen en performance gelden, namelijk i = (0, 1, 2, . . . , n) en n ∈ Z+_{. De bovenste laag is de snelste laag, vaak een}

Solid State Drive. De opvolgende lagen zijn vaak Hard Drive Disks met zowel afnemende kosten als afnemende performance. Als er wordt uitgaan van de gangbare opstelling die geschetst wordt door Gong Zhang et al. [1], kan er aangenomen worden dat P0>P1>P2

>. . . >Pn. Immers, een Solid State Drive overtreft een Hard Disk

Drive op het gebied van performance [6].

2.1 Kosten

De stelregel op het gebied van kosten van een storage laag is, hoe beter de performance per gigabyte, hoe duurder de laag (afgeleid van de thumb-rule van Linda Null et al. [13]). Een Solid State Drive is in het algemeen duurder per gigabyte dan een Hard Disk Drive [6]. Als ervan uit wordt gegaan dat de verschillen in kosten tussen de Hard Disk Drives dezelfde stelregel als grondslag hebben, kan ook hier aangenomen worden dat K0>K1 >K2>. . . >Kn. De vraag die

hier oprijst is, waar hangen de kosten precies van af?

Bij het berekenen van de kosten voor een storage laag, wordt er rekening gehouden met verschillende aspecten van de storage server. Een essentieel punt dat in ogenschouw moet worden genomen, is hoe snel de opgeslagen data nodig is. Indien het niet uitmaakt wat de leestijd is van een mediabestand, is de oplossing simpel en kunnen alle mediabestanden op de goedkoopste

(12)

laag geplaatst worden. Dit is de goedkoopste en tevens de meest langzame oplossing. Binnen zorginstellingen speelt performance wel degelijk een rol. Mediabestanden en dossiers moeten snel toegankelijk zijn. De tijd van de medisch specialisten die deze bestanden raadplegen is kostbaar [12] en een latency van enkele minuten per uur, neemt aan het eind van de dag significante vormen aan in de vorm van extra kosten. Dit is niet wenselijk binnen deze (vaak non-profit) instellingen. De kosten zijn dus te classificeren in twee groepen. Namelijk, de kosten die worden gegenereerd op basis van type storage en de kosten die worden gecre¨eerd door een hoge latency. De keuzes die gemaakt kunnen worden op het gebied van kosten lijken op het eerste gezicht contradictoir, immers je kan:

1. kiezen voor een trage, maar goedkope storage laag;

2. kiezen voor een snelle, maar duurdere storage laag.

Binnen de huidige implementatie kan een mediabestand in principe worden opgehaald vanuit elke laag. Dit zorgt voor een onnodige latency indien het bestand niet bewaard is op de toplaag. Deze latency kan eventueel resulteren in kosten, zoals aangekaart in de vorige alinea. Echter, met een simpel pre-fetching mechanisme kan er bijvoorbeeld voor gezorgd worden dat alle benodigde bestanden op het juiste moment op de snelste laag staan.

Wat getracht wordt te realiseren binnen dit onderzoek is in feite een combinatie van de eer-dergenoemde opsomming. Een goede performance is nodig om de kosten te drukken, bestanden die worden opgevraagd moeten altijd op de snelste laag gevonden worden. Een goedkope storage laag kan gebruikt worden voor de bestanden die niet per direct nodig zijn. Dit is in principe het grondbeginsel van een tiered storage, zoals ook aangereikt door IBM in een oplossing voor het archiveren binnen de zorg [10]. Op basis van enkele regels kunnen de mediabestanden geclassifi-ceerd worden. Vervolgens kan de toewijzing naar een van de lagen plaatsvinden. Overigens kan het uitvoeren van het algoritme op de servers ten tijde van een hoge workload ook resulteren in latency en dus ook kosten. Binnen dit onderzoek laten we dit punt buiten beschouwing, we gaan er vanuit dat de oplossing eenmaal daags wordt uitgevoerd op een moment waar de workload van het systeem dusdanig laag is dat het valt te verwaarlozen (bijvoorbeeld midden in de nacht). In sectie 6.2 van de conclusie wordt hier verder op ingegaan.

2.2 Effici¨

entie

Efficiëntie kan op verschillende manieren worden uitgedrukt en worden bereikt. In de vorige ali-nea is kosten-efficiëntie besproken en in deze alinea (en in de rest van de thesis) wordt efficiëntie met betrekking tot performance uitgedrukt in leestijd per megabyte1. De leestijd wordt gede-finieerd in de tijd die het systeem nodig heeft om één megabyte aan data te op te halen. Hier is voor gekozen vanwege de mogelijkheden om bijvoorbeeld de dokterskosten te berekenen aan de hand van de tijd waarin hij of zij wacht op het bestand2_{. Een effici¨}_{ent opslagsysteem kan, in}

deze zin, worden bereikt door het minimaliseren van de gemiddelde leestijd van een datafile dat aangevraagd wordt. Hoe sneller dit bestand aangeroepen en aangereikt kan worden, hoe sneller er begonnen kan worden met andere taken en hoe effici¨enter het systeem is. De hoogst mogelijke leestijd, is de leestijd van de bestanden op de laagste storage, zie figuur 1.1. Dit is dan ook de leestijd bottleneck. Zo ook in de huidige opstelling van ChipSoft. De ultieme oplossing is alle lagen voorzien van Solid State Drives, echter is dit een utopie. Deze oplossing zal voor de ruime meerderheid van de instellingen te duur zijn.

2.3 Het doel

Het doel dat binnen dit onderzoek is geprobeerd te realiseren is het vinden van een ideale opstel-ling, waarbij zowel de kosten als de leestijd van de bestanden zo laag mogelijk liggen. Ook moet

1_{Wordt in het vervolg afgekort tot leestijd.}

(13)

een bepaald percentage van de snelste laag gereserveerd zijn voor de dagelijkse productie. Dit alles moet worden bewerkstelligd met behulp van een effici¨ent data-migratie algoritme. Kosten moeten worden geminimaliseerd en de performance moet worden gemaximaliseerd:

min(X i Ki) en max( X i Pi)

Om een zo laag mogelijke leestijd te verkrijgen is het nodig de bottleneck van de meest langzame servers te doen verdwijnen: alle data aanvragen moeten worden gedaan op de snelste laag. Met behulp van het eerder genoemde pre-fetching oplossing kan alle hot data op tijd, verplaatst worden naar de bovenste laag. Op deze manier is de leestijd, op het moment dat het er toe doet, het laagst. De storage kosten kunnen worden verlaagd door de cold data zo veel mogelijk op een goedkope laag te bewaren. Voor deze oplossing moet er wel een duidelijke classificatie komen van hot- en cold data. In de volgende twee hoofdstukken wordt duidelijk hoe dit wordt aangepakt.

(14)

(15)

HOOFDSTUK 3

Aanpak

Samen met ChipSoft is besloten om het onderzoek uit te voeren middels een simulatie van het algoritme. De reden waarom er gekozen is voor een simulatie en niet voor een directe implementatie in de huidige infrastructuur van ChipSoft, ligt aan het korte tijdsbestek waarin dit onderzoek moet worden afgerond. Het inlezen en begrijpen van de ChipSoft infrastructuur vergt enige tijd. Bovendien biedt een simulatie enkele belangrijke voordelen. Bijvoorbeeld bij het demonstreren van de werking van het systeem aan klanten, in het geval van ChipSoft. De interpretatie van een simulatie is namelijk niet gebonden aan mathematische- of computerkennis, aldus Chung et al. [8]. Daarnaast zijn de modellen vaak makkelijk weer te geven. De aanpak die is gehanteerd, is gebaseerd op de methode beschreven door Anderson et al. [4]. Als eerst wordt er vormgegeven aan een model waarin het algoritme uiteindelijk op wordt los gelaten. Vervolgens wordt het algoritme vormgegeven, met het vorige hoofdstuk als grondslag. Het geheel wordt geprogrammeerd binnen Visual Studio 20101 _{en 2015}2_{, in de programmeertaal C#. Er is}

gekozen voor deze middelen, omdat dit de norm is binnen ChipSoft.

3.1 Model

Figuur 3.1: Weergave map-penstructuur van de storage center

Het model dat is gecre¨eerd is een vereenvoudigde voorstellingswijze van een opslagserver met verschillende lagen in de vorm van een mappenstructuur. Er is gekozen voor deze manier omdat het sim-pel te cre¨eren is en ook makkelijk weer te geven is met behulp van de Windows verkenner. Het opslagsysteem an sich doet dienst als de root map, binnen deze map zijn de verschillende lagen, zoals weergegeven in figuur 1.1, als submappen, zie figuur 3.1. De lagen bestaan uit storage0, storage1 en storage2. Storage0 fungeert als de snelste en duurste laag in het geheel. Storage1 is iets minder snel, maar wel goedkoper. Storage2 is het minst snel en de goedkoopste laag. Op deze lagen worden dossiers en bijbehorende mediabestan-den opgeslagen. Het opslaan begint op storage0, indien deze vol zit, wordt er overgeschakeld op storage1. Mits hier ook geen plek meer is, wordt er overgeschakeld naar storage2. Overigens worden ook enkele aannames gedaan bij de creatie van dit model, deze worden toegelicht in het hoofdstuk Algoritme.

3.1.1 Dataset

De storage moet uiteraard gevuld worden met data. Binnen de simulatie worden dossiers en mediadata aangemaakt met behulp van het GenerateData programma. Het GenerateData

pro-1_{Microsoft Visual Studio 2010, Premium edition.} 2_{Microsoft Visual Studio 2015, Community edition.}

(16)

gramma genereert een synthetische dataset. Er is gekozen voor een synthetische dataset, omdat deze makkelijk en snel aan te maken is. Bovendien kunnen de verhoudingen (hoe vaak komt een type bestand voor) eenvoudig worden aangepast. Het GenerateData programma verwacht 4 argumenten. Namelijk, het aantal dossiers n die aangemaakt moeten worden en de groottes van de drie servers die worden aangemaakt. In de Windows Command Prompt ziet het aanroepen naar het programma er als volgt uit:

GenerateData . e x e <NumberOfRecords> <S i z e S t o r a g e 0 > <S i z e S t o r a g e 1 >

,→ <S i z e S t o r a g e 2 >

Met behulp van deze argumenten worden de eerdergenoemde lagen gevuld met dossiers en mediabestanden. GenerateData neemt de verhoudingen van een niet nader te noemen ziekenhuis3 als voorbeeld. Dit document bestaat voornamelijk uit productiecijfers. Deze cijfers geven weer hoeveel een bepaalde afdeling binnen het ziekenhuis aan mediabestanden heeft geproduceerd, op jaar basis. Hieruit zijn verhoudingen met behulp van een cumulatieve relatieve frequentie verdeling ge¨extraheerd. Uit dit document worden ook de afdelingen bepaald en de gereedschap-pen die worden gebruikt voor de diagnostiek binnen de betreffende afdeling. Dit document is hervormd tot een tweedimensionale array met cijfers. Aan deze array is ook een rij toege-voegd waarin de groottes van de bestanden staan per onderzoek. In figuur 3.2 is een sample te zien van de omgevormde dataset. De eerste rij geeft de cumulatieve relatieve frequentie weer van de afdelingen. Op basis van deze rij wordt voor elk nieuw dossier bepaald uit welke af-deling het afkomstig is. De rij die daarop volgt geeft een index aan van de type bestand. In GenerateData is een array opgesteld met de voorkomende typen bestanden: bijvoorbeeld wa-veform, pdf of handgeschreven documenten. De index correspondeert met deze lijst. De derde rij, vanaf links, is ook een index, ditmaal voor de gebruikte tool. Ook hiervoor is in Genera-teData een lijst opgesteld met de voorkomende diagnostische tools, bijvoorbeeld een ECG, een longfunctie of een cystoscopie. De een-na-laatste rij doet dienst als index voor een correspon-derende array in het GenerateData programma die de afdelingen definieert. De laatste rij geeft de groottes van de bestanden gekoppeld aan de eerste rij: de relatieve cumulatieve verdeling.

Figuur 3.2: Sample van de omgevormde dataset

Elke afdeling binnen een ziekenhuis heeft haar eigen pati¨enten met aandoeningen die binnen het expertisegebied van de af-deling vallen. Dit zorgt voor een afdelingsspecifieke onder-zoeken. Van een cystoscopie binnen de urologie afdeling tot aan een tandfilm binnen de kaakchirurgie. Elk onderzoek ge-nereert vaak een kenmerkend type bestand met een bepaalde grootte. De grootte van deze bestanden zijn later handmatig aan de array in figuur 3.2 (laatste rij) toegevoegd. De groot-tes van de bestanden zijn gebaseerd op basis van een demo da-tabase met geanonimiseerde mediabestanden, aangeleverd door ChipSoft.

Figuur 3.3: Mappenstructuur binnen een opslaglaag

GenerateData creëert voor elk dossier een mediabestand. Rea-listisch gezien, hoeft een patiënt namelijk geen verleden bij een zie-kenhuis te hebben. In principe kan een dossier aangemaakt worden zonder enige mediabestanden. Ook kan het zo zijn dat er meer-dere mediabestanden zijn per patiënt. Een patiënt is per slot van rekening niet altijd gebonden aan slechts één mankement. Binnen dit onderzoek is hiervoor gekozen, omdat dit sufficiënt is voor het onderzoek. Binnen het algoritme, dat zal later blijken, wordt na-melijk een dossier samen met het bijbehorende mediabestand als één geheel verplaatst. Dus maakt het binnen dit onderzoek verder niet uit hoeveel mediabestanden er zijn per dossier. In subsectie 4.3 wordt hier verder over uitgeweid.

(17)

Dossiers en media

Binnen de simulatie omgeving staat een dossier gelijk aan een plain-text tekstbestand. Gekozen is voor tekstbestanden, omdat deze eenvoudig uit te lezen zijn en weinig ruimte in beslag nemen, hoogstens enkele kilobytes. Dit tekstbestand bestaat uit enkele kenmerken die overeenkomen met een echt pati¨entendossier. De classificatie van de dossiers wordt gedaan op basis van deze kenmerken. Elk dossier is verbonden aan een afdeling, die is bepaald door middel van de verhou-ding van het ziekenhuis document. Ook wordt het diagnostische gereedschap bijgehouden. Dit is op het moment overigens slechts voor de vorm, concreet wordt hier (nog) niets mee gedaan. De belangrijkste kenmerken die worden meegegeven zijn:

1. Next appointment;

2. Last appointment;

3. Type bestand (geeft aan wat voor type het bestand in de realiteit gehad zou hebben, bijvoor-beeld waveform);

4. Tool (geeft aan met behulp van welke tool dit bestand gerealiseerd is);

5. Size (combinatie van de dossiergrootte + bijbehorende mediagrootte);

6. Locatie (in welke directory is het dossier opgeslagen);

7. Datum verplaatst (geeft indicatie hoelang het bestand onaangeroerd is).

De dossiers worden aangemaakt en vervolgens bewaard in de dossiers map. De mediabe-standen worden ingedeeld in de map van de corresponderende afdeling, zoals weergegeven in figuur 3.3. Evenals de dossiers, doen ook in dit geval tekstbestanden functie als mediabestan-den. De mediabestanden bezitten grotendeels dezelfde kenmerken als het bijbehorende dossier, zie de opsomming hierboven. De grote verschillen zijn voornamelijk te vinden in het pad van opslag en de naam van het bestand. De dossiers en mediabestanden, zijn zoals bovengenoemd, op verschillende plekken opgeslagen. De namen van elk bestaan uit verschillende variabelen. Zo bestaat de dossiernaam uit een combinatie van het dossiernummer, die telkens ge¨ıncrement wordt om er voor te zorgen dat elke bestandsnaam uniek is, opgevolgd door een liggend streepje en de afdelingsnaam erachter. Een voorbeeld van een dossier afkomstig uit de Intensive Care is 001 IC.txt. De naam van een mediabestand bestaat uit het dossiernummer, de naam van de afdeling en het type bestand. Een voorbeeld van een dossier afkomstig uit de gynaecologie afdeling is 002 gyn waveform.txt.

(18)

(19)

HOOFDSTUK 4

Algoritme

In dit hoofdstuk wordt een stapsgewijze iteratieve oplossing voor het probleem gepresenteerd, volgens de principes van Al-Khwarizmi1 _{[16]. Het geheel vormt een simpel algoritme, waarmee}

mediabestanden, en data in het algemeen, geclassificeerd worden en eventueel verplaatst. In feite zorgt dit algoritme voor een distributie van de inhoud van de storage lagen, een her-distributie, omdat het algoritme pas in actie komt nadat de lagen al gevuld zijn met data door de dagelijkse productie. In sectie 4.3 wordt dit verder toegelicht. Een belangrijke aanname is dat het algoritme eenmaal daags uitgevoerd wordt, binnen een tijdsbestek waarin de work-load van het systeem het laagst is. Het algoritme is een zogenaamde pre fetch algoritme waarbij gekeken wordt of bestanden binnen afzienbare tijd nodig zijn, in dit geval worden deze bestanden verplaatst naar de toplaag. De latency die veroorzaakt wordt door de lagere servers, wordt op deze manier verlaagd. De leestijd van een bestand wordt zo steeds meer en meer bepaald door de toplaag. Of het bestand wel of niet nodig is hangt af van de kenmerken van het bestand, daar wordt later op teruggekomen. Het programma dat de onderstaand beschreven functionaliteiten heeft is het Algorithm programma. Dit programma werkt specifiek op de mappenstructuur die wordt gecre¨eerd door het GenerateData programma. Als argument moet slechts de grootte van de toplaag in megabytes meegegeven worden. Het programma wordt als volgt aangeroepen:

A l g o r i t h m . e x e <S i z e S t o r a g e 0 >

Het algoritme begint met het bepalen van het te bewandelen pad.

4.1 Stappen

4.1.1 Pad vaststellen

Figuur 4.1: Voorbeeld van een pad binnen het algoritme.

De eerste stap van het algoritme is het pad vaststellen dat bewandeld moet worden. Het algoritme werkt in principe ´

eén afdeling af per executie. In principe, want indien het om één of andere reden niet gelukt is om een van tevoren aangegeven doelpercentage2_{te reserveren op de snelste laag,}

dan wordt er overgeschakeld naar de volgende afdeling in het pad. Ook hier geldt hetzelfde, indien het niet lukt om het percentage te reserveren, wordt er overgeschakeld naar de volgende afdeling. Tot dat het wel lukt. Het kan natuur-lijk ook zo zijn dat het percentage helemaal niet bereikt kan worden, dit hangt sterk af van de vooraf aangegeven waar-den voor het doelpercentage en de grootte van de eerste laag.

1_{Vaak verlatiniseerd tot Algoritmi, Perzische wiskundige uit de 9e eeuw en pionier op het gebied van}

metho-dische oplossingen.

(20)

Bijvoorbeeld als het doelpercentage heel hoog wordt gedefinieerd of als de grootte van de eerste laag slechts enkele megabytes bedraagt.

Het pad wordt gerandomiseerd middels de Fisher-Yates shuffle [7]. Gekozen is voor een random pad, met het doel de belasting van het systeem zo eerlijk mogelijk te houden. Als bijvoorbeeld elke maandag3_{de Intensive Care afdeling aan de beurt is, met hele zware data, dan}

zorgt dat consequent voor een zwaardere workload op het systeem op elke maandag. Overbelaste servers zorgen vaak voor een lage performance, volgens Singh et al. [14]. Dit wordt met een willekeurig pad tegengegaan. Als het pad bekend is, zoals geschetst in figuur 4.1, dan wordt de eerste afdeling benaderd.

4.1.2 Lagen en de bijbehorende dossiers

Binnen de eerste afdeling worden enkele iteratieve instructies uitgevoerd. Elke laag van de stor-age center wordt één voor één afgewerkt door het algoritme. Elke laag bestaat uit de mappen zoals weergegeven is in figuur 3.3. Binnen elke laag moeten enkele, hieronder beschreven, ite-raties uitgevoerd worden. De eerste handeling is zoeken naar de dossiers directory. Binnen de dossier directory wordt elke dossier van de afdeling, zoals bepaald in de vorige alinea, benaderd. De handelingen die in de volgende alinea’s beschreven zijn, worden uitgevoerd binnen elke laag.

Figuur 4.2: Handelingen die elk dossier uitvoert

Elke laag bestaat uit de mappen zoals weergegeven in figuur 3.3. Binnen de dossiers directory worden alle dossiers afgelopen die gebonden zijn aan de afdeling van het huidige pad. Elk dossier wordt onderworpen aan een aantal tests. Deze tests vormen de policy van het algoritme. Op basis van de resulta-ten van deze tests, wordt een afweging gemaakt of het dossier verplaatst moet worden of niet. In figuur 4.2 is schematisch weergegeven hoe elk dossier door de tests heenloopt.

4.1.3 Policy

De tests kunnen worden gecategoriseerd in drie groepen, name-lijk tests die te maken hebben met effici¨entie, met kosten of met de weten regelgeving van Nederland. Op basis van deze tests worden de data ingedeeld in enkele categorie¨en [9], namelijk:

• bestanden die binnenkort nodig zijn;

• bestanden die later dan het voorgaande punt nodig zijn, maar wel binnen een bekend tijdspanne;

• bestanden waarvan niet bekend is of ze nodig zijn. Elke test heeft een onderliggende regel. Indien aan deze regel wordt voldaan dan is de test geslaagd. De eerste test die moet worden afgelegd is de zogenaamde size-test. Indien een dossier kleiner is dan een bepaalde waarde, bijvoorbeeld 4 megabytes, dan is het dossier geslaagd. In dit geval wordt het dossier meteen verplaatst naar laag 1, tenzij het dossier zich natuurlijk al op laag 1 bevond. De achterliggende gedachte is dat bestanden met een kleine grootte, een onbedui-dende latency hebben. In dit geval maakt het verder niet veel uit waar het bestand zich bevindt. De ruimte die wordt gecre¨eerd op laag 0 na het verplaatsen van deze kleine dossiers, kan beter gebruikt worden voor de wat zwaardere bestanden. Dit zorgt voor een effici¨enter verbruik van de capaciteit wat resulteert in lagere kosten per gigabyte. Deze test weegt het zwaarst. Indien het dossier inderdaad kleiner is dan de variabele drempelwaarde, dan hoeft het dossier niet meer getoetst te worden aan de andere regels.

(21)

Een andere test is de next appointment-test. Een dossier wordt geopend en er wordt gekeken naar de datum van de volgende afspraak. Indien dit langer is dan een van te voren gedefinieerd aantal dagen, dan is het dossier niet geslaagd. Het van te voren gedefinieerd aantal dagen is in de huidige implementatie gelijk aan (#af delingen × 2) − 1. In het meest ongunstige geval4 _{komt een afdeling namelijk pas na (#af delingen × 2) − 1 dagen aan de beurt. Deze}

drempelwaarde houdt op deze manier de laagst mogelijke waarde aan waar de functionaliteit van het algoritme gewaarborgd blijft. Indien het dossier wel slaagt, dan wordt het dossier met bijbehorende mediabestand verplaatst naar de bovenste laag. Immers, het bestand is binnenkort nodig. Als het tegenovergestelde waar is, dan wordt het bestand vanuit de bovenste naar de laag eronder verplaatst. Tenzij deze vol is, dan de laag daaronder. Deze test zorgt ervoor dat de leestijd van het dossier en mediabestand optimaal wordt, immers de data wordt verplaatst naar de toplaag.

De last appointment-test heeft een soortgelijke werking. De datum van de meest recente afspraak van een dossier wordt vergeleken met een van te voren gedefinieerd aantal dagen. Dit aantal is in de huidige implementatie vastgesteld op een aantal van 30 dagen. Ervaring binnen ChipSoft wijst uit dat indien een dossier is geopend of mediabestand is gegenereerd, een werk-nemer van een zorginstelling vaak in de dagen erna de beelden nakijkt. Om het zekere voor het onzekere te nemen is de drempelwaarde vastgesteld op 30 dagen. Indien de datum van het dossier binnen de drempelwaarde valt (gezien vanuit de dag van uitvoering van het algoritme), dan is de test succesvol afgerond en wordt het bestand, indien het zich daar niet al op bevond, verplaatst naar de bovenste laag. Is de test niet succesvol en bevindt het dossier zich op de top laag, dan wordt het dossier en bijbehorende mediabestand in principe verplaatst naar de laag er onder. Dit is echter onder voorbehoud, indien die laag namelijk vol is, wordt de bestemming de onderste laag. Ook deze test zorgt er voor dat de leestijd van het dossier en mediabestand optimaal wordt.

Een andere test is de move12-test. Deze test wordt alleen afgelegd door de dossiers op de middelste laag. Deze test kijkt namelijk hoelang een dossier zich al bevindt op deze laag. Indien dit langer is dan het toegestane aantal dagen, dan wordt het dossier en bijbehorende mediabestand verplaatst naar de laatste laag. Op deze manier blijft de middelste laag een goede bestemming voor de bestanden die slagen voor de eerste test, de size-test. Deze test is kosten-effici¨ent en distribueert bestanden naar de goedkoopste laag.

Ten slotte is er de removal-test. Ook deze test is laag-specifiek en wordt alleen afgelegd door de dossiers in de onderste laag. Indien een dossier een bepaald jaar of langer bestaat en er geen volgende afspraak in het systeem staat, wordt het dossier en bijbehorende media verwijderd. De drempelwaarde van het aantal jaren is in de huidige implementatie, met het oog op de Nederlandse weten regelgeving vastgesteld op 15 jaar5_{. Dit geldt overigens niet voor pati¨}_enten

met een genetische aandoening, in dit geval moet het dossier drie generaties lang bewaard blijven. Dit punt wordt echter buiten beschouwing gelaten binnen het onderzoek. De bovengenoemde tests zorgen voor drie mogelijkheden voor een dossier en het bijbehorende mediabestand: op de laag blijven, verplaatst worden naar een andere laag of verwijderd worden. Nadat deze beslissing is gevallen, is het volgende dossier van de betreffende afdeling aan de beurt.

4.1.4 Doelpercentage

Voordat het algoritme uitgevoerd wordt, moet een doelpercentage worden vastgesteld. Dit doel-percentage geeft aan welk doel-percentage van de toplaag gereserveerd moet worden voor de dagelijkse productie van de mediaproducerende afdelingen van, in de huidige implementatie, een zieken-huis6_{. Indien het algoritme na alle eerdergenoemde stappen tot de conclusie is gekomen dat het}

doelpercentage is behaald, is het algoritme succesvol afgerond. Indien dit echter niet het geval is, dan worden de in de vorige alinea’s beschreven handelingen herhaald, maar dan op de opvolgende

4_{Ongunstig indien een afdeling in de eerste shuffle als eerst aan de beurt komt en in de volgende shuffle als}

laatst.

5_{artikel 7:454 van het Burgerlijk Wetboek.}

6_{Het doelpercentage is relatief aan de instelling, een tandartspraktijk op het platte land hoeft beduidend}

(22)

afdeling. Dit gebeurt net zo lang tot dat het percentage wel is behaald. Natuurlijk kan het zo zijn dat zelfs na het afgaan van alle afdelingen het percentage nog steeds niet behaald is. Dit zien we later terug in de metingen en komt voor indien alle lagen bijna helemaal vol zitten. In dit geval is er weinig ruimte voor verplaatsing. Een oplossing hiervoor zou kunnen zijn om de capaciteit te vergroten binnen de simulatie onder het mom van “er wordt een nieuwe laag bijge-kocht en toegevoegd”, dit is echter toekomstwerk (zie sectie 6.2). In figuur 4.3 is een schematische weergave van alle stappen van het algoritme zoals beschreven in de hier voorafgaande alinea’s zichtbaar.

4.2 Tricks en optimalisaties

Naast de normale functionaliteiten die hierboven beschreven zijn, bevat het algoritme ook een enkele slimmigheid. Het Algorithm programma bevat onder andere de Conductor functie en de CheckMovePossibility functie. De Conductor bepaalt of een dossier in aanmerking komt voor verplaatsing. Indien dit het geval is, wordt er door de CheckMovePossibility functie gekeken of de laag van bestemming wel voldoende capaciteit heeft. Als er voldoende capaciteit is dan re-tourneert de functie de boolean waarde True. Indien het niet zo is, wordt er in bepaalde situaties getracht om dit alsnog tot een goed einde te kunnen brengen. Als voor een dossier bijvoorbeeld wordt besloten dat het van laag 0 naar laag 1 moet worden verplaatst en laag 1 zit vol. Dan wordt geprobeerd om het dossier onder te brengen in laag 2.

Initieel was het algoritme, met betrekking tot het behalen van het doelpercentage, iets anders ingericht. De tests waren veel minder streng met het idee om de toplaag zo veel mogelijk gevuld te laten. Immers, als je een hele snelle laag hebt, wil je die natuurlijk volledig benutten. Indien het percentage behaald was met deze mate van strengheid, dan werden de regels aangescherpt en werd er opnieuw door alle dossiers van de afdeling heengelopen. Dit gebeurde een aantal keer en indien het percentage nog steeds niet werd behaald, dan werd er overgeschakeld naar een andere afdeling. Echter zorgen deze extra handelingen voor veel extra iteraties. Vooral het aanpassen van de regels waarna alle dossiers opnieuw moeten worden doorlopen. Dit neemt onnodig extra tijd in beslag, waar het algoritme al gebonden is aan een tijdsframe. Bovendien is het beter om op safe te spelen wat betreft het doelpercentage. Door onvoorziene omstandigheden (een ramp met veel gewonden waardoor de eerste hulp afdeling van het ziekenhuis drukbezet raakt) zou er meer dan het doelpercentage nodig kunnen zijn. In dit geval zou het gewenst zijn dat het resterende deel van de capaciteit van de toplaag niet onnodig gevuld is. Bovendien worden opslagservers tegenwoordig vaak uitbesteed aan externe bedrijven waar er per gebruikte hoeveelheid storage betaald wordt. Ook hier is het weer gewenst om de toplaag niet onnodig te vullen. De voordelen wegen niet op tegen de nadelen.

De laatste zin van de vorige alinea geldt ook voor een dossier waarbij door de Conductor besloten is dat het, vanuit laag 1 of laag 2, naar laag 0 moet worden verplaatst. Dit gaat meestal om hot data. Binnen het Algorithm programma lukt zo een operatie bijna altijd. Echter, het zou zo kunnen zijn dat laag 0 weinig capaciteit meer over heeft. In dit geval werd er een Saviour functie aangeroepen die probeerde om, met behulp van het losser maken van de regels, laag 0 opnieuw leeg te pompen. Ook dit heeft te maken met het minder streng hanteren van de regels en ook deze methode zorgt voor iteraties die, indien je de regels vanaf het begin af aan strikt houdt, niet nodig zijn. Het losser maken van de regels heeft immers een limiet. Die limiet wordt nu vanaf het begin aangehouden.

4.3 Aannames

Het onderzoek dat is uitgevoerd binnen dit project, is gebaseerd op enkele aannames. De aan-names kunnen in twee kwadranten opgedeeld worden, namelijk aanaan-names die te maken hebben met het hierboven beschreven algoritme en aannames die specifiek te maken hebben met de

(23)

implementatie van het algoritme. De aannames zijn veelal gedaan om het onderzoek te kunnen toespitsen op de essentie van het probleem en ter wille van de werking van de simulatie. In de volgende alinea’s worden de belangrijkste aannames toegelicht en uitgelegd.

Algoritme-gebonden aannames

E´en van de aannames die gebonden zijn aan het algoritme heeft te maken met het meten van performance. Binnen de simulatie wordt performance uitgedrukt in leestijd. Er zijn talloze mogelijkheden om performance uit te drukken en te meten, deze mogelijkheden zijn meestal situatiespecifiek. Binnen dit project is het doel onder andere om een winst te behalen in perfor-mance. In principe is het voor de simulatie genoeg om te weten dat voor elk tweetal lagen, de bovenste laag sneller is. Hier kan je getallen aan hangen, bijvoorbeeld leestijd in megabytes per seconden. Uiteindelijk is het doel om het verschil in performance te meten, de resultaten worden uitgedrukt in winst of verliespercentages in performance. Er wordt namelijk van uitgegaan dat de tijd waarover het algoritme doet om alle data te re-distribueren, binnen de perken ligt van het tijdsbestek waarin de workload van het opslagsysteem het laagst ligt (bijvoorbeeld in de nacht). Er wordt ook uitgegaan van de beschikbaarheid van alle resources. Een andere aanname is dat de performance aan de opvragende kant, de pc’s die de data aanvragen uitvoeren op de server, niet in ogenschouw wordt genomen.

Implementatie-gebonden aannames

De aannames die gebonden zijn aan de beschreven implementatie zijn vooral restricties om het geheel te simplificeren. Allereerst wordt er uitgegaan van een uit meerdere lagen bestaande storage, in de implementatie zijn het er drie. Een storage die bestaat uit verschillende lagen ligt ten grondslag aan het classificeren van data. Als de storage niet bestaat uit verschillende lagen heeft het classificeren van data weinig zin [9]. Een andere aanname is dat elke dossier gebonden is aan slechts ´e´en corresponderend mediabestand, dit is feitelijk natuurlijk onjuist. Een dossier kan zowel meerdere als geen mediabestanden hebben. Voor de uitkomst van het onderzoek maakt het echter niet uit. Het GenerateData programma genereert data voor de kenmerken in het dossier. Twee van deze kenmerken zijn de meest recente afspraak en de eerstvolgende afspraak. De aannames in deze zijn dat de meest recente afspraak binnen een termijn van 0 tot 5 jaar in het verleden ligt. De eerst volgende afspraak ligt binnen een termijn van 0 tot 1 jaar. Deze aannames zijn gedaan om het algoritme zo goed mogelijk te kunnen testen binnen de simulatie. Indien de meest recente afspraak bijvoorbeeld als een datum in een tijdsbestek tot 30 jaar in het verleden was gedefinieerd, dan was de kans dat een bestand voldeed aan de last appointment-test heel erg klein. Daarnaast zijn alle dossiers per definitie in grootte gelijk aan de som van 2 megabytes7 plus en grootte van de bijbehorende mediadata. Ook wordt in de implementatie aangenomen dat de gebruikte vertrouwelijke dataset de norm is. Dit hoeft natuurlijk niet zo te zijn, maar wordt aangenomen omdat zulke informatie niet snel voor handen is. In het volgende hoofdstuk volgen ook enkele aannames, deze hebben vooral te maken met de metingen die worden beschreven.

(24)

(25)

HOOFDSTUK 5

Metingen en resultaten

5.1 Meting I

In dit hoofdstuk worden de uitgevoerde metingen toegelicht en de resultaten van de betreffende metingen uitgelegd en geanalyseerd. Het doel is om een goed beeld te krijgen van het gedrag van het algoritme in verschillende opstellingen. Het gedrag van het algoritme uit zich direct in de gemeten performance en indirect in de daar uit afgeleide kosten voor het opslagsysteem. Bij elke meting worden een tweetal situaties met elkaar vergeleken: pre-algorithm en post-algorithm.

Pre-algorithm geeft de situatie weer voordat het algoritme is uitgevoerd. Dit houdt in dat de storage center gevuld is met data volgens het eerder genoemde GenerateData programma. De data druppelt de eerste laag binnen en verplaatst zich naar de opvolgende lagen volgens het first in first out principe. Post-algorithm is de situatie binnen de storage center nadat het algoritme de data heeft geredistribueerd. In beide situaties zijn er meetmomenten en de resultaten daarvan worden in de volgende alinea’s weergegeven en geanalyseerd. De opstellingen in beide situaties blijven wel gelijk. In beide situaties wordt er met een variabele doelpercentage gemeten. Het doelpercentage varieert van 50% tot en met 98% met tussenstappen van 3%. Dit percentage wordt telkens meegegeven aan het Algorithm programma. Er wordt gestart bij een hoog doelpercentage van 50%, omdat er zoveel mogelijk cold data van de top laag gemigreerd moet worden. Bij een doelpercentage van 100% is er geen ruimte voor het algoritme om data te migreren en wordt daarom ook buiten beschouwing gelaten. De metingen zijn gericht op de leestijd van de toplagen van de pre- en post-algorithm situaties. De reden waarom alleen de toplagen in beschouwing worden genomen, is vanwege het feit dat het er binnen het algoritme om gaat dat alle data alleen benaderd moet worden via de toplaag. Dit gebeurt om de bottleneck van de leestijd, de leestijd op alle lagen behalve de toplaag, te ontwijken. De leestijd per megabyte verschilt per storage. In Meting II wordt dit verder toegelicht. Hetgeen wat getracht wordt te bereiken binnen dit onderzoek is dat zelfs met een lage grootte voor de top laag, de leestijd niet significant daalt.

(26)

5.1.1 Opstelling 1

Bij het eerste experiment bestaan de lagen uit respectievelijk 80.000, 80.000 en 80.000 megabytes. De som van de capaciteit van de drie lagen samen is voor eenderde gevuld. Het doelpercentage is een variabele factor binnen deze metingen. Bij elk doelpercentage zijn er veertig metingen uit-gevoerd om een betrouwbaar gemiddelde te krijgen van de gemiddelde leestijd per storage laag. Echter worden alleen de leestijden van de toplagen beschouwd in deze meting(en). Overigens lagen de leestijden van de overige lagen in alle 6801 _{executies van deze meting, hoger dan de}

leestijd van de toplaag van post-algorithm.

Figuur 5.1: Grafiek waarin het aantal dalingen in leestijd in de metingen van de post-algorithm situatie ten opzichte van de pre-algorithm situatie is weergegeven in percentages.

De grafiek in figuur 5.1 geeft de resultaten weer van de eerste meting. Zowel de x als de y-as representeren percentages. De x-as geeft de variabele doelpercentages weer. Elk getal dat weergegeven is op de x-as is veertig maal als variabele meegegeven aan het programma, de gemiddeldes die daaruit voortvloeien zijn de lijnen die te zien zijn in de grafiek. De groene lijn geeft aan hoe vaak er in de gemeten punten een daling in leestijd heeft plaatsgevonden. De rode lijn geeft aan hoe vaak het doelpercentage is behaald. Bij een doelpercentage van 50 procent is bijvoorbeeld te zien dat er in 70 procent van de metingen binnen dit doelpercentage, een daling in leestijd heeft plaatsgevonden. In alle gedane metingen heeft er een daling van de leestijd plaatsgevonden, de kleinste daling heeft plaatsgevonden bij een doelpercentage van 92%. Ook zijn er een paar optima waarneembaar: bij 59%, bij 71%, bij 77% en bij 86%. De grootste daling in leestijd is bij een doelpercentage van 77%. Het doelpercentage wordt in alle geteste gevallen behaald, zoals af te lezen aan de rode lijn. De gele lijn vormt het complement van de rode lijn.

1_{17 × 40 (er zijn 17 tussenstappen van 50 procent naar 98 procent met stappen van 3 en dit wordt telkens 40}

(27)

De variatie van de percentages waarin een daling van de leestijd zijn behaald, is te verklaren aan de hand van de inrichting van het algoritme. Het algoritme werkt in principe ´e´en willekeurige afdeling per executie af. Als in de metingen bijvoorbeeld vaak de Intensive Care afdeling werd aangewezen als eerste afdeling op het af te werken pad, dan worden er relatief veel grote bestanden geredistribueerd. De grootte van bestanden is evenredig met de leestijd: hoe groter het bestand, hoe langer het systeem er over doet om het bestand op te halen. Als binnen een meting dus bijvoorbeeld relatief veel “zware” afdelingen afgewerkt worden, dan valt de daling in leestijd groter uit ten opzichte van de metingen met relatief veel “lichte” afdelingen. Daarnaast kan het zo zijn dat in sommige gevallen meerdere afdelingen worden doorgelopen om het doelpercentage te behalen, dit gebeurt indien het niet in een keer gelukt is met de afdeling waarmee begonnen is. In dit geval kan de leestijd ook drastisch dalen, maar heeft het algoritme wel een extra afdeling moeten afwerken.

Figuur 5.2: Grafiek waarin de gemiddelde winst en verlies percentages van de leestijd per doelpercentage in de pre- en post-algorithm fase van laag 0 zijn weergegeven.

In de volgende grafiek, zichtbaar in figuur 5.2, zijn de winst en verlies percentages in perfor-mance weergegeven van post-algorithm ten opzichte van pre-algorithm. De groene lijn geeft in elk punt aan hoeveel de leestijd verschilt ten opzichte van de post-algorithm situatie in termen van procenten. Bij een doelpercentage van 50% is bijvoorbeeld te zien dat er op het gebied van daling in leestijd een winst is geboekt van 150%. Ook in dit geval is elk winstpercentage een gemiddelde van veertig executies van het programma op met het corresponderende doelpercen-tage als argument van het programma. In alle gemiddelden is een winst in daling van leestijd waarneembaar. In deze grafiek zijn er vijf optima waarneembaar: bij 50%, 59%, 65%, 77% en bij 83%. Ook hier valt de grilligheid te verklaren door de willekeur van het programma in de afwerking van een afdeling. De gemiddelde winst in daling van de leestijd van post-algorithm ten opzichte van pre-algorithm is in deze opstelling gelijk aan 174,5%.

(28)

5.1.2 Opstelling 2

Deze opstelling varieert ten opzichte van de vorige opstelling alleen in termen van de hoeveelheid data waarmee de lagen worden gevuld. Waar het in de vorige opstelling gelijk was aan eenderde, is het in deze opstelling gelijk aan tweederde. De capaciteit van de lagen blijft gelijk, deze is voor elke laag gelijk aan 80.000 megabytes.

In figuur 5.3 zijn de resultaten van het algoritme zichtbaar in de nieuwe opstelling. Een overeenkomst met opstelling 1 is dat ook in deze opstelling er in alle gevallen een daling van de gemiddelde leestijd waarneembaar is op de toplaag van post-algorithm ten opzichte van pre-algorithm. Er zijn echter ook enkele veranderingen waarneembaar. In opstelling 1 is grootste daling gemeten bij een doelpercentage van 77%: namelijk 93%. De gemiddelde daling in leestijd bij een doelpercentage van 77% in opstelling 2 is gelijk aan 68%. Dit is een verschil van 25% ten opzichte van de eerste opstelling. De hoofdreden hiervoor is dat er meer bestanden zijn bijgekomen, waar de capaciteit hetzelfde is gebleven: er is minder ruimte om met data te schui-ven. In opstelling 2 is er een grootste daling gemeten bij een doelpercentage van 50%, namelijk 73%. Evenals de vorige opstelling is ook hier de grilligheid van de lijn te verklaren door de manier waarop het algoritme werkt. Daarnaast is ook te zien dat het gemiddelde van het aantal succesvolle experimenten, dat wil zeggen experimenten waarbij het doelpercentage is behaald, een dalende trend heeft als het doelpercentage stijgt (zie de rode lijn). Na het doelpercentage van 83% zijn de pogingen om het doelpercentage te behalen gemiddeld gezien niet meer succesvol.

(29)

In figuur 5.4 zijn de winst en verlies percentages in performance weergegeven van de post-algorithm situatie ten opzichte van pre-post-algorithm situatie. De groene lijn geeft in elk punt aan hoeveel de leestijd verschilt ten opzichte van de post-algorithm situatie in termen van procenten. Ook in dit geval is elk winstpercentage een gemiddelde van veertig executies van het programma met het corresponderende doelpercentage als argument van het programma. Er zijn nogal wat pieken en dalen zichtbaar, ook dit valt weer te wijten aan de keuze in inrichting van het algoritme. In alle gemiddelden van de metingen is een winst waarneembaar in daling van de leestijd, ondanks de grotere hoeveelheid data. In deze grafiek zijn er vijf optima waarneembaar: bij 50%, 59%, 71%, 83% en bij 92%. De gemiddelde winst op het gebied van minimaliseren van de leestijd van de post-algorithm situatie ten opzichte van pre-algorithm situatie in deze opstelling is gelijk aan een 64%. Dit ligt veel lager dan bij opstelling 1, waar het gelijk was aan 174.5%. Ook dit valt te verklaren door de grotere hoeveelheid data: hoe meer data, hoe minder beschikbare capaciteit op de lagen om data te migreren, hoe minder effici¨ent het algoritme is.

(30)

Figuur 5.5: Gegroepeerde histogram waarin de percentages van het aantal dalingen in leestijd van pre-en post-algorithm is weergegevpre-en voor 2 opstellingpre-en: capaciteit gevuld met epre-enderde pre-en capaciteit gevuld met tweederde

In figuur 5.5 zijn de resultaten van de figuren 5.1 (opstelling 1) en 5.3 (opstelling 2) naast elkaar geplaatst. De dalingen die zijn gerealiseerd in de opstelling waarin de capaciteit met eenderde gevuld was, zijn in de meeste gevallen hoger behalve bij het doelpercentage van 50%. De betere prestaties van opstelling 1 valt te verklaren door het feit dat er in opstelling 1 meer data-migratie mogelijk is vanwege de grotere beschikbaarheid aan ruimte. Alle waarden zijn gelijk of groter aan 50%. Dat betekent dat er in minimaal de helft van de metingen voor elk doelpercentage een daling is gerealiseerd.

(31)

5.1.3 Opstelling 3

In deze opstelling bestaan de lagen 0, 1 en 2 respectievelijk uit 40.000, 100.000 en 100.000 mega-bytes. Deze meting is interessant, omdat hieruit blijkt hoe het algoritme zich gedraagt met een relatief kleinere toplaag ten opzichte van de overige twee lagen. De totale som van de capaciteit is voor eenderde gevuld. Evenals in de vorige opstellingen is ook hier het doelpercentage een variabele factor binnen deze metingen. Het percentage varieert van 50 procent tot en met 98 procent met tussenstappen van 3 procent. Bij elk doelpercentage wordt er veertig maal geme-ten. Met behulp van deze metingen zijn de gemiddelde leestijden van pre en post-algorithm met elkaar te vergelijken. Zoals eerder uitgelegd worden alleen de leestijden van de bestanden van de toplagen met elkaar vergeleken.

In figuur 5.6 zijn de resultaten weergegeven van de eerste meting in de derde opstelling. Zowel de x als de y-as representeren percentages. De x-as geeft de variabele doelpercentages weer. Elk getal dat weergegeven is op de x-as is veertig maal als variabele meegegeven aan het programma, de gemiddeldes die daaruit voortvloeien zijn de lijnen die te zien zijn in de grafiek. De groene lijn geeft aan hoe vaak er in de gemeten punten een daling in leestijd heeft plaatsgevonden. De rode lijn geeft aan hoe vaak het doelpercentage is behaald. Tot en met het doelpercentage van 92% is in alle gevallen het doelpercentage behaald. Na dit breekpunt werkt het algoritme niet meer zo effici¨ent als ervoor en komt het steeds vaker voor dat het doelpercentage niet wordt behaald met als dieptepunt het doelpercentage van 98%. Aan de groene lijn is ook te zien dat na het doelpercentage van 89% er een vrije val plaatsvindt in het aantal dalingen in leestijd. Er wordt steeds minder vaak een daling gerealiseerd. Evenals opstelling 2 is ook dit een bewijs dat het algoritme de data in een volle storage met een hoge doelpercentage niet goed kan redistribueren. Bij een doelpercentage van 65% en 74% zijn de hoogste dalingen gemeten, respectievelijk 90% en 90%. Evenals in de vorige twee opstellingen heeft de grafiek ook hier een licht grillig karakter

(32)

en evenals in de vorige twee opstellingen valt ook dit te verklaren aan de hand van de keuze in inrichting van het algoritme.

Figuur 5.7: Grafiek met de gemiddelde winst en verlies percentages van de leestijd per doelpercentage in de pre- en post-algorithm fase van laag 0.

In de volgende grafiek, zichtbaar in figuur 5.7, zijn de winst en verlies percentages in perfor-mance weergegeven van de post-algorithm situatie ten opzichte van de pre-algorithm situatie. De groene lijn geeft in elk punt aan hoeveel de leestijd verschilt ten opzichte van de post-algorithm situatie in termen van procenten. Het eerste wat opvalt in deze opstelling is dat er een ver-lies in daling van leestijd plaats heeft gevonden bij het doelpercentage van 98%. Een te hoog doelpercentage is in deze opstelling niet gewenst. Daarnaast is er een piek waarneembaar bij het doelpercentage van 89%, vervolgens daalt de lijn sterk. Het gemiddelde van alle winst en verliespercentages bedraagt in deze opstelling 143.05%. Er is dus gemiddeld 143.05% gedaald in leestijd. Dit verschilt slechts 31.45% met opstelling 1 waar de toplaag juist kleiner in capaciteit is. Het eerder genoemde verlies in de daling van de daling wordt dus goed opgevangen.

(33)

5.1.4 Opstelling 4

Deze opstelling varieert ten opzichte van de vorige opstelling in termen van de hoeveelheid data waarmee de lagen worden gevuld. Waar het in de vorige opstelling gelijk was aan eenderde, is het nu gelijk aan tweederde. De capaciteit van de lagen 0, 1 en 2 blijft gelijk, deze is respectievelijk 40.000 100.000 en 100.000 megabytes.

In figuur 5.8 zijn de resultaten van het algoritme zichtbaar in de nieuwe opstelling. De resultaten lijken qua vorm sterk op de resultaten van opstelling 3. Evenals bij opstelling 3 wordt ook hier tegen de hogere doelpercentages aan slechter gepresteerd. De negatieve trend zet zich ´

e´en stap eerder in dan bij opstelling 3. In opstelling 3 was het breekpunt het doelpercentage van 98%, in dit geval is het breekpunt het doelpercentage van 89%. In deze opstelling is er een grootste daling gemeten bij een doelpercentage van 77% ter waarde van 83%. Overigens lijkt het algoritme het best te presteren met een doelpercentage tussen de 65% en 77%, dit geldt voor alle opstellingen behalve opstelling 2.

(34)

In figuur 5.9 zijn de winst en verlies percentages in performance weergegeven van de post-algorithm situatie ten opzichte van pre-post-algorithm situatie. De groene lijn geeft in elk punt aan hoeveel de leestijd verschilt ten opzichte van de post-algorithm situatie in termen van procenten. Ook in dit geval is elk winstpercentage een gemiddelde van veertig executies van het programma met het corresponderende doelpercentage als argument van het programma. Er is een sterke winst waarneembaar in de doelpercentages rondom 71% met als hoogtepunt 71% zelf. Daar is namelijk een winstpercentage van 136% gemeten in daling van de leestijd. Het doelpercentage van 83% vormt het omslagpunt, na dit punt daalt de lijn sterk met als laagtepunt een verlies van 64%. De gemiddelde winst in de minimalisatie van de leestijd van post-algorithm ten opzichte van pre-algorithm in deze opstelling is gelijk aan 80.71%, een significant verschil met de vorige opstelling waar de gemiddelde winst gelijk was aan 143.05%. Een simpele verklaring hiervoor is het verschil in hoeveelheid data dat geredistribueerd wordt, in deze opstelling is dat gelijk aan tweederde van de capaciteit. Het algoritme werkt blijkbaar minder effici¨ent onder hoge doelper-centages, zoals waarneembaar in de figuren 5.7 en 5.9.

(35)

Figuur 5.10: Gegroepeerde histogram waarin de percentages van het aantal dalingen in leestijd van preen post-algorithm is weergegeven voor 2 opstellingen: capaciteit gevuld met eenderde en capaciteit gevuld met tweederde.

In figuur 5.10 zijn de resultaten van de figuren 5.6 (opstelling 3) en 5.8 (opstelling 4) tegen elkaar uitgezet. De rode balken geven het aantal dalingen in leestijd weer binnen de huidige opstelling en de groene balken het aantal dalingen in leestijd weer binnen opstelling 3. Ondanks het grote verschil in hoeveelheid data, houden de rode balken redelijk gelijke tred met de groene. Onder de lagere doelpercentages is de daling bij een capaciteit gevuld met tweederde zelfs sterker, bijvoorbeeld bij de doelpercentages van 50% en 53%. Tegen de hogere doelpercentages aan (vanaf 86%) lopen de balken wel verder uiteen in het voordeel van eenderde kleur. Bij de doelpercentages 50%, 71% en 77% zijn de verschillen minimaal.

(36)

5.2 Meting II

In deze sectie worden er nog een aantal metingen toegevoegd aan de eerder beschreven metin-gen. Deze metingen hebben als doel de kosten beter in beeld te brenmetin-gen. Al deze metingen zijn gedaan met een doelpercentage van 71%. Er is gekozen voor dit percentage, omdat dit percentage vooral in de winst en verlies grafieken voor de situaties waarbij de capaciteit met tweederde gevuld is altijd een optimum bezit. Daarnaast zit dit percentage in het gouden be-reik van 65%-77%, binnen dit bebe-reik presteert het algoritme bijna in alle gevallen van de vorige metingen het best. Het verschil binnen de opstellingen tussen de situaties onderling is met dit doelpercentage niet groot. Het doelpercentage lijkt zich dus goed te lenen voor verdere metingen.

Voor verschillende formaties is de gemiddelde leestijd berekend en de bijbehorende kosten. De leestijd die we hanteren voor laag 0 is 35 micro-seconds per megabyte, voor laag 1 5.000 micro-seconds per megabyte en voor laag 2 10.000 micro-seconds per megabyte2_{. Deze getallen}

dienen slechts ter indicatie en om te vergelijken tussen de formaties3_{. Per storage-laag wordt}

de gemiddelde grootte van een bestand berekend. Op basis van dit gemiddelde wordt een ge-middelde leestijd berekend. De kosten zijn gebaseerd op de tiered storage van het UT Health Center [15]: 0.86 euro per gigabyte voor laag 0, 0.35 euro per gigabyte voor laag 1 en 0.26 euro per gigabyte voor laag 2. De kosten worden berekend door het product te nemen van de kosten per gigabyte en de grootte van de laag. De grootte van de toplaag wordt in deze opstelling voortdurend veranderd, evenals de grootte van ´e´en van de twee overige lagen.

Figuur 5.11: Gegroepeerde histogram waarbij voor verschillende storage formaties de kosten zijn uitgezet tegenover de performance.

2_{Gebaseerd op de verhouding in access time opgesteld door ComputerHope [2].}

(37)

In de histogram van figuur 5.11 zijn de opstellingen van Meting I meegenomen bij de nieuwe metingen. De nieuwe metingen bestaan uit verschillende formaties waarbij de grootte van de toplaag telkens verkleind wordt. Deze afname is omgekeerd evenredig met de groei van één van de overige twee lagen. Op de x-as zijn de formaties weergegeven. De ideale formatie is de formatie waar zowel de gele balk als de blauwe het laagst zijn. Deze kleuren representeren respectievelijk de gemiddelde leestijd en de kosten per formatie. De eerste twee formaties zijn afkomstig uit Meting I. De formatie 80-80-80 presteert bijvoorbeeld heel goed met een storage die voor eenderde gevuld is. Echter is deze formatie wel het duurst. De daaropvolgende formatie is de formatie die is gehanteerd in de opstellingen 3 en 4 van Meting I. De kosten vormen de helft van de kosten van formatie 80-80-80, terwijl er slechts een fractie aan daling van de gemiddelde leestijd wordt ingeleverd. De daaropvolgende formaties zijn stapsgewijs uitgevoerd met telkens een verlaging van 10.000 megabyte van de toplaag. In de eerste 7 opvolgende formaties wordt laag 1 telkens vergroot met 10.000 megabytes en in de laatste 7 formaties wordt laag 2 telkens vergroot met 10.000 megabytes. Duidelijk is te zien dat de kosten van een formatie lager uitvallen indien de toplaag kleiner is. De resultaten verschillen daarentegen niet heel veel binnen de verschillende formaties. De gemiddelde leestijd is het laagst bij de formatie 70-80-90. Een grotere toplaag staat dus niet altijd garant voor betere prestaties binnen dit algoritme. De hoogste leestijden worden gemeten bij de allerkleinste toplagen, namelijk van 10.000 megabytes. In deze gevallen is er niet genoeg ruimte om de efficiëntie van de toplaag te benutten. De beste oplossing moet vooral gezocht worden in formaties met een grote middenlaag. De formatie 40-80-120 heeft bijvoorbeeld de op een na laagste leestijd. Deze formaties hebben genoeg ruimte op de toplaag waar het algoritme efficiënt te werk mee kan gaan. De beste oplossing lijkt dus te liggen in formaties met een redelijke toplaag (30.000 - 50.000 megabytes) in combinatie met een grote middenlaag.

(38)

(39)

HOOFDSTUK 6

Conclusie

6.1 Conclusie

De resultaten uit het vorige hoofdstuk geven een goed beeld van de sterkte van het algoritme. Bij het vullen van de capaciteit van de lagen met eenderde met een formatie van 80.000, 80.000, 80.000 megavytes, zien we in opstelling 1 dat er zelfs tot 93% van de gevallen een daling wordt bewerkstelligd door het algoritme. Daarnaast wordt in alle gevallen het doelpercentage behaald. De tweede opstelling werkt redelijk, niet zo goed als de eerste opstelling, maar dat een logische verklaring lijkt de grotere hoeveelheid data ten opzichte van de eerste opstelling. Het doelpercen-tage wordt vaker niet behaald, desondanks vindt er wel in elk gemeten doelpercendoelpercen-tage een daling plaats. De post-algorithm situaties presteren beduidend beter dan de pre-algorithm situaties.

Evenals in de vorige opstellingen presteert het algoritme ook goed in de derde opstelling. Na een doelpercentage van 89% zijn de resultaten minder goed, echter lijdt de gemiddelde leestijd er nauwelijks onder. Met inachtneming van de grootte van de toplaag, slechts 40000 megabytes, is dit een goede prestatie en precies wat het doel is van het algoritme. Net als bij opstelling 3 bestaat ook opstelling 4 uit respectievelijk 40.000, 100.000, 100.000 megabytes voor de lagen 0, 1 en 2. Bij opstelling 4 is alleen de hoeveelheid data vermeerderd. Ondanks deze vermeerdering presteert het algoritme naar behoren: tot en met doelpercentage 89 vindt er in steeds meer dan de helft van de gevallen een daling in leestijd plaats. Ook in deze twee situaties presteren de post-algorithm situaties in de ruime meerderheid vna de gevallen beter dan de pre-post-algorithm situaties.

Op het gebied van kosten besparing zijn er enkele interessante conclusies te trekken. Als eerst stellen we dat hoe minder de capaciteit bedraagt van de toplaag, hoe goedkoper het geheel. Als de capaciteit van de toplaag wordt verminderd, maar in combinatie van de vergroting van een van de overige twee lagen, dan komen er goedkope oplossingen uit (zie figuur 5.11). De oplossing lijkt vooral te liggen in een redelijk compacte toplaag in combinatie met een grote middenlaag. De vergroting van de middenlaag zorgt net voor een betere performance dan een vergroting van de laatste laag. De kosten zijn in het laatste geval wel lager, maar het verschil in kosten tussen de twee formaties is niet significant genoeg om in beschouwing te nemen.

Een van de doelvragen was of de kosten van het systeem na de werking van het algoritme goedkoper uitvallen dan bij de huidige implementatie. Deze vraag kan alleen de zorginstelling beantwoorden na het duidelijk maken van de keuze in formatie. Wat we wel kunnen concluderen is dat de performance in de meeste gevallen dicht bij elkaar ligt, ondanks de formatieverschillen en dus de kostenverschillen. Een duurdere storage is dus niet per definitie sneller. Een andere vraag was: welke invloed heeft het algoritme heeft op de leestijd? Het algoritme zorgt in de meeste gevallen voor een winst in de daling van de leestijd. In enkele gevallen vindt er ook een verlies plaats in daling van de leestijd, de leestijd wordt dus langer, dit komt voor bij doelper-centages hoger dan 92%.