Filip Luki´c
Primerjava uˇ cinkovitosti podatkovnih baz pri obravnavi ˇ casovnih vrst
DIPLOMSKO DELO
VISOKOˇSOLSKI ˇSTUDIJSKI PROGRAM PRVE STOPNJE
RA ˇCUNALNIˇSTVO IN INFORMATIKA
Mentor : viˇs. pred. dr. Aljaˇ z Zrnec Somentor : asis. dr. Marko Poˇ zenel
Ljubljana, 2021
koriˇsˇcenje rezultatov diplomske naloge je potrebno pisno privoljenje avtorja, Fakultete za raˇcunalniˇstvo in informatiko ter mentorja.
Besedilo je oblikovano z urejevalnikom besedil LATEX.
Tematika naloge:
Vse veˇc informacijskih storitev temelji na obdelavi velikih koliˇcin podatkov.
Za njihovo uˇcinkovito shranjevanje so se uveljavila orodja in baze, ki upora- bljajo ˇcasovne vrste. V okviru diplomske naloge izberite dve podatkovni bazi za podporo ˇcasovnim vrstam ter eno klasiˇcno podatkovno bazo. Primerjajte jih po uˇcinkovitosti in ostalih kriterijih, ki vplivajo na njihov izbor.
Povzetek Abstract
1 Uvod 1
2 Podatkovna baza in ˇcasovne vrste 5
3 Pregled izbranih performanˇcnih testov 15
4 Metodologija 23
4.1 Predstavitev podatkovnih baz . . . 23
4.2 Opis kriterijev . . . 29
4.3 Vzpostavitev testnega okolja . . . 33
4.4 Zgradba performanˇcnega testa . . . 34
5 Izvedba testiranja 37 5.1 Opis uporabljenih operacij . . . 38
6 Predstavitev rezultatov 47 6.1 Operacije pisanja v podatkovno bazo . . . 47
6.2 Brisanje . . . 59
6.3 Operacije branja iz podatkovne baze . . . 62
6.4 Analiza rezultatov . . . 74
6.5 Vrednotenje podatkovnih baz z vidika nemerljivih kriterijev . . 77
Literatura 81
2.1 Regularne in iregularne ˇcasovne vrste . . . 6
2.2 Primer relacije med dvema tabelama . . . 8
2.3 Arhitektura lambda [16] . . . 14
3.1 Predlog naˇcrta za performanˇcni test [6] . . . 16
3.2 Poraba pomnilnika pri InfluxDB [15] . . . 19
3.3 Zasedenost CPU pri InfluxDB [15] . . . 20
3.4 Arhitektura orodja IoTDB-Benchmark [18] . . . 21
3.5 Postopki pri orodju IoTDB-Benchmark [18] . . . 22
4.1 Grafiˇcni vmesnik za podatkovno bazo Postgres . . . 25
4.2 Primer tabele ˇcasovnih vrst [1] . . . 27
4.3 Shema performanˇcnega testa . . . 34
5.1 Branje podatkov znotraj ˇcasovnega intervala . . . 43
5.2 Raˇcunanje vsot za doloˇcen atribut . . . 43
5.3 Raˇcunanje povpreˇcij za doloˇcen atribut . . . 44
5.4 Iskanje minimalnih vrednosti . . . 45
5.5 Iskanje maksimalnih vrednosti . . . 45
5.6 Izvedba kompleksne poizvedbe . . . 46
6.1 Cas izvajanja navadnega zapisovanja pri ˇˇ casovno urejenih po- datkih . . . 48
6.2 Cas izvajanja navadnega zapisovanja pri ˇˇ casovno urejenih po- datkih z uporabo indeksov . . . 49
podatkih . . . 51 6.4 Cas izvajanja navadnega zapisovanja pri ˇˇ casovno neurejenih
podatkih z uporabo indeksov . . . 52 6.5 Cas izvajanja pri zapisovanju ˇˇ casovno urejenih podatkov v
sveˇznju . . . 54 6.6 Cas izvajanja pri zapisovanju ˇˇ casovno urejenih podatkov v
sveˇznju z uporabo indeksov . . . 55 6.7 Cas izvajanja zapisovanja neurejenih ˇˇ casovnih vrst v sveˇznju . 57 6.8 Cas izvajanja zapisovanja neurejenih ˇˇ casovnih vrst v sveˇznju
z uporabo indeksov . . . 58 6.9 Cas izvajanja pri operaciji brisanja . . . .ˇ 60 6.10 ˇCas izvajanja pri operaciji brisanja z uporabo indeksov . . . . 61 6.11 ˇCas izvajanja pri branju podatkov znotraj ˇcasovnega intervala 63 6.12 ˇCas izvajanja pri branju podatkov znotraj ˇcasovnega intervala
z uporabo indeksov . . . 64 6.13 ˇCas izvajanja pri raˇcunanju meseˇcnih vsot za posamezno vozilo 65 6.14 ˇCas izvajanja pri raˇcunanju meseˇcnih vsot za posamezno vo-
zilo z uporabo indeksov . . . 66 6.15 ˇCas izvajanja pri raˇcunanju meseˇcnih povpreˇcij za posamezno
vozilo . . . 67 6.16 ˇCas izvajanja pri raˇcunanju meseˇcnih povpreˇcij za posamezno
vozilo z uporabo indeksov . . . 68 6.17 ˇCas izvajanja pri raˇcunanju meseˇcnih naraˇsˇcajoˇcih minimu-
mov za posamezno vozilo . . . 69 6.18 ˇCas izvajanja pri raˇcunanju meseˇcnih naraˇsˇcajoˇcih minimu-
mov za posamezno vozilo z uporabo indeksov . . . 70 6.19 ˇCas izvajanja pri raˇcunanju meseˇcnih padajoˇcih maksimumov
za posamezno vozilo . . . 71 6.20 ˇCas izvajanja pri raˇcunanju meseˇcnih padajoˇcih maksimumov
za posamezno vozilo z uporabo indeksov . . . 72
deksov . . . 74
kratica angleˇsko slovensko BASE basic availability, soft state,
eventual consistency
osnovna razpoloˇzljivost, mehko stanje, eventuelna konsistenca
DBMS database management system sistem za upravljanje podat- kovnih baz
TSDB time series data base podatkovna baza za ˇcasovne vrste
DDL data definition language jezik za opisovanje podatkov DML data manipulation language jezik za manipulacijo s podatki IoT Internet of Things internet stvari
ACID atomicity, consistency, isola- tion, durability
atomarnost konsistenstost, izolacija, trajnost
LTS long term support dolgoroˇcna podpora
GUI graphical user interface grafiˇcni uporabniˇski vmesnik API application programming in-
terface
aplikacijski programski vme- snik
RP retention policy politika zastarevanja
SQL structured query language strukturirani poizvedovalni je- zik
Naslov: Primerjava uˇcinkovitosti podatkovnih baz pri obravnavi ˇcasovnih vrst
Avtor: Filip Luki´c
Danes ˇzivimo v svetu, kjer se naˇse vsakodnevne dejavnosti vedno bolj digitalizirajo. Priˇca smo obdobju, kjer imamo na voljo veliko naprav, ki se vkljuˇcujejo v omreˇzje in ustvarjajo velike koliˇcine podatkov. Med te naprave ne sodijo zgolj prenosniki in mobilni telefoni, temveˇc vse bolj prisotni sen- zorji v avtomobilih, pametnih domovih, sistemih v industriji in energetiki, ki poˇsiljajo vrste podatkov v omreˇzje. Tradicionalne podatkovne baze niso kos izzivom, ki jih predstavljajo tolikˇsne koliˇcine podatkov. Zato so se pojavile podatkovne baze za ˇcasovne vrste, ki senzorske podatke ˇcasovno ˇzigosajo in jih fiziˇcno zdruˇzujejo po ˇcasu, kar omogoˇca uˇcinkovitejˇso obdelavo podat- kov. Trenutno obstaja na trgu veliko razliˇcnih podatkovnih baz za ˇcasovne vrste in baz, ki podpirajo delo s ˇcasovnimi vrstami. To predstavlja izbor najustreznejˇse podatkovne baze za neko reˇsitev razvijalcem izredno zahteven izziv. Za izbiro podatkovne baze si razvijalci programske opreme pomagajo z uporabo ali pregledom performanˇcnih testov. Performanˇcni test je v osnovi program, ki skozi definirano in nadzorovano okolje ovrednoti programsko opremo s pomoˇcjo nabora doloˇcenih meritev. V primeru podatkovnih baz je to program, ki pripravi podatke in izvede nabor doloˇcenih poizvedb nad po- datkovno bazo, ter pri tem izmeri kriterije uˇcinkovitosti. Ker so podatkovne baze za ˇcasovne vrste razmeroma nove, obstaja malo neodvisnih primerjav
performanˇcni test, ki bi skozi ˇstudijo primera uporabe pomagal pri odgovoru na vpraˇsanje katera podatkovna baza za ˇcasovne vrste je najbolj ustrezna za doloˇcen scenarij.
Kljuˇcne besede: ˇcasovne vrste, podatkovna baza za ˇcasovne vrste, Timescale, InfluxDB, Postgres, performanˇcni test.
Title: Diploma thesis sample Author: Filip Luki´c
Today we live in a world, where our everyday activities are becoming more and more digitalised. We are witnesses of an age, where we have a large number of devices at our disposal, which are connecting to the web and are producing large quantities of data. Among these devices belong not only laptops and mobile phones, but also even more present sensors in cars, smart homes, industry and power plants, which are sending rows of data into the web. Traditional databases could not cope with all the challenges, which were presented by such large amounts of data. Thus the timeseries databases emerged. Their main characteristic is that they add a timestamp to sensor data, which is then used as a basis for grouping. Finally this allows them to handle data more effectively. Currently, there are many different timeseries databases and others which support work with timeseries. Consequently, this greets the developers with the difficulty of choosing the right database for some solution. Therefore to fulfill this task, the developers require the assis- tance of a benchmark. A benchmark is basically a program, which through a defined and controlled environment, evaluates the performances of some software, with a set of tests. In the case of databases, this represents a pro- gram which prepares data and executes a set of given queries, on a database.
Lastly it measures the effectiveness, through the chosen criteria. The prob- lem is that, there are merely a few existing benchmarks, which could be used as a reference, as the TSDBs are a relatively new concept. These are usually
question which timeseries database is more suitable for a given scenario.
Keywords: timeseries, timeseries database, Timescale, InfluxDB, Postgres, benchmark.
Uvod
Z razvojem tehnologije je priˇslo do velike rasti koliˇcine podatkov na spletu.
To omogoˇca mnoˇzica senzorskih naprav, ki vsako sekundo poˇsilja veliko ˇstevilo podatkov v omreˇzje. To zasnovo imenujemo internet stvari (angl. in- ternet of things) [6, 16, 18]. Senzorji svojim meritvam dodajo ˇcasovno znaˇcko z namenom analiziranja podatkov skozi daljˇse ˇcasovno obdobje in ugotavlja- nja zakonitosti skritih v podatkih. ˇCasovno ˇzigosani podatki omogoˇcajo ugo- tavljanje razliˇcnih trendov in napovedovanje sprememb v prihodnosti. Takim podatkom pravimo ˇcasovne vrste [8].
V prometu se uporabljajo senzorji za spremljanje vozil na poti. Senzorji poˇsiljajo na streˇznik podatke, kot so lokacija, hitrost vozila, stanje rezervoarja ipd. Analiza podatkov omogoˇca vrsto izboljˇsav pri zmanjˇsevanju stroˇskov porabe goriva, vzdrˇzevanju vozil, nudenju pomoˇci na cesti, napovedovanju prihodov in upravljanja z osebjem. Podobno je tudi pri taksi sluˇzbah, kjer se poleg lokacije spremlja tudi ˇstevilo potnikov in cena za prevoˇzeno razda- ljo. Prevozna podjetja tako lahko poizvedujejo, kdaj in kje je povpraˇsevanje po storitvah prevoza najveˇcje, koliko novih voznikov morajo zaposliti itd.
Prav tako se poenostavi beleˇzenje plaˇcil in obraˇcun davkov. V letalskem in ladijskem prometu se zajemajo podatki o lokaciji, stanju tovora in urnik pri- hodov in odhodov plovil. Poleg prometa se ˇcasovne vrste uporabljajo tudi v industriji [12]. V proizvodnji kemijskih uˇcinkovin morajo sistemi imeti na
1
voljo podatke o spojinah, ki so v uporabi. V tovarnah so nameˇsˇceni senzorji za nadzor nivoja tekoˇcin, temperature, in topil, z namenom optimizacije in neoviranega poteka proizvodnje.
Najbolj aktualno podroˇcje, kjer nastopajo ˇcasovne vrste, je energetika [18]. Zanimiv primer najdemo na Kitajskem. Kitajska, kot energetsko revna drˇzava, vse veˇc vlaga v razvoj alternativnih virov pridobivanja energije. Eno izmed reˇsitev predstavlja primer vetrne elektrarne, ki ima 1000 turbin opre- mljenih s senzorji. Vsak senzor v intervalu med 5 in 7 sekund opravi sto meritev. Skupno na streˇznik prispe vsakih nekaj sekund ˇcasovna vrsta, ki ˇsteje 100 000 meritev. Uporabo ˇcasovnih vrst zasledimo tudi pri pametnem gospodarjenju z energijo. Razvite zahodne drˇzave vlagajo v gradnjo pame- tnih domov in mest z namenom zmanjˇsevanja porabe energije [17]. Osnova pametnih domov so senzorji, ki merijo temperaturo in vlago v sobah, ter se na osnovi meritev odloˇcijo, ali je potrebno ogrevanje prostorov. Nadalje si lahko s ˇcasovnimi vrstami pomagamo pri varovanju okolja. V Kanadi je obstajala pobuda za vzpostavljanje sistema za nadzor in spremljanje one- snaˇzenosti jezer in moˇcvirij [15]. S pomoˇcjo senzorjev so merili temperaturo, kislost, koliˇcino ionov in prisotnost teˇzkih kovin ter strupov v vodi. Vsem tem primerom je skupno veliko ˇstevilo podatkov, ki jih ustvarjajo senzorji skozi ˇcas. Za hranjenje in manipulacijo vseh teh podatkov se uporabljajo po- datkovne baze. Klasiˇcne relacijske baze vse teˇzje dohajajo take obremenitve, zato se vse bolj uveljavljajo baze tipa NoSQL [14, 23, 21] in podatkovne baze za ˇcasovne vrste (angl. Time Series DB - TSDB). Obstajajo tudi primeri, kjer se uporabljajo posebej porazdeljeni streˇzniki relacijske baze MySQL za ˇcasovne vrste [6].
Podatkovna baza za ˇcasovne vrste je specializirana za delo s podatki, ki nastopajo kot ˇcasovne vrste. Na spletni strani DB-Engines zasledimo le- stvico, na kateri je ovrednoteno skupaj 343 podatkovnih baz [3]. Njihova ˇstevilˇcnost, namen uporabe, podprtost in zdruˇzljivost z drugo programsko opremo oteˇzijo izbor najustreznejˇse reˇsitve. Omenjena dejstva skupaj vpli- vajo na zahtevnost implementacije sploˇsnih performanˇcnih testov za primer-
javo med razliˇcnimi podatkovnimi bazami. Trenutno je malo orodij, ki bi omogoˇcala performanˇcne teste med razliˇcnimi bazami. Ta orodja pogosto podpirajo zgolj teste za doloˇcene scenarije (npr. stroˇski delovanja podat- kovne baze), ali imajo podporo za omejeno ˇstevilo podatkovnih baz. Prav tako je veˇcina teh orodij plaˇcljiva ali pa niso dostopna javnosti [5].
V diplomski nalogi bomo na podatkovnih bazah primerjali izvajanje ope- racij nad podatki. Za primerjavo smo izbrali tri podatkovne baze: Postgres, Timescale in InfluxDB [5, 6]. Pri izboru smo upoˇstevali zastopanost razliˇcnih tipov baz. Postgres kot predstavnik tradicionalne objektno – relacijske po- datkovne baze, InfluxDB kot nerelacijsko podatkovno bazo za ˇcasovno vrsto in Timescale, ki vpelje ˇcasovne vrste v bazo Postgres.
Vsebina diplomskega dela je razdeljena na pet poglavij. V prvem po- glavju se osredotoˇcamo na definicijo temeljnih konceptov podatkovnih baz in ˇcasovnih vrst. V drugem poglavju sledi pregled sorodnih del, ˇclankov in diplomskih del s podroˇcja primerjave uˇcinkovitosti podatkovnih baz. V tretjem poglavju opiˇsemo podatkovne baze, na katerih smo izvedli perfor- manˇcni test. Temu sledi obravnava kriterijev, ki so bili izbrani za ugota- vljanje uˇcinkovitosti posameznih baz. Poglavje nato zaokroˇzimo z opisom metode, na osnovi katere je bila primerjava izvedena. Sledi izvedba testira- nja, kjer je predstavljena implementacija performanˇcnega testa in meritev, ki so bile izbrane za testiranje. Predzadnje poglavje vsebuje predstavitev dobljenih rezultatov. V zakljuˇcku povzamemo najpomembnejˇse ugotovitve diplomske naloge.
Podatkovna baza in ˇ casovne vrste
Na zaˇcetku bomo predstavili osnovne koncepte podatkovnih baz za ˇcasovne vrste, njihovo arhitekturo in razlike med njimi ter klasiˇcnimi relacijskimi bazami.
Pri podatkovnih bazah se pogosto sreˇcujemo s potrebo po shranjevanju podatkov skupaj z oznako ˇcasa, v katerem so nastali - ˇcasovno znaˇcko (angl.
timestamp). Gre za meritve, ki se beleˇzijo periodiˇcno, pri ˇcemer je ˇcasovni interval lahko poljuben in spremenljiv. Za tovrstne podatke se je ustalilo ime ˇcasovne vrste [8]. Loˇcimo dve vrsti ˇcasovnih vrst: podatke, ki nastajajo v enakomernih intervalih – imenujemo jih regularne metrike in podatke, ki nastajajo v neenakomernih intervalih. Slednjim pravimo neregularni podatki oziroma dogodki (angl. events). Na sliki 2.1 je s krogi, ki predstavljajo na- stanek posameznih podatkov skozi ˇcas, prikazana razlika med obema tipoma ˇcasovnih vrst.
Zaˇcetki uporabe ˇcasovnih vrst segajo v 19. stoletje. Ljudje so se pri raziskovanju nevede ukvarjali s ˇcasovnimi vrstami, kot na primer britanski raziskovalci in pomorˇsˇcaki, ki so vsako uro zapisovali v ladijski dnevnik me- ritve geografske ˇsirine in dolˇzine [8]. Danes smo z razvojem omreˇznih tehno- logij priˇca vedno veˇcji rabi ˇcasovnih vrst. Senzorji zelo hitro ustvarijo velike
5
Slika 2.1: Regularne in iregularne ˇcasovne vrste
koliˇcine podatkov, ki jih nato poˇsiljajo v omreˇzje [8]. Za primer vzemimo avto, ki je prikljuˇcen v omreˇzje. Vsako uro lahko avtomobil v delovanju poˇslje na streˇznik tudi do 25 GB podatkov [8]. Klasiˇcne relacijske podat- kovne baze morda niso veˇc najboljˇsa moˇznost za takˇsne koliˇcine in strukturo podatkov. Uveljavljati so se zaˇcele podatkovne baze za ˇcasovne vrste, ki podpirajo optimizirano zapisovanje podatkov in nudijo reˇsitev pri teˇzavah z razˇsirljivostjo.
Preden se poglobimo v arhitekturo in lastnosti podatkovnih baz za ˇcasovne vrste, moramo razumeti potek razvoja podatkovnih baz v celoti.
2.0.1 Relacijska podatkovna baza
Podatkovna baza je definirana kot organizirana urejena zbirka podatkov, ki je centralno raˇcunalniˇsko nadzorovana [10]. Struktura in zasnova podatkovne baze je odvisna od obravnavane problemske domene. Opiˇsemo jo v koncep- tualnem nivoju, kjer definiramo tip podatkov in oblikujemo entitete. Sistem upravljanja s podatkovno bazo je programska oprema, ki skrbi za upravljanje s fiziˇcnimi podatkovnimi bazami. Omogoˇca ustvarjanje, dodajanje, brisanje in agregacijo podatkov. Zadolˇzena je tudi za nadzor in dostop do podat- kov ter njihovo vzdrˇzevanje [10]. Po navadi se izraza uporabljata vzajemno, kajti sistem upravljanja s podatkovno bazo je pogojen z obstojem konkretne podatkovne baze in obratno.
Zasnovi, na kateri temelji podatkovna baza, kako deluje, kakˇsne podatke obravnava upravlja in na kakˇsen naˇcin opisuje povezave med njimi, pravimo podatkovni model. Najbolj znani podatkovni modeli so relacijski, mreˇzni, hierarhiˇcni in objektni. Tukaj se bomo posvetili relacijskemu modelu. Za relacijski podatkovni model je znaˇcilno, da je definiran formalno in temelji na matematiˇcnih relacijah [13]. Relacije so definirane na zaˇcetku ustvarjanja baze in so nespremenljive. Predstavljene so s tabelami, ki so zelo intuitivne pri delu in organizaciji. Vsaka tabela ima opredeljene entitete, ki jih opisu- jemo z atributi (npr. ime osebe, spol in starost).
Med posameznimi tabelami so povezave opredeljene s tujimi kljuˇci. Pri- marni kljuˇc v eni tabeli je tako lahko v drugi tuji kljuˇc in predstavlja moˇzno povezavo za zdruˇzevanje tabel pri izpolnjevanju poizvedb. Primer podat- kovne baze, ki uporablja relacijski model, je Postgres. Relacijske podatkovne baze lahko obravnavajo ˇcasovne vrste kot podatke, vendar po navadi niso tako dobro optimizirane za uˇcinkovito obdelovanje podatkovnih obremenitev, ki jih po navadi povzroˇcijo ˇcasovne vrste. Da bi podatkovna baza veljala za relacijsko, mora izpolnjevati lastnosti znane pod kratico ACID (atomicity, consistency, isolation, durability) [7, 11].
Vsaka transakcija je opredeljena kot ena ali veˇc logiˇcnih operacij, ki spre- minjajo ali dostopajo do vsebine podatkovne baze. Izvaja jih lahko neposre-
Slika 2.2: Primer relacije med dvema tabelama
dno uporabnik ali pa aplikacija. Lastnosti transakcij, ki zagotavljajo integri- teto podatkov in njihove znaˇcilnosti so:
• atomarnost (atomicity),
• konsistentnost (consistency),
• izoliranost (isolation),
• trajnost (durability).
Atomarnost transakcije narekuje, ali se bodo spremembe, ki jih povzroˇci tran- sakcija v celoti izvedle v podatkovni bazi, ali pa se sploh ne bodo. Banˇcniˇstvo je primer, kjer je zagotavljanje atomarnosti transakcije bistvenega pomena.
Pri prenosu sredstev med banˇcnimi raˇcuni, bo program odˇstel podani znesek
s prvega in priˇstel drugemu banˇcnemu raˇcunu. V primeru napake se transak- cija ne bo izvedla. Napake pri nakazilih, kjer bi sistem odˇstel z enega, nato pa ne bi priˇstel drugemu raˇcunu, so poslediˇcno onemogoˇcene.
Konsistentnost pove, da se transakcija lahko izvede zgolj v primeru, ˇce preide podatkovna baza iz enega konsistentnega stanja v drugo.
Izolacija pomeni, da so vmesne spremembe vsebine podatkovne baze vi- dne zgolj transakciji, ki operira nad temi podatki. SUPB z ustrezno imple- mentacijo podeljuje dostop nekemu viru zgolj eni transakciji, druge morajo poˇcakati, da se vir sprosti. Tako SUPB prepreˇcuje napake, kot sta stradanje in smrtni prijem (angl. deadlock).
Trajnost zagotavlja SUPB tako, da se spremembe zapiˇsejo na disk, preden se transakcija potrdi. Poslediˇcno se s tem prepreˇci izguba potrjenih podatkov.
Delovanje podatkovne baze je lahko optimizirano na razliˇcne naˇcine, po navadi z normalizacijo tabel ali dekompozicijo poizvedb. Pri optimiziranju poizvedb igrajo pomembno vlogo indeksi.
Indeks
Indeks je dodatna podatkovna struktura, ki omogoˇca hitrejˇse iskanje podat- kov, za ceno dodatnega zapisovanja in porabe prostora. Pri podatkovnih bazah za ˇcasovne vrste je znaˇcilno ustvarjanje indeksov na zapise v tabeli po ˇcasovni oznaki in atributih, ki tvorijo znaˇcko. Znaˇcka predstavlja mnoˇzico atributov na katerih ustvarimo indekse. Pri relacijskih podatkovnih bazah ustvarimo indeks na mnoˇzici atributov, ki skupaj tvorijo enoliˇcno identifi- kacijsko skupino, imenovano primarni kljuˇc (angl. primary key). Pri bazah tipa TSDB (angl. timeseries database) je primarni kljuˇc po navadi sestavljen iz ˇcasovne oznake in znaˇcke [1].
Podatkovne baze morajo zagotavljati doloˇceno stopnjo dostopnosti po- datkov. Ta mora biti zagotovljena v primeru odpovedi strojne ali program- ske opreme, izpada elektrike ipd. Zato si pri ustvarjanju arhitekture SUPB pomagajo z gruˇcenjem (angl. clustering).
Gruˇca
Gruˇca je predstavljena kot mnoˇzica vozliˇsˇc, ki sluˇzijo hranjenju podatkov z namenom zagotavljanja razpoloˇzljivosti podatkovne baze. Gruˇcenje vo- zliˇsˇc omogoˇca tudi redundantnost podatkov s pomoˇcjo sinhronizacije vozliˇsˇc.
Namen sinhronizacije vozliˇsˇc je prepreˇcevanje izgube podatkov v primeru od- povedi enega izmed vozliˇsˇc in zagotavljanje konsistentnosti podatkovne baze.
Implementirana je po principu gospodar-suˇzenj ali gospodar-gospodar [10].
2.0.2 Nerelacijska (NoSQL) podatovna baza
Nerelacijske podatkovne baze, imenovane tudi NoSQL [4], so nastale z opuˇsˇcanjem relacijskega modela in naˇcel ACID. Cilj je bil pridobivanje pri- lagodljive strukture za obravnavo problemskih domen, kjer niso jasno opre- deljene relacije med entitetami in je struktura podatkov spremenljiva. Po- datkovne baze NoSQL so namenjene uporabi pri problemih, kjer nastopajo velike koliˇcine nestrukturiranih ali polstrukturiranih podatkov [10].
Primer uporabe nerelacijskih podatkovnih baz so socialna omreˇzja. Apli- kacije za socialna omreˇzja zahtevajo veˇcji poudarek na skalabilnosti in raz- poloˇzljivosti, kot na primer na konsistentnosti [24].
Poleg socialnih omreˇzij je vedno veˇc spletnih aplikacij, z zahtevami po veˇcji skalabilnosti in razpoloˇzljivosti na raˇcun konsistentnosti. Zato se je na- mesto ACID uveljavil pristop BASE (Basically Available, Soft State, Even- tual Consistency) [10]. BASE narekuje naˇcelno razpoloˇzljivost, mehko stanje (opisuje stanje, kjer so podatki lahko nekonsistentni) in postopno konsistenco (nekatera vozliˇsˇca imajo toˇcne podatke, druga pa zastarele, ki postanejo kon- sistentni takrat, ko se nehajo spreminjati).
Veˇcina nerelacijskih podatkovnih baz je bila ustvarjena z namenom delo- vanja na gruˇcah raˇcunalnikov (vozliˇsˇcih), zato morajo biti odporne na napake [10]. Podatki se zato zapiˇsejo na veˇc vozliˇsˇc, tako da odpoved enega izmed vozliˇsˇc, ne vpliva na moˇznost dostopa do tega podatka. Temu postopku pravimo replikacija podatkov.
Med nerelacijskimi podatkovnimi bazami najdemo veliko odprtokodnih in imajo lasten poizvedovalen jezik, ter so dostopne pogosto preko API vmesnika [10].
Na podlagi podatkovnega modela lahko razporedimo nerelacijske podat- kovne baze v naslednje kategorije [10]: dokumentne shrambe, shrambe tipa razˇsirljiv zapis in shrambe tipa kljuˇc vrednost.
2.0.3 Lastnosti TSDB
Glavne lastnosti podatkovnih baz za ˇcasovne vrste, po katerih jih loˇcimo od ostalih, so [20]:
• zbiranje sorodnih podatkov na disku,
• hiter pregled nad ˇsirokim razponom velikega ˇstevila zapisov,
• upravljanje ˇzivljenjskega cikla podatkov,
• optimizirano zapisovanje v podatkovno bazo,
• posebne tehnike stiskanja podatkov,
• skalabilnost in uporabnost.
Podatkovna baza za ˇcasovne vrste hrani podatke znotraj istega ˇcasovnega intervala skupaj, kar omogoˇca hitre poizvedbe znotraj danega intervala. Pri- mer predstavlja iskanje vseh oseb med minimalno in maksimalno starostjo ali pa imena vseh zaposlenih s plaˇco nad dano vrednostjo v doloˇcenem obdobju.
Podatkovne baze za ˇcasovne vrste morajo zagotavljati visoko raz- poloˇzljivost in visoko zmogljivost operacij zapisovanja in branja podatkov.
Podatki imajo lahko visoko frekvenco beleˇzenja, kar ima za posledico po- trebo po uˇcinkovitejˇsi metodi stiskanja podatkov, kot jo nudijo navadne podatkovne baze. Podatkovne baze za ˇcasovne vrste nudijo postopke za zgoˇsˇcevanje podatkov z namenom uˇcinkovite porabe spomina. Primer ta- kega postopka je spreminjanje atributa ˇcasa. Namesto zapisovanja datuma do milisekunde natanˇcno za tisoˇce zapisov, se uporabi odmik od zaˇcetnega zapisa v milisekundah.
Sistem je skalabilen, ˇce se ob dodanih virih poveˇca njegova zmoˇznost obdelave veˇcje delovne obremenitve.
Podatkovne baze za ˇcasovne vrste vkljuˇcujejo funkcije in operacije, ki so povezane z analizo ˇcasovnih vrst in izpeljevanjem zakonitosti slednjih. Tukaj nastopajo poizvedbe, kot so ˇcasovna agregacija podatkov, pregledi nad po- datki v daljˇsem ˇcasovnem intervalu ipd. Pregledi (angl. scans) so poizvedbe
v podatkovni bazi, ki dostopajo do entitet, ki so omejene na interval vredno- sti doloˇcenega atributa. Primer je iskanje vseh vseh oseb starosti med 35 in 45 let ali osebe pod doloˇceno telesno viˇsino.
Podatkovne baze za ˇcasovne vrste pokrivajo veliko podroˇcij obravnave.
Nekatere od teh podroˇcij so: sistemski nadzori, omreˇzne tehnologije in po- datkovna analitika. Pri tem se arhitektura podatkovne baze za ˇcasovne vrste izogiba vsakemu morebitnemu izpadu podatkov tudi v primeru odpovedi po- sameznih vozliˇsˇc v omreˇzju ali strojne napake. Visok praga odpornosti na izpade in prilagodljivost arhitekture zniˇza stroˇske, ki lahko nastanejo zaradi prekinitev delovanja storitve. Pomembna je tudi implicitna vrednost TSDB, ki se kaˇze v tem, da velike koliˇcine podatkov, pridobljene v kratkem ˇcasu, omogoˇcajo ugotavljanje vzorcev in trendov v poslovanju in ekonomiki in po- slediˇcno omogoˇcajo podjetjem prednost pred tekmeci [20].
2.0.4 Zastarevanje podatkov
Osnova za obravnavo velikih koliˇcin podatkov je politika zastarevanja podat- kov. Poizvedbe nad novimi podatki so praviloma hitrejˇse kot nad starejˇsimi podatki [16]. Podatkovne baze za ˇcasovne vrste se lahko razlikujejo tudi po tem, ali je njena velikost spremenljiva [16]. ˇCe ˇzelimo pri nespremenljivi velikosti imeti pregled nad podatki v daljni preteklosti, moramo uporabiti povpreˇcenje podatkovnih toˇck v preteklosti ali neko drugo tehniko gruˇcenja podatkov. Poslediˇcno izgubimo veliko toˇck iz preteklosti. Arhitekturi, ki se hkrati osredotoˇca na aktualne in starejˇse podatke pravimo, Lambda arhitek- tura [16].
Slika 2.3: Arhitektura lambda [16]
Pregled izbranih performanˇ cnih testov
Izbira ustrezne podatkovne baze za ˇcasovne vrste je lahko zahtevna odloˇcitev, saj trenutno po nekaterih ocenah obstaja veˇc kot 70 podatkovnih baz za ˇcasovne vrste [5, 6]. Pri izbiri si pomagamo s performanˇcnim testom. Per- formanˇcni test je programska oprema, ki omogoˇca merjenje parametrov uˇcinkovitosti (npr. hitrosti operacij in porabe virov) znotraj nadzorovanega in definiranega okolja [5]. Pogosto se izbere neka lastnost ali skupina lastno- sti, po katerih razliˇcne baze zdruˇzimo v skupine, znotraj katerih jih nato primerjamo. Te lastnosti so lahko tip baze, funkcionalnost ali naˇcin gruˇcenja ipd [5]. Temu sledi sestava okolja (performanˇcnega testa), znotraj katerega testiramo baze. Po testiranju ovrednotimo baze glede na rezultate. Pri rezultatih moramo poleg uˇcinkovitosti upoˇstevati tudi druge kriterije (npr.
sintaksa poizvedovalnega jezika, enostavnost nameˇsˇcanja).
V nadaljevanju bomo predstavili nekaj primerov performanˇcnih testov.
Prvo podpoglavje opisuje zgradbo univerzalnega performanˇcnega testa, ki podpira testiranje vseh podatkovnih baz za ˇcasovne vrste. Drugo podpo- glavje opisuje performanˇcni test za specifiˇcno domeno – sistem nadzora one- snaˇzevanja voda. Tretje podpoglavje opisuje orodje za testiranje performanc podatkovnih baz pri vetrnih elektrarnah.
15
3.0.1 Univerzalni performanˇ cni test
Bader v delu Primerjava podatkovnih baz za ˇcasovne vrste [6] naˇsteva skupno 75 podatkovnih baz za ˇcasovne vrste (od tega 42 odprtokodnih). V tem delu so zasledili pomanjkanje orodij oziroma performanˇcnih testov za primerjavo med bazami za ˇcasovne vrste. Naˇsli so zgolj tri taka orodja (STAC-M3 BEN- CHMARK SUITE, FinTime in TSDB Bench), ki pa podpirajo delo z le nekaj bazami. Poslediˇcno so imeli za nalogo ustvarjanje sploˇsnega performanˇcnega testa, ki bi podpiral vse podatkovne baze in jih nato primerjal med seboj.
Z vidika implementacije so zasnovali performanˇcni test kot program, ka- terega gradniki nadzirajo generiranje podatkov, nabor operacij, ki se izvajajo nad njimi in vmesnik za interakcijo med aplikacijo in podatkovno bazo, kar je razvidno iz slike 3.1.
Slika 3.1: Predlog naˇcrta za performanˇcni test [6]
Performanˇcni test je napolnil podatkovne baze iste vrste na veˇc vozliˇsˇcih, izvedel poizvedbe in izmeril iskane koliˇcine, kot sta hitrost in prostorska po- raba. Posamezna podatkovna baza je bila napolnjena z 1000000 vrsticami zapisov. Vsak zapis je bil sestavljen iz ˇcasovne znaˇcke in simulacijo meritve, ki jo je opravil senzor (ˇstevilo zapisano v plavajoˇci vejici med 0 in 10000), ter treh znaˇck. Meritve so bile generirane nakljuˇcno. Znaˇcke so bile sestavljene iz nakljuˇcno ustvarjenih alfanumeriˇcnih nizov iste dolˇzine. ˇCasovne znaˇcke so bile izbrane med dvema datumoma v preteklosti, z vmesnim korakom dolˇzine 1000 milisekund. Performanˇcni test sta sestavljali dve fazi.
V prvi fazi se je podatkovna baza napolnila s podatki. Pri tem so za za- pisovanje v podatkovne baze uporabljeni posameznimi ukazi INSERT, kajti namen tega je bil simulirati poˇsiljanje meritve posameznega senzorja na streˇznik-vozliˇsˇce. Funkcije za vstavljanje podatkov v sveˇznju niso bile upo- rabljene. Postopek pisanja v podatkovno bazo je bil ponovljen 1000-krat.
Druga faza je predvidevala branje iz podatkovne baze in ˇstiri funkcije agregacije (funkcije SCAN, COUNT, AVERAGE, SUM). V primeru branja je bila poizvedba 1000-krat ponovljena, v primeru agregacije pa vsaka funk- cija po 250-krat. Na koncu so bili predstavljeni rezultati in primerjave med najveˇcjo in najmanjˇso ter povpreˇcno hitrostjo izvedbe in porabe spomina.
Poudarek je bil na poizvedbah, ki so se uspeˇsno zakljuˇcile. Po izvajanju per- formanˇcnega testa so s pomoˇcjo sistema toˇckovanja ovrednotili posamezne podatkovne baze. Med njimi so bile najuspeˇsnejˇse:
• Druid,
• Rhombus,
• OpenTSDB,
• InfluxDB.
3.0.2 Performanˇ cni test za specifiˇ cno domeno
V uvodu je bil opisan primer, kjer je kanadska univerza pomagala pri vzpo- stavitvi sistema za nadzor kakovosti vode, s katerim bi upravljala lokalna skupnost [15]. Sistem je predvideval namestitev senzorjev za zaznavanje prisotnosti razliˇcnih strupenih snovi v vodi in aplikacijo, ki bi omogoˇcala shranjevanje podatkov na streˇznik. Podatke, ki so jih ustvarjali senzorji, so se shranjevali na cenovno ugoden streˇznik Arduino Raspberry Pi, ki je lahko sprejemal podatke 450 senzorjev. Teˇzava je nastala pri izbiri podatkovne baze.
Preden so se lotili implementacije performanˇcnega testa, so morali upoˇstevati ˇse nekaj drugih lastnosti podatkovnih baz. Pri izbiri so morali med drugim upoˇstevati tudi, ali baza podpira delo s ˇcasovnimi vrstami in ali jo je moˇzno namestiti na streˇznik Arduino Raspberry Pi. Izbira baze z najboljˇsimi rezultati testov, je lahko neustrezna, ˇce je ni mogoˇce namestiti na ˇzeleni streˇznik. Predpogoje za test so izpolnjevale naslednje naslednje baze:
• OpenTSDB,
• InfluxDB,
• ElasticSearch,
• Kdb+,
• RRDtool,
• Graphite,
• Prometheus,
• DalmatinerDB.
Po opravljenem testu so se pokazale prednosti posameznih baz, glede na hitrost, zasedanje spomina in virov. Prednost je imela podatkovna baza Ela- sticSearch vendar so na koncu izbrali podatkovno bazo InfluxDB. Odloˇcili
so se za podatkovno bazo InfluxDB, kajti pri poveˇcevanju ˇstevila senzorjev skozi ˇcas, se poraba spomina RAM in zasedenosti CPU poveˇcuje premoso- razmerno, kar je razvidno iz grafov na slikah 3.2 in 3.3. Za razliko od ostalih podatkovnih baz, InfluxDB omogoˇca tudi naprednejˇse analitiˇcne funkcije in agregacije rezultatov. Slednje omogoˇca laˇzje upravljanje s podatki osebam, ki prihajajo iz ne tehniˇcnega ozadja [15]. Na odloˇcitev so vplivali tudi od- prtokodnost, enostavnost nameˇsˇcanja in majhna poraba virov za nemoteno delovanje na streˇzniku Raspberry Pi.
Slika 3.2: Poraba pomnilnika pri InfluxDB [15]
Slika 3.3: Zasedenost CPU pri InfluxDB [15]
3.0.3 Orodje za primerjavo podatkovnih baz za ˇ casovne vrste v industriji
V uvodu smo omenili primer uporabe senzorjev in ˇcasovnih vrst pri vetrnih elektrarnah [18]. Pri izbiri podatkovne baze za ta scenarij, je bilo upora- bljeno orodje za performanˇcno testiranje IoTDB-Benchmark, ki je bilo pose- bej razvito za podatkovne baze za ˇcasovne vrste. Na sliki 3.4 lahko vidimo arhitekturno zasnovo tega orodja, kjer lahko opazimo elemente, kot so generi- ranje in shranjevanje testnih mnoˇzic, vmesnik za upravljanje s podatkovnimi bazami in nadzor odjemalcev. Na sliki 3.5 lahko zasledimo postopke pri tem orodju, ki obsegajo postopek, kjer se vzpostavi testno okolje. Nato testirajo uˇcinkovitost zapisovanja ter branja iz baze. Pomemben del, ki nastopa na tem mestu, je nadzor sistema, ki omogoˇca vzdrˇznost testne mnoˇzice. Slednje nam omogoˇca veˇckratno ponavljanje testov pri istih pogojih, brez potrebe po ponovnem generiranju testne mnoˇzice.
Za izbrani scenarij so primerjali ˇstiri podatkovne baze za ˇcasovne vrste:
• InfluxDB,
• OpenTSDB,
• KairosDB,
• Timescale.
Slika 3.4: Arhitektura orodja IoTDB-Benchmark [18]
Performanˇcni test je poleg vstavljanja podatkov zajemal tudi poizvedbe kot so:
• poizvedba znotraj doloˇcenega ˇcasovnega razpona,
• iskanje najveˇcjega elementa ali povpreˇcja,
• poizvedovanje po elementih med dvema vrednostima,
• kombinacija slednjih.
Pri poizvedbah je orodje spremljalo naslednje koliˇcine za posamezno po- datkovno bazo:
• ˇcas izvrˇsevanja poizvedbe,
• ˇstevilo vnosov proti ˇcasu izvrˇsevanja,
• prostorska poraba,
• poraba sistemskih virov.
Slika 3.5: Postopki pri orodju IoTDB-Benchmark [18]
Pri rezultatih testiranja pisanja v podatkovno bazo, poizvedovanju zno- traj ˇcasovnega intervala in porabi spomina sta bila v prednosti podatkovni bazi InfluxDB in Timescale. Pri iskanju posameznega elementa (toˇcke), najveˇcjega elementa in povpreˇcja elementov je bila najhitrejˇsa podatkovna baza KairosDB.
Metodologija
4.1 Predstavitev podatkovnih baz
Za izvedbo performanˇcnega testa je bilo potrebno izbrati mnoˇzico podatkov- nih baz, ki bodo predmet testiranja. Vodilo pri izboru podatkovnih baz je bila zastopanost razliˇcnih tipov podatkovnih baz z namenom ugotavljanja njihovih lastnosti v doloˇcenem testu. Uporabljene so bile podatkovne baze, ki so se pojavljale pri obstojeˇcih testih (predstavljenih v poglavju 3). Po- membno vlogo pri izbiri podatkovne baze je imelo tudi dejstvo ali je doloˇcena podatkovna baza odprtokodna ali plaˇcljiva. Na podlagi teh kriterijev so bile izbrane tri podatkovne baze, dve relacijski (Postgres, Timescale) in ena ne- relacijska (InfluxDB).
23
4.1.1 Postgres
Postgres je odprtokodna objektno-relacijska, ki je nastal leta 1996 kot nasle- dnik Ingresa. Podpira sintakso in funkcionalnosti standardov SQL. Omogoˇca delo s proˇzilci, postopki (angl. procedures) in tujimi kljuˇci. Postgres je ustvarjen z namero zagotavljanja skalabilnosti, razˇsirljivosti, zdruˇzljivosti standardov in konsistentnosti podatkov. Na voljo je za operacijske sisteme Windows in Linux.
Namestitev je preprosta. Z uradne spletne strani podatkovne baze Po- stgres [9] prenesemo izvrˇsljivo datoteko, ki jo nato zaˇzenemo. Postopek nato zahteva ime in geslo za bazo, ter ˇstevilko vrat, na katerih bo prikljuˇcen streˇznik. Trenutno je najsodobnejˇsa razliˇcica Postgres 13, vendar je za name- stitev razˇsiritve Timescale potrebna razliˇcica 11 ali 12, saj za najsodobnejˇso ˇse ni na voljo razˇsiritev Timescale. Pot do mape z zagonskimi datotekami je na koncu potrebno ˇse dodati v sistemsko spremenljivko Path. Po namestivi, je moˇzno izvajati poizvedbe preko terminala z ukazom psql -U postgres po- stgres (v tem primeru sta privzeti imeni za bazo in uporabnika postgres) ali z grafiˇcnim vmesnikom PG4, ki ga najdemo v mapi postgres pod mapo bin.
Kot je razvidno na sliki 4.1, PG4 nudi grafiˇcni vmesnik s hierarhiˇcno dreve- sno strukturo, ki omogoˇca hitro navigacijo med elementi (tabelami, postopki, orodji) kot tudi orodje za poizvedovanje.
Kot osnovne podatkovne tipe, ki so potrebni za obravnavo ˇcasovnih vrst, uporablja:
• za nize VARCHAR (50), z dolˇzino, ki jo podamo kot argument znotraj oklepajev,
• za ˇstevila tip NUMERIC (5,2), kjer prva ˇstevilka znotraj oklepajev po- meni ˇstevilo ˇstevk, druga pa natanˇcnost (brez argumentov lahko spre- jema vse tipe ˇstevil),
• TIMESTAMP - ˇcasovno oznako.
Slika 4.1: Grafiˇcni vmesnik za podatkovno bazo Postgres
4.1.2 Timescale
Timescale je odprtokodna razˇsiritev za podatkovno bazo Postgres, ki je op- timizirana za delo s ˇcasovnimi vrstami in njihovo analizo.
Timescale uporablja hipertabele (angl. Hypertable) kot abstraktno plast in glavno toˇcko, skozi katero poteka interakcija s podatki, kot je ustvarjanje tabel, indeksov, spreminjanje tabel, dodajanje in izbiranje podatkov. Hi- pertabele se nato samodejno razdeli po ˇcasovni znaˇcki znotraj doloˇcenega intervala in tako tvori kose podatkov (angl. chunks of data). Hipertabela predstavlja abstraktno podatkovno strukturo. To pomeni, da se spremembe posredujejo naprej do posameznih kosov. Timescale je zdruˇzljiv s poizvedo- valnim jezikom SQL. ˇCasovne vrste v hipertabelah se lahko kombinirajo z relacijskimi podatki v navadnih tabelah s pomoˇcjo operacij JOIN. Najprej ustvarimo navadno tabelo z ukazi:
CREATE TABLE vozila(
casovna_znacka TIMESTAMPTZ NOT NULL, id_vozila INTEGER,
prevozena_razdalja FLOAT );
Nato jo pretvorimo v hipertabelo z danimi argumenti (ime tabele, ime ˇcasovne komponente in ˇcasovni interval med kosi):
SELECT * FROM create_hypertable(’vozila’, ’casovna_znacka’, chunk_time_interval => INTERVAL ’1 day’);
4.1.3 InfluxDB
InfluxDB je odprtokodna podatkovna baza za ˇcasovne vrste. Napisana je v programskem jeziku Go. Optimizirana je za hranjenje in poizvedovanje ˇcasovnih vrst. InfluxDB se uporablja pri nadzoru raˇcunalniˇskih sistemov, aplikacijski metriki, senzoriˇcnih podatkih IoT in realno ˇcasovnih analitikah.
V osnovi podpira delo s tabelami podobno kot pri podatkovni bazi Postgres, vendar s to razliko, da zaradi svoje nerelacijske arhitekture ne podpira stika- nja tabel s funkcijo JOIN. Zato je bolj ustrezna za delo s polstrukturiranimi ali nestrukturiranimi podatki in entitetami, med katerimi ne priˇcakujemo ve- liko logiˇcnih povezav. To pomeni, da je bolj primerna za scenarije, kjer se po- javljajo zahteve po zapisu velikih koliˇcin podatkov v zelo kratkem ˇcasovnem obdobju.
Podatkovno strukturo pri podatkovni bazi InfluxDB lahko ponazorimo na primeru iz prevozniˇstva [8]. Zanimajo nas podatki kot so ime voznika, ˇstevilo prevoˇzenih oseb, lokacija vkrcanja, v katero starostno skupino spadajo in seveda ˇcas, v katerem je bil podatek ustvarjen – ˇcasovna znaˇcka. V tabeli 4.2 so prikazani podatki, s katerimi bomo ponazorili delovanje baze InfluxDB.
Slika 4.2: Primer tabele ˇcasovnih vrst [1]
V literaturi o TSDB se za posamezno meritev oziroma vrstico (entiteto) v tabeli uporablja izraz toˇcka. Izraz je prisoten tudi v dokumentaciji baze InfluxDB [1]. V prvem stolpcu je ˇcasovna oznaka, naslednja atributa (stolpca otroci in odrasli) spadata v mnoˇzico polj. Naslednja dva atributa (stolpca lokacija in voznik) skupaj tvorita znaˇcko. Razlika med poljem in znaˇcko je v tem, da znaˇcka skupaj z atributom ˇcasa tvori primarni indeks, kar pomeni, da so poizvedbe po njih hitrejˇse. Politika zastarevanja (angl. retention policy) narekuje, koliko ˇcasa se bo vnos hranil v podatkovni bazi in koliko kopij slednjega se bo hranilo v njej. Podatkom s privzeto politiko zastarevanja, ki po navadi oznaˇcuje neskonˇcno trajanje podatka brez replikacije, pravimo autogen.
4.2 Opis kriterijev
Vlogo pri odloˇcanju glede izbire podatkovne baze igrajo razliˇcni kriteriji, ki se pojavljajo v ˇstevilnih virih [5, 6, 19]. Vsem omenjenim virom je skupno merjenje hitrosti izvrˇsevanja operacij nad podatkovnimi bazami (branje in za- pisovanje v podatkovno bazo) in porabo diskovnega prostora. Poleg slednjih smo upoˇstevali tudi nekatere nemerljive kriterije (npr. enostavnost poizve- dovalnega jezika). Na koncu smo primerjali podatkovne baze z naslednjimi kriteriji:
• enostavnost poizvedovalnega jezika,
• podroˇcje uporabe - problemska domena,
• koliˇcina in vrsta podatkov, ki se zapisujejo v podatkovno bazo,
• stroˇski licence in vzdrˇzevanja podatkovnih baz,
• hitrost operacij nad podatki in poraba spomina.
4.2.1 Enostavnost poizvedovalnega jezika
Poizvedovalni jezik – query language, kot se pojavlja v literaturi [8], je jezik, ki ga uporablja programska oprema za interakcijo s podatkovno bazo. Pred- stavlja ga nabor ukazov za opis oziroma definiranje podatkov (npr. CRE- ATE, ALTER, DROP) imenovano DDL (angl. data definiton language).
Nabor ukazov za ravnanje s podatki (npr. SELECT, INSERT, DELETE, UPDATE), pa imenujemo DML (angl. data manipulation language). Pri izbiri podatkovne baze za doloˇceno domeno je pomembno, ali razvijalci po- znajo poizvedovalni jezik, ki ga podatkovna baza uporablja [19]. V literaturi pogosto zasledimo ˇzeljo, da bi poizvedovalni jezik ˇcim bolj spominjal na je- zik SQL, zaradi razˇsirjenosti in preprostosti [10]. Tako je potrebno pri izbiri podatkovne baze za doloˇceno domeno poskrbeti, da so razvijalci seznanjeni z jezikom izbrane podatkovne baze [19].
4.2.2 Podroˇ cje uporabe - problemska domena
Podroˇcje uporabe oziroma problemska domena zajema mnoˇzico scenarijev, kjer so obravnavani podatki ˇcasovne vrste. Razliˇcna podroˇcja imajo lahko razliˇcno frekvenco ˇcasovno ˇzigosanih podatkov. Sprva se odloˇca, katera arhi- tektura je ustreznejˇsa relacijska ali nerelacijska. Relacijska podatkovna baza je smiselna v primeru, ko so jasne relacije med entitetami, so nespremenljive in vnaprej znane. Primer uporabe je knjiˇznica. Moˇzne entitete so knjiga, uporabnik, podruˇznica, izvod. Povezave med entitetami opisujejo relacije.
Uporabnik si lahko izposodi doloˇcen izvod knjige v dani podruˇznici. Prav tako so atributi, ki opisujejo entitete nespremenljivi - naslov, leto izdaje, ime avtorja, status ali je izposojena in kateri izvod je bil izposojen. Primer knjiˇznice je naveden kot klasiˇcen scenarij za relacijski model, vendar pri njem ne nastopajo ˇcasovne vrste.
V primeru, da domena zahteva jasno opredeljene relacije med entitetami pomeni, da bo pri interakciji s podatkovno bazo priˇslo do zdruˇzevanja veˇc tabel (operacija JOIN). V tem primeru je pomembna izbira baze, ki podpira take operacije, kot je na primer Postgres. InfluxDB po drugi strani ne podpira takih operacij in je poslediˇcno neustrezen za take domene.
Domena, kjer nastopajo ˇcasovne vrste so ˇze omenjene taksi sluˇzbe. Tukaj so na voljo tako relacijske kot nerelacijske podatkovne baze, ki so lahko tipa TSDB. Tudi ˇce podatkovna baza ni tipa TSDB, ˇse ne pomeni, da je neu- porabna pri obravnavi ˇcasovnih vrst. Pomembno je le, da omogoˇca ˇcasovno ˇzigosanje in zdruˇzevanje po ˇcasu. Primer je replikacijska arhitektura streˇznika MySQL z namenom shranjevanja ˇcasovnih vrst, kjer je izmerjena uˇcinkovitost podobna podatkovnim bazam tipa TSDB [18].
4.2.3 Koliˇ cina in vrsta podatkov, ki se zapisujejo v po- datkovno bazo
Za obˇcutek glede mnoˇziˇcnosti podatkov je dober primer socialno omreˇzje Facebook, ki je leta 2009 objavilo, da je na njegovem omreˇzju pribliˇzno 60
milijard slik, kar skupaj znese pribliˇzno 1,5 petabajta spomina, s 350 milijoni uporabniki [10]. 11 let pozneje pri 2,5 milijarde uporabnikov je ˇstevilo naraslo na pribliˇzno 250 milijard. Tako je primer nalaganja spletne strani, kjer se tekoˇce objave pojavijo takoj, starejˇse pa lahko potrebujejo tudi nekaj sekund, ne predstavlja posebne teˇzave. V primeru banˇcniˇstva pa je nujno takojˇsnje razpolaganje z vsemi podatki o transakcijah. Poslediˇcno koliˇcina in hitra obdelava podatkov vpliva na izbor ustrezne podatkovne baze.
Vrsta podatkov je tudi vodilo, pri izbiri ustrezne podatkovne baze. V primeru, da imamo opravka s polstrukturiranimi (npr. XML, e-poˇsta) ali ne- struktruturiranimi podatki (golo besedilo, slike, zvok, posnetki) se odloˇcimo za podatkovne baze tipa NoSQL. V primeru strukturiranih podatkov v ta- belah, pa se uporabljajo relacijske podatkovne baze [10].
4.2.4 Stroˇ ski licence in vzdrˇ zevanja podatkovnih baz
Pri izbiri podatkovne baze za doloˇceno aplikacijo je pomemben kriterij cena.
Programska oprema je lahko odprtokodna ali plaˇcljiva. Pri obeh je potrebno upoˇstevati, ali ima oprema ustrezno podporo, kot je recimo dolgoroˇcno pod- poro (angl. long-term support) in ali je potrebno dokupiti licence za zunanje odvisnosti. Pri izbiri na videz poceni podatkovne baze je potrebno paziti tudi na skrite stroˇske, ki lahko nastanejo zaradi morebitne nezdruˇzljivosti zuna- njih orodij in je nato potrebno dodatno programiranje na podroˇcju aplikacije oziroma vmesnika [6].
4.2.5 Hitrost operacij nad podatki in poraba spomina
Veˇcina primerjav se po pregledu prejˇsnjih kriterijev konˇca s testiranjem zmo- gljivosti. Zmogljivost se po navadi odraˇza v tem, kako hitro lahko podatkovna baza opravi neko operacijo pri ˇcim manjˇsi porabi pomnilnika in ostalih virov (CPE). Z inˇzenirskega vidika bi ta dva dejavnika morala biti odloˇcilna (se- veda pri enakovrednih lastnosti arhitekture, sheme baze ipd.), vendar lahko eden izmed prejˇsnjih kriterijev, kot sta stroˇski programske opreme ali sinta- ksa poizvedovalnega jezika dobi prednost pri izbiri.
4.3 Vzpostavitev testnega okolja
Primerjava uˇcinkovitosti med podatkovnimi bazami (Postgres, Timescale, InfluxDB) je bila izvedena s performanˇcnim testom na realnem primeru z uporabo ˇcasovnih vrst. Obravnavani primer je bil izbran iz domene av- toprevozniˇstva (taksi sluˇzbe), kjer se zajemajo podatki skozi ˇcas (ˇcasovno ˇzigosanje) in prevladujejo operacije s pomoˇcjo ˇcasovne komponente.
Pri testiranju lastnosti posameznih baz nismo imeli na voljo senzorjev, obstojeˇce baze podatkov ali aplikacije, kot je to znaˇcilno za take primere testov, zato smo se odloˇcili, da bomo infrastrukturo sistema simulirali. Per- formanˇcni test je zato moral ustvariti testno mnoˇzico podatkov, znaˇcilnih za to domeno (lokacija, vrednosti senzorjev ipd.), jih zapisati na streˇznik in opraviti izbrano mnoˇzico operacij nad njimi za vse tri baze.
Poglavitna kriterija za ugotavljanje uˇcinkovitosti baz, ki ju obravnava per- formanˇcni test [22] sta hitrost izvajanja operacij in velikost spomina, ki jo zasedajo tabele posameznih baz, pri velikih koliˇcinah podatkov. Poleg obrav- navanih kriterijev bodo omenjeni ˇse nekateri, kot sta jezik in uporabniˇska izkuˇsnja, vendar ne izˇcrpno, saj to presega meje teme te diplomske naloge.
4.4 Zgradba performanˇ cnega testa
Performanˇcni test je bil sestavljen iz treh delov, kot to prikazuje slika 4.3.
Prvi del predstavlja program, ki je bil zadolˇzen za ustvarjanje podatkov.
Ustvarjene podatke nato zapiˇse v datoteko tipa csv. V drugem delu program prebere podatke iz datoteke in jih zapisuje v podatkovno bazo na streˇzniku.
Podatki se pri tem zapisujejo v enakomernih intervalih v podatkovno bazo.
Program zapiˇse podano ˇstevilo vrstic v podatkovno bazo, izmeri trajanje in nato izbriˇse podatke v podatkovni bazi. Potem izraˇcuna in shrani povpreˇcje desetih ponovitev izvajanja za vsako ˇstevilo zapisanih vrstic. Tretji del po- teka enako kot drugi s to razliko, da meri povpreˇcen ˇcas izvajanja operacij branja in agregacije, ter brisanja. Na koncu program izriˇse grafe ˇcasa izva- janja za posamezno operacijo.
Slika 4.3: Shema performanˇcnega testa
Performanˇcni test je ustvarjen v programskem jeziku python. Python ima veliko ogrodij in knjiˇznic za ustvarjanje spletnih aplikacij kot so na primer Django ali Flask, kot tudi odjemalcev za delo z bazami (med drugim tudi za primerjane baze Postgres, InfluxDB).
Testiranje baz je bilo izvajano na streˇzniku z naslednjimi specifikacijami:
• CPE 64-bitni sistem,
• 2 GB RAM,
• 20 GB SSD.
Izvedba testiranja
Uporaba ˇcasovnih vrst na podroˇcju prevozniˇstva je ena izmed najbolj znaˇcilnih primerov uporabe, kjer nastopa ta vrsta podatkov [8]. Prevozna podjetja kot npr. Uber potrebujejo uˇcinkovito programsko opremo, ki jim bo omogoˇcala pregled nad poslovanjem. Poslovanje pri takih podjetjih po- gosto vkljuˇcuje opravila, kot so ugotavljanje frekvence prevoza potnikov na doloˇcenih linijah, poˇsiljanje vozila, ki je najbliˇzje stranki, spremljanje pri- hodkov ipd. Tukaj bomo predstavili tipiˇcne operacije nad podatkovno bazo, ki so znaˇcilne za poslovanje taksi sluˇzbe. Za podatkovne baze v prometu je znaˇcilno spremljanje spreminjanja lokacije vozila, prevoˇzena razdalja (tudi stanje rezervoarja), zaradi uˇcinkovitega gospodarjenja podjetja. Pri taksi sluˇzbah je zelo pomembna tudi zaraˇcunana cena za voˇznjo, zaradi obraˇcuna davkov. Prav tako je pomemben podatek glede ˇstevila prevoˇzenih potnikov, saj pomaga pri ugotavljanju trenda povpraˇsevanja in prikaz povpraˇsevanja po posameznih delih dneva, tedna in fiskalnih delih leta.
Podatki so shranjeni v tabeli vozila, ki vsebuje atribute z imeni:
id voznika, zaˇcetno lokacijo, konˇcno lokacijo, ˇstevilo potnikov, razdaljo, ceno in ˇcasovno znaˇcko. Za izvedbo performanˇcnega testa bomo uporabili na- kljuˇcno generirane testne podatke, ki so s staliˇsˇca testiranja zmogljivosti enakovredni realnim podatkom o prevozih. Lastnosti teh podatkov so:
• ˇsifre posameznih vozil so zavzemale vrednosti med ˇstevili 0 in 1000, 37
• vrednosti atributov razdalje in cene so bile generirane med 0 in 20, saj smo sklepali, da je realna dolˇzina poti, ki jih opravi nekje v tem obmoˇcju,
• zaloga vrednosti za atribut ˇstevilo potnikov je na intervalu (0, 4],
• vstopna in izstopna lokacija sta bili generirani kot alfanumeriˇcna niza (skupno se je v testni mnoˇzici pojavljalo 10000 enakomerno porazde- ljenih vstopnih in izstopnih lokacij).
5.1 Opis uporabljenih operacij
Pri performanˇcnem testu smo uporabili operacije, ki so lahko v pomoˇc pri obravnavani domeni taksi sluˇzbe (npr. raˇcunanje povpreˇcnih meseˇcnih raz- dalj ali meseˇcnih prihodkov).
Operacije smo izvajali pri razliˇcnih koliˇcinah podatkov (od nekaj tisoˇc do milijon vrstic). Prav tako je bilo opazovano kako ustvarjanje ustreznih indeksov vpliva na rezultate (pri podatkovnih bazah Postgres in Timescale).
Podatkovna baza InfluxDB ne podpira ustvarjanja indeksov. Ustvarjanje operacij pri podatkovnih bazah Postgres in Timescale ni predstavljalo teˇzave, saj oba uporabljata poizvedovalni jezik SQL. Po drugi strani pa je InfluxDB s prehodom z verzije 1.X na 2.X prenehal z uporabo jezika InfluxQL (soroden SQL) in preˇsel na novi poizvedovalni jezik Flux. Flux ima posebno sintakso, ki jo poleg novega grafiˇcnega vmesnika (Influx Data Explorer), mora posa- meznik osvojiti, preden lahko zaˇcne sestavljati operacije enakovredne tistim v jeziku SQL. Na tem mestu se spomnimo na obravnavane kriterije pri izbiri ustrezne baze za doloˇcen projekt iz prejˇsnjih poglavij. Obˇcutna sprememba sintakse jezika neke programske opreme lahko negativno vpliva na projekt (zamude, stroˇski dodatnega usposabljanja), kar poslediˇcno lahko vpliva na izbiro neke baze.
Povezovanje programa z bazo je bilo zelo enostavno, saj python vsebuje knjiˇznice in odjemalce za povezovanje z vsemi tremi bazami. Pri podatkov-
nih bazah Postgres in Timescale se uvozi knjiˇznica za povezovanje z njim imenovana psycopg2. Nato se ustvari instanca tega razreda, ki se mu podajo argumenti: ime baze, ip, geslo in vrata. Nato se ustvari instanca kazalca, ki izvede poizvedbo, zapisano kot spremenljivka v nizu. Na podoben naˇcin ustvari tudi instanco odjemalca za InfluxDB imenovano influxdbclient. Sle- dnji je do neke mere olajˇsal teˇzave s sintakso Fluxa, saj ima vgrajene nekatere osnovne funkcije API, kot sta zapisovanje in brisanje podatkov.
Z upoˇstevanjem naˇstetih lastnosti podatkovnih baz in omejitev strojne opreme (posebej pri koliˇcini obravnavanih podatkov) smo testirali naslednje operacije nad podatkovno bazo:
• zapisovanje podatkov v podatkovno bazo,
• brisanje podatkov,
• branje podatkov znotraj ˇcasovnega intervala,
• raˇcunanje meseˇcnih vsot za doloˇcen atribut,
• raˇcunanje meseˇcnih povpreˇcij za doloˇcen atribut,
• iskanje minimalnih/maksimalnih vrednosti,
• kompleksna poizvedba.
5.1.1 Zapisovanje podatkov v podatkovno bazo
Merjenje uˇcinkovitosti zapisovanja podatkov v podatkovno bazo je bilo izve- deno na dva naˇcina.
• Klasiˇcno zapisovanje posameznih vrstic z uporabo ukaza za vstavljanje INSERT.
• Zapisovanje podatkov v sveˇznju (angl. batch insert).
Zapisovanje podatkov v sveˇznju je optimizirana metoda pisanja v po- datkovno bazo, ki se uporablja, ko moramo zapisati veˇcje koliˇcine podatkov naenkrat. Prednost te metode se kaˇze v tem, da ustvari eno instanco objekta za povezavo do podatkovne baze in prenos veˇcje koliˇcine podatkov, namesto da bi ustvarjala nove instance objekta, za vnos vsake vrstice v podatkovno bazo. Pri podatkovnih bazah Postgres in Timescale je bilo to doseˇzeno z ukazom:
COPY vozila(id_vozila, lokacija_zacetna, lokacija_koncna, razdalja, cena, potniki, casovna_znacka)
FROM ’/tmp/benchmark0.csv’
DELIMITER ’,’;
oziroma s pomoˇcjo funkcije pythonovega odjemalca:
cur.copy_from(f, ’vozila’, columns=(
’id_vozila’, ’lokacija_zacetna’,
’lokacija_koncna’,’razdalja’,
’cena’,’potniki’,’casovna_znacka’), sep=",").
Tudi podatkovna baza InfluxDB omogoˇca zapisovanje podatkov v sveˇznju.
Sveˇznje zapisujemo s funkcijo:
write_api.write(bucket=’bucket-by-python’, record=data)
Spremenljivka data predstavlja seznam objektov razreda Point.
Testirali smo razliˇcne primere zapisovanja podatkov v podatkovno bazo iz realnega ˇzivljenja. Vsak test je bil ponovljen z indeksi pri podatkovnih bazah Postgres in Timescale. Indeksi so bili ustvarjeni na atributih ˇsifre vozila in ˇcasovne znaˇcke.
Testiranje je obsegalo:
• zapisovanje s podatki, urejenimi po ˇcasovni znaˇcki,
• zapisovanje, kjer so bili zapisi neurejeni glede na ˇcasovno znaˇcko.
5.1.2 Brisanje podatkov
Pri obravnavi ˇcasovnih vrst se pogosto sreˇcujemo s primeri, kjer zaradi po- manjkanja prostora ali narave dela hranjenje starejˇsih podatkov ni veˇc nujno.
Zato imajo nekatere podatkovne baze za ˇcasovne vrste implementirano zasta- revanje podatkov (angl. retention policy), ko po doloˇcenem ˇcasu samodejno izbriˇse stare podatke (npr. InfluxDB). Implementacija politike zastarevanja
je odvisna od uˇcinkovite funkcije brisanja podatkov. Politika zastarevanja omogoˇca samodejno brisanje zastarelih podatkov. Administratorji poslediˇcno porabijo manj ˇcasa kot, ˇce bi morali roˇcno brisati podatke na vsakih nekaj dni. Prav tako je bil izveden test z uporabo indeksov pri podatkovnih bazah Postgres in Timescale. Indeksi so bili ustvarjeni spet na atributih ˇsifre vozila in ˇcasovni znaˇcki.
Pri podatkovni bazi Postgres podatke briˇsemo s pomoˇcjo ukaza:
DELETE FROM vozila;
V tem primeru je bil uporabljen ukaz DELETE, saj ohranja strukture ta- bele in briˇse podatke lahko glede na izbran ˇcasovni interval (mora prebrati vsako vrstico, ki ustreza pogojem, pred izbrisom za razliko od ukaza DROP TABLE). Timescale po drugi strani ponuja funkcijo, ki izbriˇse podatke po kosih:
SELECT drop_chunks(INTERVAL ’24 hours’,’vozila’);
Za brisanje podatkov pri podatkovni bazi InfluxDB je poskrbel pythonov odjemalec z ˇze vgrajeno funkcijo
delete_api = client.delete_api() delete_api.delete(
start, stop, ’_measurement="vozila"’, bucket=’bucket-by-python’,
org=’diploma’)
.
5.1.3 Bralne operacije
V tem poglavju bodo opisane izvedene bralne in agregacijske operacije, ki so bile testirane. Opisani so tudi ponovljeni testi z uporabo indeksov pri podatkovnih bazah Postgres in Timescale. Indeksi so ustvarjeni na atributu ˇsifre vozila in ˇcasovne znaˇcke. Pri testu raˇcunanja meseˇcnih povpreˇcij pa ˇse na atributu razdalje.
Branje podatkov znotraj ˇcasovnega intervala
Naslednja poizvedba je klasiˇcen primer bralne operacije pri ˇcasovnih vr- stah, kjer nastopa pregled podatkov po ˇcasovni komponenti in preverjanje ali doloˇcen atribut zadoˇsˇca danemu pogoju. V opazovanem primeru je to razvi- dno kot pridobivanje informacij glede dolˇzine razdalj, ki jih vozila opravijo v danem obdobju. Primer take poizvedbe je viden na sliki 5.1.
Slika 5.1: Branje podatkov znotraj ˇcasovnega intervala
Raˇcunanje meseˇcnih vsot za doloˇcen atribut
Podjetja na koncu meseca opravljajo razliˇcne izraˇcune glede plaˇc, davkov ipd.
Na sliki 5.2 je prikazana poizvedba, kjer ˇzelimo ugotoviti kolikˇsen je skupen zasluˇzek vozil po mesecih, bodisi zaradi izplaˇcila bonusa voznikom ali plaˇcila davkov na dobiˇcek.
Slika 5.2: Raˇcunanje vsot za doloˇcen atribut
Raˇcunanje meseˇcnih povpreˇcij za doloˇcen atribut
V danem scenariju pogosto naletimo na podatke o razdaljah, ki jih prevozijo doloˇcena vozila. Iz slike 5.3 je razvidna poizvedba po povpreˇcnih meseˇcnih razdaljah za posamezno vozilo zaradi obraˇcuna stroˇskov za gorivo. Podjetja zato skrbno nadzorujejo podatke o stanju rezervoarjev in porabo goriva z namenom zagotavljanja uˇcinkovite porabe sredstev.
Slika 5.3: Raˇcunanje povpreˇcij za doloˇcen atribut
Iskanje minimalnih/maksimalnih vrednosti
Ena izmed problematik, s katero se sooˇcajo uporabniki prevoznih sluˇzb so manipulacije z iskanjem najkrajˇse poti do cilja. Ankete pogosto kaˇzejo ne- zadovoljstvo strank zaradi namernega iskanja in zaraˇcunavanja daljˇsih poti.
Na sliki 5.5 imamo primer poizvedbe, ki nam je v pomoˇc pri iskanju takih odstopanj. Poslediˇcno lahko ugotovimo, ali so eventuelne pritoˇzbe strank upraviˇcene ali ne. Podobno lahko iz poizvedbe o minimalnih vrednostih (slika 5.4) ugotovimo, ali je voznik zaraˇcunal premajhno plaˇcilo.
Slika 5.4: Iskanje minimalnih vrednosti
Slika 5.5: Iskanje maksimalnih vrednosti Izvedba kompleksne poizvedbe
Zadnji scenarij predvideva izvedbo kompleksne poizvedbe, kjer analitike v podjetju zanimajo maksimalne prevoˇzene razdalje znotraj omejenega inter- vala. Opazovanje slednjega je lahko v pomoˇc pri ugotavljanju obnaˇsanja trga, in sicer v smislu odgovarjanja na vpraˇsanje kdaj v teku dneva je pov- praˇsevanje po daljˇsih relacijah veˇcje. Naslednja poizvedba (slika 5.6) nam vrne pet minut, znotraj katerih je nastopila voˇznja z najdaljˇso dnevno raz- daljo.
Slika 5.6: Izvedba kompleksne poizvedbe
Predstavitev rezultatov
V tem poglavju bodo predstavljeni rezultati operacij, ki so bile opisane v po- glavju 5.1. Vsaka operacija nad podatki je bila testirana brez in z uporabo indeksov. Indeksi so bili ustvarjeni na atributih ”ˇsifra vozila”in ”ˇcasovna znaˇcka”, pri nekaterih poizvedbah pa ˇse na nekaterih drugih atributih (npr.
”razdalja”). Na grafih testov z indeksi so prikazani samo rezultati podatkov- nih baz Postgres in Timescale, kajti InfluxDB ne podpira dela z indeksi.
6.1 Operacije pisanja v podatkovno bazo
6.1.1 Navadno zapisovanje (z ukazom insert ) ˇ casovno urejenih podatkov
Graf na sliki 6.1 prikazuje porabo ˇcasa pri navadnem zapisovanju ˇcasovno urejenih podatkov. Poraba ˇcasa je bila premo sorazmerna pri vseh treh ba- zah. Z veˇcanjem ˇstevila zapisanih vrstic se ˇcas izvajanja linearno poveˇcuje.
Najpoˇcasnejˇse zapisovanje je bilo pri InfluxDB, medtem, ko sta Postgres in Timescale potrebovali enako ˇcasa za vnaˇsanje. Zapisovanje podatkov je potekalo, kot je razvidno iz grafov, izredno poˇcasi, saj mora program pri navadnem vstavljanju za vsako novo vrstico ustvariti novo povezavo, do po- datkovne baze. Test z uporabo indeksov (slika 6.2) je pokazal, bistveno
47
1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 x - tevilo podatkov
0 50 100 150 200 250 300
y - as v sek undah
P T I
Slika 6.1: ˇCas izvajanja navadnega zapisovanja pri ˇcasovno urejenih podatkih poveˇcanje ˇcasa zapisovanja, saj se morajo indeksi posodabljati z vsakim no- vim zapisom.
1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 x - tevilo podatkov
0 100 200 300 400
y - as v sek undah
P T
Slika 6.2: ˇCas izvajanja navadnega zapisovanja pri ˇcasovno urejenih podatkih z uporabo indeksov
6.1.2 Navadno zapisovanje ˇ casovno neurejenih podat- kov
V realnem ˇzivljenju pogosto naletimo na razliˇcne scenarije, kjer nastopajo ˇcasovno neurejeni podatki. Vzroki za to so lahko razliˇcni od izpada sistema do slabega omreˇznega signala. Na grafu na sliki 6.3 vidimo, da je trend naraˇsˇcanja ˇcasa izvajanja linearen pri vseh treh podatkovnih bazah. Po- slediˇcno je hitrost zapisovanja konstantna, iz ˇcesar sklepamo lahko, da je sistem skalabilen pri vseh treh podatkovnih bazah. Podatkovna baza Po- stgres je zahtevala najmanj ˇcasa za vnaˇsanje podatkov, poslediˇcno je bila hitrost zapisovanja veˇcja. V primerjavi s prejˇsnjim testom (slika 6.1), vi- dimo, da ˇcasovna neurejenost ni bistveno vplivala na ˇcas izvajanja. V toˇcki pri 10000 zapisov sta podatkovni bazi Postgres in Timescale potrebovali pod 250 sekund pri obeh testih. Podatkovna baza InfluxDB je pri testu s ˇcasovno urejenimi podatki dosegla ˇcas izvajanja 300 sekund. Pri testu s ˇcasovno ne- urejenimi pa je komaj presegla 300 sekund. Test z uporabo indeksov (slika 6.4) kaˇze linearno poveˇcevanje ˇcasa izvajanja pri podatkovnih bazah Postgres in Timescale. Za zapisovanje 10000 zapisov z uporabo indeksov potrebujeta podatkovni bazi bistveno veˇc ˇcasa (med 350 in 450 sekund) kot brez (manj kot 250 sekund). Hitrost zapisovanja z uporabo indeksov, se je pri podat- kovnih bazah Postgres in Timescale zaradi posodabljanja struktur indeksov zmanjˇsala. Pri obeh testih je bila najhitrejˇsa podatkovna baza Postgres.
1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 x - tevilo podatkov
0 50 100 150 200 250 300
y - as v sek undah
P T I
Slika 6.3: ˇCas izvajanja navadnega zapisovanja pri ˇcasovno neurejenih po- datkih
1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 x - tevilo podatkov
0 100 200 300 400
y - as v sek undah
P T
Slika 6.4: ˇCas izvajanja navadnega zapisovanja pri ˇcasovno neurejenih po- datkih z uporabo indeksov
6.1.3 Zapisovanje ˇ casovno urejenih podatkov v sveˇ znju
Zapisovanje podatkov v sveˇznju je nekoliko hitrejˇsa metoda zapisovanja v podatkovno bazo, kjer program naenkrat poˇslje veˇc vrstic podatkov skupaj.
Ta metoda pisanja ima svoje prednosti pri primerih, ko je potrebno naenkrat zapisati veliko koliˇcino podatkov. Vozilo vˇcasih zaradi preobremenjenega omreˇzja ali slabega signala ne more poslati podatkov na streˇznik v realnem ˇcasu. Takrat jih shrani lokalno in jih ob priloˇznosti poˇslje vse naenkrat na streˇznik. Tukaj je izvajanje potekalo hitreje in je bilo moˇzno testirati baze z nekoliko veˇcjo testno mnoˇzico (do 1000000 vrstic).
Graf na sliki 6.5 nam pove, da imata podatkovni bazi Postgres in Time- scale uˇcinkovitejˇso metodo za zapisovanje podatkov v sveˇznju, saj je njihov ˇcas izvajanja zapisovanja krajˇsi, kot pri InfluxDB, kar se opazi iz krepko poloˇznejˇse premice. Za zapisovanje milijona vrstic potrebuje InfluxDB 117 sekund, Postgres in Timescale pa po 14 sekund. Pri zapisovanju podatkov v sveˇznju je oˇcitna prednost ponovno na strani podatkovne baz Postgres in Timescale nasproti InfluxDB. Test je pokazal linearno rast ˇcasa izvajanja pri vseh treh podatkovnih bazah. Na grafu na sliki 6.6 je vidno obˇcutno poveˇcanje ˇcasa izvajanja z uporabo indeksov. Pri zapisovanju z indeksi po- trebujeta podatkovni bazi Postgres in Timescale veˇc ˇcasa kot InfluxDB. Kot ˇze povedano pri zapisovanju je potrebno indekse vedno znova posodabljati, zato je poslediˇcno zapisovanje poˇcasnejˇse pri podatkovnih bazah Postgres in Timescale, kot brez uporabe indeksov.
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 x - tevilo podatkov v milijonih 1e6 0
20 40 60 80 100 120
y - as v sek undah
P T I
Slika 6.5: ˇCas izvajanja pri zapisovanju ˇcasovno urejenih podatkov v sveˇznju
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 x - tevilo podatkov v milijonih 1e6 0
25 50 75 100 125 150 175
y - as v sek undah
P T
Slika 6.6: ˇCas izvajanja pri zapisovanju ˇcasovno urejenih podatkov v sveˇznju z uporabo indeksov
6.1.4 Zapisovanje ˇ casovno neurejenih podatkov v sveˇ znju
Na koncu si oglejmo ˇse testiranje hitrosti zapisovanja v sveˇznju pri neure- jenih ˇcasovnih vrstah. Na grafu na sliki 6.7, opazimo, da je ˇcas izvajanja pri podatkovnih bazah Postgres in Timescale gibal okoli 40 sekund, z blago prednostjo v korist podatkovne baze Timescale. ˇCas izvajanja pri podatkovni bazi InfluxDB je v primerjavi s prejˇsnjim testom (poglavje 6.1.3) ostal skoraj nespremenjen. Test je pokazal upoˇcasnitev zapisovanja ˇcasovno neurejenih podatkov (ˇcas izvajanja se je gibal okoli 40 sekund) v primerjavi z zapisova- njem ˇcasovno urejenih za podatkovni bazi Postgres in Timescale, kjer je bil ˇcas izvajanja med 0 in 20 sekund. Pri testu z uporabo indeksov (slika 6.8), opazimo linearno rast ˇcasa izvajanja, s prednostjo na strani podatkovne baze Postgres, ki je prehitela podatkovno bazo Timescale. Nastalo upoˇcasnitev zapisovanja je spet moˇc pripisati posodabljanju indeksov in ˇcasovni neureje- nosti podatkov. Kljub ˇcasovni neurejenosti in uporabi indeksov je najhitrejˇsa podatkovna baza bila Postgres, saj je potrebovala manj kot 100 sekund za zapisovanje enega milijona vrstic.
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 x - tevilo podatkov v milijonih 1e6 0
20 40 60 80 100 120
y - as v sek undah
P T I
Slika 6.7: ˇCas izvajanja zapisovanja neurejenih ˇcasovnih vrst v sveˇznju
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 x - tevilo podatkov v milijonih 1e6 0
20 40 60 80 100 120
y - as v sek undah
P T
Slika 6.8: ˇCas izvajanja zapisovanja neurejenih ˇcasovnih vrst v sveˇznju z uporabo indeksov
6.2 Brisanje
Brisanje je kljuˇcna funkcija pri implementaciji politike zastarevanja, ki na- rekuje, koliko ˇcasa se bodo podatki hranili v bazi. Na sliki 6.9 opazimo, da ne glede na rast ˇstevila vrstic od 0 do 1000000 je operacija brisanja pri po- datkovni bazi Timescale zahtevala konstanten ˇcas izvajanja. V zadnji toˇcki opazimo, da je Postgres bil dvakrat poˇcasnejˇsi od podatkovne baze Timescale, ki pa se je le pribliˇzala podatkovni bazi InfluxDB. Prav tako lahko zasledimo, da se je z rastjo ˇstevila vrstic nekoliko poveˇceval tudi ˇcas izvajanja pri po- datkovnih bazah Postgres in InfluxDB, medtem ko pa je pri podatkovni bazi Timescale poraba bila konstantna. Test z uporabo indeksov (slika 6.10) je pohitril izvajanje, pri podatkovni bazi Postgres (0.15-0.25 sekunde), pri po- datkovni bazi Timescale pa je ostal nespremenjen (okoli 0.1 sekunde). Pri podatkovni bazi Postgres lahko na obeh testih opazimo odstopanje v toˇcki pri 100000 vrstic. To odstopanje lahko pripiˇsemo premajhnemu ˇstevilu po- novitev testa in delovanju medpomnilnika.
