O údajoch

horizontálne a vertikálne škálovanie, SQL vs NoSQL databázové systémy, časové rady (time series databázy) a ich použitie, zber dát, vizualizácia dát, analýza dát

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.
    Smart Waste Management (zdroj)

    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.

    IoT Architecture Overview [@s4]

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é.

    Scale Out vs Scale Up [@s64]
  • 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:

    Cost difference in vertical vs horizontal scalability [@s65]
    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.

    DB-Engines Score by DB Category (zdroj)[@s62]
  • (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ť
    Regular vs Irregular Time Series [@s67]