O údajoch

Introduction

• (slide) Začnime pohľadom na službu, o ktorej sa rozprávame od začiatku - o chytrom vývoze odpadu (waste management). Trochu preháňajme a uvažujme, že v Košiciach sa nachádza 1000 domov (súpisné čísla). Preháňajme ďalej a povedzme, že pre každý dom máme vyhradený

  • 1 kontajner pre papier,
  • 1 kontajner pre sklo,
  • 1 kontajner pre plasty, a
  • 1 kontajner pre komunálny odpad.

  

  To máme dokopy 4000 veľkých kontajnerov v meste. Zatiaľ nič nehovoríme o verejných kontajneroch v parkoch, na zastávkach a podobne. Každý z týchto kontajnerov je v našom scenári vybavený chytrým zariadením (vecou), ktoré vie zistiť množstvo odpadu v kontajneri a v pravidelných intervaloch, ako aj v prípade potreby (množstvo odpadu presiahlo úroveň, kedy ho je potrebné vyviezť) vie odoslať údaje o svojom stave. Ak budeme preháňať ďalej, tak povedzme, že každé zariadenie bude posielať správu o aktuálnom stave každú hodinu. To znamená, že v jednom momente zaznamenáme nápor v podobe 4000 požiadaviek o zápis údajov do databázy.

• Toto číslo samozrejme nie je extrémne veľké. Ak by sme však mali senzory, ktoré by snímali údaje napr. každú minútu alebo každých niekoľko sekúnd, množstvo údajov, ktoré je potrebné uložiť, by bolo výrazne vyššie.

• V našom scenári sme však stále v jednom meste. Čo ak by sme svoju službu prevádzkovali v niekoľkých mestách zároveň? Čo ak by sme vyhrali nejakú štátnu zákazku a stali by sme sa výlučným poskytovateľom danej služby na Slovensku? Čo ak by sme uvažovali vo veľkom a podarilo by sa nám preraziť za hranicami a službu by sme poskytovali v niekoľkých krajinách? Množstvo údajov čakajúcich na uloženie by rástlo ďalej, vďaka čomu by sa databázový server stal veľmi rýchlo úzkym hrdlom systému.

• (slide) Hovorili sme o tom, že nápor množstva údajov vieme znížiť vhodným umiestnením vrstvy edge v našej architektúre. Tá nám pomôže znížiť nápor agregovaním údajov, prípadne ich čiastočným predspracovaním alebo aj analytikou.

  

Horizontal vs Vertical Scaling

• (slide) Znížiť nápor množstva údajov však môžeme aj výberom vhodného databázového systému s vhodnými vlastnosťami. Databázové servery pre IoT riešenia, ktoré potrebujú spracovávať obrovské množstvá údajov v reálnom čase, by mali byť horizontálne škálovateľné.

  

• Relačné databázové systémy sú tu s nami už od 70-tych rokov. S množstvom uchovávaných údajov sa môžu začať potýkať s problémom potrebného výkonu. Akonáhle sa problémy tohto typu vyskytnú, začnú ich spoločnosti riešiť vertikálnym škálovaním.

• Vertikálne škálovať (alebo tiež scale up/down) znamená pridať ďalšie zdroje (alebo odstrániť existujúce) z jedného uzla (zariadenia). Obyčajne sa jedná o zvýšenie výkonu v podobe rýchlejšieho CPU, zvýšenie počtu CPU, zvýšenie RAM alebo zväčšenie diskového priestoru na jednom počítači.

• Tento spôsob škálovania má však svoje limity. Tie sú dané hlavne fyzikálnymi zákonitosťami, resp. možnosťami aktuálnych technológií.

• Horizontálne škálovať (alebo tiež scale out/in) znamená pripojiť do systému ďalšie uzly (alebo odpojiť existujúce). To docielime pripojením nového počítača do distribuovaného systému. Vlastnosťou horizontálneho škálovania je vybavená väčšina NoSQL databázových systémov.

• (slide) Samozrejme aj jeden aj druhý prístup má svoje výhody a nevýhody:

  

  horizontálne škálovanie	vertikálne škálovanie
  so zvyšovaním počtu pripojených uzlov sa zvyšuje aj dostupnosť	single point of failure
  pri škálovaní nie je potrebný žiadny výpadok služby	pri zmene konfigurácie je služba nedostupná
  relatívne nízke náklady	lepší hardvér predstavuje zvýšené náklady
  škálovať je možné teoreticky do nekonečna	obmedzené možnosti zvyšovania výkonu
  nie každý softvér a problém je možné riešiť distribuovane	väčšina softvéru zvláda výhody vertikálneho škálovania
  problémy ako potreba load balancera na distribuovanie požiadaviek, synchronizácia a replikácia údajov, aktualizácia softvéru	jednoduchá správa softvéru na jednom počítači/zariadení
  automatické škálovanie použitím vhodných služieb (AWS)	automatizácia je možná buď vlastnými skriptami alebo inštalovanými službami

Time Series Databases

