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.
Slika 6.9: ˇCas izvajanja pri operaciji brisanja
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.00
0.05 0.10 0.15 0.20 0.25
y - as v sek undah
P T
Slika 6.10: ˇCas izvajanja pri operaciji brisanja z uporabo indeksov
6.3 Operacije branja iz podatkovne baze
6.3.1 Branje podatkov znotraj ˇ casovnega intervala
Naslednji test je predstavljal branje podatkov znotraj ˇcasovnega intervala.
Graf na sliki 6.11 ponazarja, kako se je izkazal InfluxDB, saj je kljub rasti ˇstevila vrstic ohranil ˇcas izvajanja okoli 0,1 sekunde – konstantna poraba ˇcasa. Postgres in Timescale sta se prepletala, kar je tudi priˇcakovano, saj iz specifikacij izhaja, da je pri enostavnejˇsih poizvedbah nad daljˇsimi ˇcasovnimi intervali lahko podatkovna baza Timescale poˇcasnejˇsa za 1 sekundo od po-datkovne baze Postgres, kar je oˇcitno iz zadnje toˇcke na grafu. Prepleta-nje lomljenk je moˇc pripisati teˇzavam z internetno povezavo in majhnim ˇstevilom ponovitev poizvedb, kar je bilo omenjeno na zaˇcetku kot omejitve izvedbe performanˇcnega testa zaradi strojne opreme. Z boljˇsimi viri bi bilo moˇzno izvesti veˇc ponovitev v razumnejˇsem ˇcasovnem okvirju, poslediˇcno bi bila odstopanja manj oˇcitna. Test z uporabo indeksov je pohitril izvajanje poizvedbe. Na grafu 6.12 se ˇcas izvajanja za podatkovni bazi Postgres in Timescale nahaja v razponu med 1.2 in 1.6 sekunde (brez uporabe indeksov pa 3-5 sekund).
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
1 2 3 4 5
y - as v sek undah
P T I
Slika 6.11: ˇCas izvajanja pri branju podatkov znotraj ˇcasovnega intervala
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.0
0.2 0.4 0.6 0.8 1.0 1.2 1.4 1.6
y - as v sek undah
P T
Slika 6.12: ˇCas izvajanja pri branju podatkov znotraj ˇcasovnega intervala z uporabo indeksov
6.3.2 Raˇ cunanje meseˇ cnih vsot za posamezno vozilo
Podobno kot pri preˇsnji poizvedbi lahko z grafa 6.13 znova opazimo, da je prednost na strani podatkovne baze Postgres, za razliko od podatkovne baze Timescale. Za InfluxDB tovrstna agregacija ne predstavlja teˇzav. Ustvarja-nje indeksov (na atributih ”ˇcasovna znaˇcka”, ”ˇsifra vozila”in ”razdalja”) je omogoˇcilo pribliˇzno 3-5 kratno pohitritev pri podatkovnih bazah Postgres in Timescale (razvidno iz grafa 6.14).
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
1 2 3 4 5
y - as v sek undah
P T I
Slika 6.13: ˇCas izvajanja pri raˇcunanju meseˇcnih vsot za posamezno vozilo
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.0
Slika 6.14: ˇCas izvajanja pri raˇcunanju meseˇcnih vsot za posamezno vozilo z uporabo indeksov
6.3.3 Raˇ cunanje meseˇ cnih povpreˇ cij za posamezno vo-zilo
Pri raˇcunanju povpreˇcij je iz grafa 6.15 razvidno, da sta podatkovni bazi Timescale in Postgres zahtevali enak ˇcas izvajanja. Raˇcunanje povpreˇcja je zahtevnejˇsa funkcija od raˇcunanja vsot, saj je potrebno ˇse opraviti operacijo deljenja, zato se poveˇca kompleksnost poizvedbe. Rast koliˇcine podatkov in kompleksnost poizvedbe vplivata na poveˇcanje ˇcasa izvajanja pri podatkovni bazi Postgres, kar je razvidno na koncu grafa, kjer Timescale prehiti Postgres.
Test z uporabo indeksov (slika 6.16) je uspel pohitriti delovanje pri podat-kovnih bazah Postgres in Timescale. Pri obeh testih je vidno odstopanje v prvi toˇcki (pri 100000 zapisov). To odstopanje je posledica premajhnega
ˇstevila ponovitev testa in delovanja medpomnilnika.
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.0
0.2 0.4 0.6 0.8 1.0 1.2
y - as v sek undah P
T I
Slika 6.15: ˇCas izvajanja pri raˇcunanju meseˇcnih povpreˇcij za posamezno vozilo
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.0
Slika 6.16: ˇCas izvajanja pri raˇcunanju meseˇcnih povpreˇcij za posamezno vozilo z uporabo indeksov
6.3.4 Iskanje minimalnih in maksimalnih meseˇ cnih vrednosti
Timescale in Postgres sta pri iskanju minimalnih (slika 6.17) in maksimalnih meseˇcnih vrednosti (slika 6.19) enakovredno uˇcinkoviti, InfluxDB pa je bil hitrejˇsi od obeh. Vzrok odklona konic v zaˇcetni toˇcki pri 100000, lahko sklepamo, da je zaradi delovanja medpomnilnika kot tudi ponovno zaradi premajhnega ˇstevila ponovitev testa. Grafa na slikah 6.18 in 6.20 ponazarjata pohitritev testov s pomoˇcjo uporabo indeksov. Pohitritev izvajanja je najbolj opazna v toˇcki pri milijon zapisih. ˇCas izvajanja je tukaj skoraj prepolovljen.
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
1 2 3 4 5
y - as v sek undah
P T I
Slika 6.17: ˇCas izvajanja pri raˇcunanju meseˇcnih naraˇsˇcajoˇcih minimumov za posamezno vozilo
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.0
0.1 0.2 0.3 0.4 0.5 0.6 0.7
y - as v sek undah
P T
Slika 6.18: ˇCas izvajanja pri raˇcunanju meseˇcnih naraˇsˇcajoˇcih minimumov za posamezno vozilo z uporabo 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.0
0.2 0.4 0.6 0.8 1.0 1.2
y - as v sek undah P
T I
Slika 6.19: ˇCas izvajanja pri raˇcunanju meseˇcnih padajoˇcih maksimumov za posamezno vozilo
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.0
0.1 0.2 0.3 0.4 0.5 0.6 0.7
y - as v sek undah
P T
Slika 6.20: ˇCas izvajanja pri raˇcunanju meseˇcnih padajoˇcih maksimumov za posamezno vozilo z uporabo indeksov
6.3.5 Izvedba kompleksne poizvedbe
Zadnja poizvedba je ponazoritev primera, kjer podatkovna baza Timescale dokonˇcno premaga podatkovno bazo Postgres z veliko razliko in dohiti In-fluxDB. Kot je razvidno iz specifikacij [2] je prednost podatkovne baze Ti-mescale nad podatkovno bazo Postgres v primerih kompleksnih agregacij z veliko stavki urejanja in zdruˇzevanja. To potrjuje tudi graf na sliki 6.21. Test z uporabo indeksov (slika 6.22) je pokazal delno pohitritev izvajanja pri po-datkovnih bazah Postgres in Timescale. Obe sta se pribliˇzali podatkovni bazi InfluxDB, vendar je nista prehiteli. Ponovno je premajhno ˇstevilo ponovitev obeh testov vplivalo na odstopanja pri rezultatih.
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.00
Slika 6.21: ˇCas izvajanja pri izvedbi kompleksne poizvedbe
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
x - tevilo podatkov 1e6
0.000
Slika 6.22: ˇCas izvajanja pri izvedbi kompleksne poizvedbe z uporabo inde-ksov
6.4 Analiza rezultatov
Testi navadnega in zapisovanja podatkov v sveˇznju, pri podatkovnih bazah Timescale in InfluxDB, sta v primerjavi s podatkovno bazo Postgres zah-tevali veˇc ˇcasa za zapisovanje podatkov. Ta razlika je posebej vidna med podatkovno bazo InfluxDB na eni in podatkovnimi bazami Postgres, ter Ti-mescale na drugi strani. InfluxDB je pokazal manjˇso hitrost pri zapisovanju v podatkovno bazo, vendar veˇcjo odpornost pri menjavi scenarijev, saj so vse poizvedbe zahtevale podobno koliˇcino ˇcasa, za razliko od podatkovnih baz Postgres in Timescale. Testiranje bralnih in agregacijskih poizvedb je ustvarilo ˇse posebej zanimive rezultate kljub omenjenim omejitvam strojne opreme.
Brisanje je kot ˇze omenjeno kljuˇcna operacija pri implementaciji
samo-dejnega zastarevanja podatkov, ki je vse bolj uveljavljena v domeni ˇcasovnih vrst. Pri brisanju smo opazili naraˇsˇcanje ˇcasa izvajanja pri podatkovnih bazah Postgres in InfluxDB. Podatkovni bazi Timescale je uspelo ohranjati konstanten ˇcas izvajanja, neodvisno od naraˇsˇcanja koliˇcine podatkov.
Sledila je enostavna poizvedba po ˇcasovnem intervalu z atributom razdalje pod neko vrednostjo. Znova je bilo priˇcakovati blaˇzjo prednost podatkovne baze Postgres nad podatkovno bazo Timescale za 1 sekundo, vendar pa je podatkovna baza InfluxDB zahtevala manj ˇcasa od podatkovnih baz Postgres in Timescale..
Pri vseh ostalih poizvedbah razen zadnje se je vzorec ponavljal. Podat-kovna baza InfluxDB je v vseh preostalih poizvedbah zahtevala minimalno koliˇcino ˇcasa, medtem ko se je slednja pri podatkovnih bazah Postgres in Ti-mescale bolj ali manj prepletali, s to razliko, da je naˇceloma pri najviˇsji obre-menitvi Timescale prehitel Postgres. Z veˇcanjem kompleksnosti poizvedbe s stavki zdruˇzevanja in urejanja in oˇzanjem iskanega ˇcasovnega intervala, pa je podatkovna baza Timescale krepko prehitela podatkovno bazo Postgres in se zbliˇzala s podatkovno bazo InfluxDB.
V tabeli 6.1 so zbrani ˇcasi izvajanj za operacije navadnega zapisovanja (10000 zapisov) in zapisovanju v sveˇznju (1000000 zapisov). V tabeli so pred-stavljeni rezultati meritev brez uporabe indeksov zato, da lahko primerjamo vse tri podatkovne baze (InfluxDB ne podpira dela z indeksi). Iz tabele je razvidno, da je pri zapisovanju najveˇc ˇcasa potreboval InfluxDB. Postgres in Timescale sta bila izenaˇcena pri zapisovanju ˇcasovno urejenih podatkov. Pri navadnem vstavljanju ˇcasovno neurejenih podatkov je bila hitrejˇsa podat-kovna baza Postgres, pri zapisovanju ˇcasovno neurejenih podatkov v sveˇznju pa Timescale.
Naslednja tabela (slika 6.2) vsebuje ˇcase izvajanj ostalih operacij nad posameznimi podatkovnimi bazami, ki so vsebovale 1000000 zapisov. Tabela vsebuje rezultate meritev brez uporabe indeksov. Iz tabele je razvidno, da je pri vseh operacijah najmanj ˇcasa zahtevala podatkovna baza InfluxDB, edino pri brisanju je zaostajala za podatkovnima bazama Postgres in Timescale.
Podatkovna baza Timescale je bila pri nekaterih operacijah v prednosti pred podatkovno bazo Postgres (npr. brisanje, raˇcunanje meseˇcnih povpreˇcij za posamezno vozilo, izvedba kompleksne poizvedbe). Pri preostalih operacijah pa je podatkovna baza Postgres zahtevala manj ˇcasa kot Timescale.
Operacija Postgres Timescale InfluxDB Navadno vstavljanje ˇcasovno urejenih podatkov 241 243 292 Navadno vstavljanje ˇcasovno neurejenih podatkov 250 267 310 Zapisovanje ˇcasovno urejenih podatkov v sveˇznju 14 14 117 Zapisovanje ˇcasovno neurejenih podatkov v sveˇznju 43 33 120 Tabela 6.1: Cas izvajanja pri navadnem zapisovanju (10000 zapisov) inˇ
zapisovanju v sveˇznju (1000000 zapisov) za posamezno podatkovno bazo
Operacija Postgres Timescale InfluxDB
Brisanje 0.2 0.1 0.9
Branje podatkov znotraj ˇcasovnega intervala 3.2 3.8 0.1 Raˇcunanje meseˇcnih vsot za posamezno vozilo 0.6 1.9 0.1 Raˇcunanje meseˇcnih povpreˇcij za posamezno vozilo 1.6 1.1 0.1 Iskanje minimalnih meseˇcnih vrednosti 1.1 1 0.05 Iskanje maksimalnih meseˇcnih vrednosti 1.1 1.1 0.1
Izvedba kompleksne poizvedbe 0.23 0.05 0.05
Tabela 6.2: ˇCas izvajanja pri operacijah nad posameznimi podatkovnimi bazami, ki so vsebovale po 1000000 zapisov
6.5 Vrednotenje podatkovnih baz z vidika ne-merljivih kriterijev
Na koncu je pomembno omeniti tudi nameˇsˇcanje posameznih baz. Kot je bilo ˇze omenjeno v poglavju 2 je namestitev podatkovnih baz Postgres in Ti-mescale enostavna. Pri podatkovni bazi InfluxDB je teˇzave povzroˇcil prehod na novejˇso razliˇcico. Pri tem je ugotavljanje, kateri ukazi niso veˇc podprti, terjalo precej ˇcasa. Podobno je bilo tudi pri spoznavanju novega grafiˇcnega vmesnika, imenovanega DataExplorer.
Vse tri podatkovne baze so razpolagale s hitrim in enostavnim postop-kom uvoza knjiˇznice (python) za povezavo z bazo in s tem tudi enostavno vkljuˇcitev v naˇso aplikacijo. Dokumentacija knjiˇznic za manipulacijo s po-datkovnimi bazami Postgres, Timescale in InfluxDB je bila zelo pregledno in obˇsirno opisana.
Prav tako so vse tri podatkovne baze na voljo kot odprtokodne in skladno s tem ni bilo drugih stroˇskov (nakup licence).
Pomemben kriterij je tudi preprostost sintakse jezika za manipulacijo z bazo. Postgres in Timescale uporabljata SQL, ki je lahko razumljiv in ga mnogi razvijalci dojemajo kot osnovno znanje na podroˇcju podatkovnih baz.
InfluxDB v razliˇcici 1.x uporablja jeziku SQL soroden poizvedovalni jezik imenovan InfluxQL. V razliˇcici 2.X pa je InfluxQL zamenjal novejˇsi poizve-dovalni jezik Flux. Pri slednjem je bilo potrebno vzeti nekaj ˇcasa za uˇcenje novih funkcij, ukazov in poizvedb. Flux je prav tako obˇcutljiv na datum in sprejema zgolj dva formata.
Zakljuˇ cek
Casovne vrste se vse bolj uveljavljajo na podroˇˇ cju podatkovnih baz. Razliˇcne podatkovne baze se med seboj primerjajo s pomoˇcjo performanˇcnega testa.
Namen te diplomske je bil primerjati uˇcinkovitost razliˇcnih vrst podatkovnih baz - Postgres (relacijska podatkovna baza), Timescale (relacijska TSDB), InfluxDB (nerelacijska TSDB). Za ta namen smo poustvarili primer uporabe podatkovnih baz in sestavili performanˇcni test. Z uporabo performanˇcnega testa smo primerjali uˇcinkovitost omenjenih podatkovnih baz.
Performanˇcni test je bil sestavljen iz treh delov: Ustvarjanje testne mnoˇzice podatkov, zapisovanja podatkov in izvajanje operacij nad podat-kovno bazo. S performanˇcnim testom smo uspeˇsno prepoznali razlike v zmo-gljivosti izbranih podatkovnih baz.
Podroˇcje podatkovnih baz za ˇcasovne vrste se je pokazalo kot obetavno podroˇcje za raziskovanje in nadaljnje delo. Diplomsko nalogo bi lahko nad-gradili z razˇsiritvijo strojne opreme in povezovanjem s podjetji, ki pri po-slovanju uporabljajo podatkovne baze za ˇcasovne vrste. Z boljˇso strojno opremo bi lahko testirali podatkovne baze z veˇcjo testno mnoˇzico in opazo-vali obnaˇsanje operacij pri skaliranju. Povezovanje s podjetji, ki uporabljajo podatkovne baze za ˇcasovne vrste, bi nam lahko omogoˇcilo vpogled v struk-turo podatkov in operacij. Z analizo lastnosti realnih podatkov in operacij bi lahko natanˇcneje poustvariti dejanske primere uporabe.
79
[1] InfluxDB. Dosegljivo: https://www.influxdata.com/. [Dostopano: 1.
10. 2020].
[2] TimesScale. Dosegljivo: https://www.timescale.com/. [Dostopano:
1. 10. 2020].
[3] DB-Engine Ranking, 2020 (accessed December 30, 2020).
[4] Anil Poriya Ameya Nayak and Dikshay Poojary. Type of nosql databases and its comparison with relational databases. International Journal of Applied Information Systems, 2003.
[5] Andreas Bader. Comparison of time series databases. Master’s thesis, 2016.
[6] Andreas Bader, Oliver Kopp, and Michael Falkenthal. Survey and com-parison of open source time series databases. Datenbanksysteme f¨ur Business, Technologie und Web (BTW 2017)-Workshopband, 2017.
[7] Billy P Buckles and Frederick E Petry. A fuzzy representation of data for relational databases. Fuzzy sets and systems, 7(3):213–226, 1982.
[8] Ted Dunning and Ellen Friedman. Time series databases new ways to store and access data. 25(3):1–10, 2013.
[9] Salahaldin Juba, Achim Vannahme, and Andrey Volkov. Learning Po-stgreSQL. Packt Publishing Ltd, 2015.
81
[10] Nataˇsa Knez. Primerjava relacijske in NoSQL podatkovne baze in opre-delitev kriterijev za pomoˇc pri izbiri najprimernejˇse podatkovne baze.
PhD thesis, Univerza v Ljubljani, 2012.
[11] David Maier. The theory of relational databases, volume 11. Computer science press Rockville, 1983.
[12] Mikael Martinviita. Time series database in industrial iot and its testing tool, 2018.
[13] Mohamed A Mohamed, Obay G Altrafi, and Mohammed O Ismail. Rela-tional vs. nosql databases: A survey. International Journal of Computer and Information Technology, 3(03):598–601, 2014.
[14] ABM Moniruzzaman and Syed Akhter Hossain. Nosql database: New era of databases for big data analytics-classification, characteristics and comparison. arXiv preprint arXiv:1307.0191, 2013.
[15] Emil Sekerinski Muntazir Fadhel and Shucai Yao. A comparison of time series databases for storing water quality data. 2019.
[16] Dmitry Namiot. Time series databases. DAMDID/RCDL, 1536:1–10, 2015.
[17] Ana Carolina Riekstin, Antoine Langevin, Thomas Dandres, Ghyslain Gagnon, and Mohamed Cheriet. Time series-based ghg emissions pre-diction for smart homes. IEEE Transactions on Sustainable Computing, 5(1):134–146, 2018.
[18] Jun Yuan Rui Liu. Benchmarking time series databases with iotdb-benchmark for iot scenarios. pages 1–10, 2019.
[18] Jun Yuan Rui Liu. Benchmarking time series databases with iotdb-benchmark for iot scenarios. pages 1–10, 2019.