• Údaje, ktoré zbierame v IoT aplikáciách, sú závislé na čase. Takýto typ databáz sa nazýva time series (časové rady) databázy

• (slide) Time series databáza (TSDB) je softvérový systém, ktorý je optimalizovaný pre prácu s časovými radmi na základe párov dvojíc čas a hodnota.

• Obecne sa teda jedná o údaje, ktoré keď vizualizujeme v podobe grafu, tak jedna z osí reprezentuje čas. Čas tu figuruje ako nezávislá premenná a cieľom je obyčajne predikovať budúcnosť.

• Nad dátami tohto typu nás častokrát zaujímajú otázky ako:

  • aká bola teplota za poslednú hodinu?
  • aká bola teplota za posledných 24 hodín?
  • aká bola priemerná teplota za celý minulý rok?

• (slide) Ich popularita v posledných rokoch prudko stúpla, o čom svedčí aj štatistika serveru db-engines.com na základe kategórií databáz.

  

• (slide) TSDB majú najväčšie uplatnenie v týchto troch oblastiach:

  1. IoT - senzorické dáta
  2. DevOps - monitoring
  3. dátová analytika (v reálnom čase) - metriky

• (slide) typy grafov/údajov

  • v pravidelných intervaloch - pravidelné merania
  • v nepravidelných intervaloch - udalosť

  

InfluxDB

• (slide) InfluxDB is a programmable and performant time series database, with a common API across OSS, cloud and Enterprise offerings.

• InfluxDB is designed to work with time-series data. SQL databases can handle time-series but weren’t created strictly for that purpose. In short, InfluxDB is made to store a large volume of time-series data and perform real-time analysis on those data, quickly.

• In InfluxDB, a timestamp identifies a single point in any given data series. This is like an SQL database table where the primary key is pre-set by the system and is always time.

• InfluxDB also recognizes that your schema preferences may change over time. In InfluxDB you don’t have to define schemas up front. Data points can have one of the fields on a measurement, all of the fields on a measurement, or any number in-between. You can add new fields to a measurement simply by writing a point for that new field.

Terminology

• Referencing the example above, in general:

  • An InfluxDB measurement (foodships) is similar to an SQL database table.
  • InfluxDB tags ( park_id and planet) are like indexed columns in an SQL database.
  • InfluxDB fields (#_foodships) are like unindexed columns in an SQL database.
  • InfluxDB points (for example, 2015-04-16T12:00:00Z 5) are similar to SQL rows.

• measurement

• drzi udaje v UTC

InfluxQL

• (slide) InfluxQL is an SQL-like query language for interacting with InfluxDB. It has been lovingly crafted to feel familiar to those coming from other SQL or SQL-like environments while also providing features specific to storing and analyzing time series data.

InfluxDB API

• (slide) Služba poskytuje HTTP REST API pre prácu s databázou štandardne na porte 8086. Pomocou neho je možné:

  • vytvoriť databázu
  • vkladať údaje
  • získavať údaje

• Nás bude primárne zaujímať vkladanie údajov do databázy. To je možné pomocou HTTP metódy POST. Vkladané údaje majú tieto položky:

  • measurement - názov merania (tabuľky)
  • tags - zoznam značiek s ich hodnotami (metaúdaje)
  • fields - namerané hodnoty (samotné údaje)
  • timestamp - časová značka, ktorá však nie je povinná

• Príklad vloženia informácií do databázy mydb o meraní teploty v stupňoch Celzia v kuchyni pomocou senzora DHT22 je tu:

  $ curl -i \
    -X POST 'http://localhost:8086/write?db=mydb&precision=s' \
    --data-binary 'temperature, \
                   room=kitchen, \
                   sensor=dht22 value=21.64, \
                   unit=C 1585856323'

• V tomto prípade bola použitá aj časová značka v podobe Unixového času. To je dobré používať napr. vtedy, keď chcete do merania (tabuľky) vložiť staršie údaje. Inak je možné údaje vkladať aj bez uvedenia časovej značky, pričom čas bude doplnený na strane databázového servera:

  $ curl -i \
    -X POST 'http://localhost:8086/write?db=mydb' \
    --data-binary 'temperature, \
                   room=kitchen, \
                   sensor=dht22 value=21.64, \
                   unit=C'

• Keďže sa jedná o protokol HTTP, v jazyku MicroPython môžeme použiť balík urequests:

  import urequests
  
  url = 'http://localhost:8086/write?db=mydb'
  data = 'temperature,room=kitchen,\
          sensor=dht22 value=21.64,unit=C'
  response = urequests.post(url, data=data.encode())
  # check result
  response.close()

Visualization with Grafana

• (slide)

• ak influxdb drzi udaje v UTC, tak Grafana ich automaticky konvertuje vzhladom na vasu casovu zonu

Best Practices for Building Analytics Dashboards

Overview of Existing Dashboards

	HTTP	MQTT	pypi
io.adafruit.com	áno	áno	adafruit-io
Ubidots	áno	áno
IBM Watson IoT			micropython-watson-iot
ThingSpeak	áno	áno