IoT, udu ja pilved: räägime tehnoloogiatest?

Tehnoloogia areng tarkvaras ja riistvaras, uute sideprotokollide ilmumine on toonud kaasa asjade interneti (IoT) laienemise. Seadmete arv kasvab päev-päevalt ja need genereerivad tohutul hulgal andmeid. Seetõttu on vajalik mugav süsteemi arhitektuur, mis suudaks neid andmeid töödelda, salvestada ja edastada.

Praegu kasutatakse nendeks eesmärkideks pilveteenuseid. Kuid üha populaarsemaks muutuv udusComputing paradigmain on võimeline täiendama pilvelahendusi, skaleerides ja optimeerides IoT infrastruktuuri.

„Pilved“ suudavad katta enamik IoT nõudmisi. Näiteks tagada teenuste jälgimise, kiire andmete töötlemise, mida seadmed genereerivad, ning nende visualiseerimise. UdusComputing on aga tõhusam reaalaja ülesannete lahendamisel. Need tagavad kiire reageerimise päringutele ja minimaalse viivituse andmete töötlemisel. See tähendab, et Fog täiendab „pilvi“, laiendab nende võimalusi.

Kuid peamine küsimus on hoopis: kuidas peaks kõik see toimima asjade interneti kontekstis? Millised sideprotokollid oleksid kõige tõhusamad IoT-Fog-Pilv ühendatud süsteemi tööks?

Vaatamata näiliselt domineerivale HTTP-le kasutatakse IoT, Fog ja Cloud süsteemides suurt hulka muid lahendusi. See on seletatav sellega, et IoT peab ühendama mitmesuguste seadmete sensorite funktsionaalsused turvalisuse, ühilduvuse ja teiste kasutajate nõudmistega.

Kuid ühine arusaam eetalonsest arhitektuurist ja side standardist on lihtsalt puudulik. Seetõttu on uue protokolli loomine või olemasoleva kohandamine konkreetsete IoT ülesannete jaoks üks IT-kogukonna kõige olulisemaid ülesandeid.

Milliseid protokolle kasutatakse praegu ja mida nad pakuvad? Uurime seda lähemalt. Ent enne arutame ökosüsteemi põhimõtteid, kus suhtlevad pilved, udud ja asjade internet.

IoT Fog-to-Cloud (F2C) arhitektuur

Olete ilmselt märganud, kui palju vaeva näidatakse IoT, pilvede ja udude mõistmise ning nende ratsionaalse ja koordineeritud haldamise eelistest ja kasudest. Kui ei, siis siin on teile kolm standardimisalgatust: OpenFog Consortium, Edge Computing Consortium ja mF2C H2020 EU projekt.

Kui varem oldi keskendunud ainult kahele tasandile, pilvedele ja lõpp-seadmetele, siis pakutud arhitektuur toob sisse uue taseme - uduarvutused. Sellega võib udutasandi jagada mitmeks alatasemeks, sõltuvalt ressurssidest või poliitikate kogumist, mis määratlevad erinevate seadmete kasutamise nende alatasemete raames.

Kuidas võiks see abstraktsioon välja näha? Siin on tüüpiline IoT-Udu-Pilv ökosüsteem. IoT-seadmed saadavad andmeid võimsamatele serveritele ja arvutusseadmetele, et lahendada ülesandeid, mis nõuavad madalat viivitust. Samas vastutavad pilved ülesannete lahendamise eest, mis nõuavad suurt arvutusvõimet või andmete salvestamiseks ruumi.

Nutitelefonid, nutikellad ja muud vidinad võivad samuti olla osa IoT-st. Kuid sellised seadmed kasutavad tavaliselt suurte arendajate patendi protokolle. IoT kaudu genereeritud andmed edastatakse udutaseile REST HTTP protokolli kaudu, mis tagab paindlikkuse ja funktsionaalse ühilduvuse RESTful-teenuste loomisel. See on oluline, arvestades olemasoleva arvutusinfrastruktuuri tagurpidi ühilduvust, mis töötab kohalikes arvutites, serverites või serverite klastrites. Kohalikud ressursid, mida kutsutakse „udusõlmedeks“, filtreerivad saadud andmeid ja töötlevad neid kohapeal või edastavad edasiseks arvutamiseks pilve.

Pilved toetavad erinevaid sideprotokolle, sealhulgas AMQP ja REST HTTP. Kuna HTTP on laialdaselt tuntud ja kohandatud interneti jaoks, võib tekkida küsimus: „kas ei peaks seda kasutama IoT ja udude jaoks?“. Kuid selle protokolli jõudluses on probleeme. Räägime sellest hiljem.

Üldiselt on olemas 2 sideprotokolli mudelit, mis sobivad meie süsteemi. Need on päring-vastus ja avaldamine-tellimine. Esimene mudel on laiemalt tuntud, eriti server-klient arhitektuuris. Klient küsib serverilt teavet, misjärel server saab päringu, töötleb seda ja saadab vastusena sõnumi. Selle mudeli järgi töötavad protokollid REST HTTP ja CoAP.

Teine mudel tekkis vajadusest tagada asünkroonne, jaotatud, nõrk side andmete genereerijate ja nende saajate vahel.

Mudelis osaleb kolm osalist: väljaandja (andmeallikas), vahendaja (dispetšer) ja tellija (saaja). Siin ei pea klient, kes tegutseb tellijana, serverilt teavet küsima. Kliendi asemel tellib ta süsteemis teatud sündmused vahendaja kaudu, kes vastutab kõigi sissetulevate sõnumite filtreerimise ja nende suunamise vahel väljaandjate ja tellijate vahel. Väljaandja avaldab vahendajale, kui teatav teema tõttu toimub sündmus, ja vahendaja edastab tellijale andmed nõutud teema kohta.

Sisuliselt põhineb see arhitektuur sündmustel. Selline suhtlemismudel on huvitav rakenduste jaoks IoT-s, pilves, udus, kuna see suudab tagada skaleeritavuse ja lihtsustada erinevate seadmete vahelisi ühendusi, toetades dünaamilist "palju-palju" suhet ja asünkroonset suhtlust. Tuntud standardiseeritud sõnumivahetusprotokollide seas, mis kasutavad "väljaandmise-tellimise" mudelit, on nimetada MQTT, AMQP ja DDS.

On selge, et "väljaandmise-tellimise" mudelil on mitmeid eeliseid:

• Väljaandjad ja tellijad ei pea teadma üksteise olemasolust;
• Üks tellija võib saada teavet paljusid erinevaid väljaandeid, samas kui üks väljaandja võib edastada andmeid paljudele erinevatele tellijatele (printsiip "palju-palju");
• Väljaandja ja tellija ei pea olema samaaegselt aktiivsed, et andmeid vahetada, kuna vahendaja (töötades järjekorrasüsteemina) suudab säilitada sõnumi klientide jaoks, kes ei ole hetkel võrku ühendatud.

Kuid ka "küsi-vasta" mudelil on oma tugevad küljed. Kui serveri poolel pole mitu klienti käsitlevates päringutes probleeme, on mõistlik kasutada juba tõestatud usaldusväärseid lahendusi.

Samuti on protokolle, mis toetavad mõlemat mudelit. Näiteks XMPP ja HTTP 2.0, mis toetavad „server push“ valikut. IETF on välja andnud ka CoAP. Käesoleva probleemi lahendamiseks on loodud mitmeid teisi lahendusi, nagu WebSocketi protokoll või HTTP protokolli kasutamine läbi QUIC (Quick UDP Internet Connections).

WebSocketite osas, kuigi seda kasutatakse andmete edastamiseks reaalajas serverilt veebikliendile ning see tagab pidevad ühendused samaaegse kahepoolsest suhtlusest, ei ole see mõeldud piiratud arvutusvõimekusega seadmetele. QUIC väärib samuti tähelepanu, kuna uus transpordiprotokoll avab palju uusi võimalusi. Kuid kuna QUIC ei ole veel standardiseeritud, on liiga vara prognoosida selle võimaliku rakenduse ja mõju IoT lahendustele. Seega jätame WebSocketid ja QUIC tulevikku silmas pidades meelde, kuid hetkel ei hakka me neid sügavamalt uurima.

Kes on maailmas kõige armsam: võrreldes protokolle

Räägime nüüd protokollide tugevustest ja nõrkustest. Enne teema süvenemist tasub kohe märkida, et puudub üks selge juht. Iga protokolli omadustes ja puudustes on midagi.

Reageerimise aeg

Üks olulisemaid sideprotokollide omadusi, eriti Interneti-asjade kontekstis, on reageerimisaeg. Kuid olemasolevate protokollide seas ei ole ühtegi absoluutset võitjat, kes näitaks minimaalset viivitust erinevates tingimustes. Siiski on olemas hulk uuringuid ja võrdlusi protokollide võimekusest.

Näiteks, tulemused HTTP ja MQTT efektiivsuse võrreldes IoT-s näitas, et MQTT-d päringu reageerimisaeg on lühem kui HTTP-l. Ja uuringu saatmisaeg (RTT) kohta paljastas, et CoAP keskmine RTT on 20% madalam kui MQTT-l.

Teine katse RTT protokollide MQTT ja CoAP osas viidi läbi kahes stsenaariumis: kohalikus võrgus ja IoT-võrgus. Selgus, et keskmine RTT IoT-võrgus on 2-3 korda kõrgem. MQTT QoS0 näitas võrreldes CoAPiga madalamat tulemust, samas kui MQTT QoS1 demonstreeris kõrgemat RTT-d ACK tõttu rakendus- ja transporditasemel. Erinevate QoS tasemete latentsus mitteülekasutatud võrgus oli MQTT puhul millisekundites, CoAP puhul siiski sadades mikrosekundites. Siiski tasub meeles pidada, et vähem usaldusväärsetes võrkudes näitab MQTT, mis töötab TCP kohal, täiesti erinevat tulemust.

Võrdlus AMQP ja MQTT protokollide viivitusaega suurendava koormuse suurenemise analüüs näitas, et väikeste koormuste korral on viivituse tase peaaegu sama. Kuid suurte andmehulkade edastamise korral demonstreerib MQTT madalamat viivitusaega. Veel ühe uurimine CoAPi võrreldi HTTPga masinatevahelise suhtluse stsenaariumis, kus seadmed olid paigaldatud transpordivahenditele ning varustatud gaasidetektorite, ilmadeetektorite, asukoha (GPS) ja mobiilivõrgu (GPRS) liidesega. Aeg, mis oli vajalik CoAP sõnumi edastamiseks mobiilse võrgu kaudu, oli peaaegu kolm korda lühem kui HTTP sõnumite kasutamiseks vajalik aeg.

Viidi läbi uuringud, kus võrreldi mitte kahte, vaid kolme protokolli. Näiteks võrdlus IoT protokollide MQTT, DDS ja CoAP tootlikkust meditsiinilises rakenduses võrguemulaatori abil. DDS ületas MQTT telemeetriaviivituse osas erinevates kehvades võrgutingimustes. UDP-põhine CoAP toimestas hästi rakendustes, mis vajavad kiiret vastust, kuid kuna see põhineb UDP-l, toimus märkimisväärne ennustamatu paketikaotus.

Läbivusvõime

Võrdlus MQTT ja CoAP efektiivsuse analüüs kanalite kasutamise osas toimus andmete koguhulga arvu loendamise kaudu, mida edastati ühe sõnumiga. CoAP näitas väiksemat läbilaskevõimet kui MQTT väikeste sõnumite edastamisel. Kuid protokolli efektiivsuse võrdlemisel kasulikku teavet sisaldavate baitide arvu ja edastatud baitide koguarvu suhetes osutus CoAP tõhusamaks.

Kaugjuhtimisega analüüsis MQTT, DDS (TCP transport protocol) ja CoAP kasutamisel selgus, et CoAP näitas tavaliselt võrreldes madalamat ribalaiuse tarbimist, mis ei suurenenud võrgupakettide kaotuste või suurenenud viivituse korral, erinevalt MQTT-st ja DDS-ist, kus nimetatud stsenaariumides täheldati ribalaiuse kasutamise kasvu. Teises stsenaariumis osales suur hulk seadmeid, mis edastasid andmeid samal ajal, mis on tüüpiline olukord IoT keskkondades. Tulemused näitasid, et suurema koormuse korral on parem kasutada CoAP-i.

Väikese koormuse korral kasutas CoAP kõige vähem ribalaiust, järgnesid MQTT ja REST HTTP. Siiski, kui koormuse suurus suurenes, olid parimad tulemused REST HTTP-l.

Energiatarve

Energiatarbimise küsimus on alati oluline, kuid IoT süsteemis on see eriti tähtis. Kui võrrelda MQTT ja HTTP energiatarbimist, siis HTTP tarbib oluliselt rohkem. CoAP on aga energiatõhusam kui MQTT, lubades toitehalduse. Sellegipoolest sobib MQTT lihtsates stsenaariumides paremini andmevahetuseks asjade interneti võrkudes, eriti kui toite piiranguid ei ole.

Teine katse, mille käigus võrreldi AMQP ja MQTT võimalusi mobiilses või ebastabiilses traadita võrgus, näitas, et AMQP pakub rohkem turvavõimalusi, samas kui MQTT on energiatõhusam.

Turvalisus

Turvalisus on veel üks väga oluline teema, mida tõstatatakse asjade interneti ning äärmiselt/täiendavates arvutustes. Turvamehhanism põhineb tavaliselt TLS-l HTTP-s, MQTT-s, AMQP-s ja XMPP-s, või DTLS CoAP-is, ning toetab mõlemat varianti DDS.

TLS ja DTLS algavad protsessiga, millega luuakse ühendus kliendi ja serveri vahel, et vahetada toetatud krüptoüksikute komplekte ja võtmeid. Mõlemad pooled leppivad kokku komplektides, et tagada, et edasine suhtlemine toimub turvalises kanalis. Nende erinevus seisneb väikestes muutustes, mis võimaldavad DTLS-l, mis põhineb UDP-l, töötada ebakindlas ühenduses.

Kaugjuhtimisega katsekohtumised Mitme erineva TLS ja DTLS rakenduse testimise käigus selgus, et TLS suudab ülesande paremini täita. DTLS-i rünnakud olid edukamad tänu selle vigadele tolerantsele loodusele.

Kuid nende protokollide suurim probleem on see, et need ei olnud algselt mõeldud IoT kasutamiseks ega eeldanud töötamist pilves või udus. Kokku lepitud käepigistusega lisavad nad igaühenduse loomisega lisaliiklust, mis kurnab arvutusressursse. Keskmiselt on TLS-i lisakoormus 6,5% ja DTLS-i omakorda 11% võrreldes turbatava puudumisega. Ressursirikkas keskkonnas, kus kasutatakse tavaliselt, pilve , ei ole see probleem, kuid IoT ja udutasemete vahelises suhtluses muutub see oluliseks piiranguks.

Mida valida? Ühtegi kindlat vastust ei ole. MQTT ja HTTP näivad olevat kõige lootustandvamad protokollid, kuna neid peetakse võrreldes teiste protokollidega suhteliselt küpseks ja stabiilseks lahenduseks IoT-le.

Ühe kommunikatsiooniprotokolli põhised lahendused

Ühe protokolli lahenduse praktikal on palju puudusi. Näiteks proto, mis sobib piiratud keskkonda, ei pruugi töötada domeenis, millel on ranged turvanõuded. Arvesse võttes, tuleb meil jätta peaaegu kõik ühe protokolli põhised lahendused IoT udust pilve ekosüsteemis kõrvale, välja arvatud MQTT ja REST HTTP.

REST HTTP ühe protokolli lahendusena

On hea näide REST HTTP päringute ja vastuste interaktsioonist IoT-st uduni: nutifarm. Loomadele on paigaldatud kantavad andurid (IoT klient, C) ja neid hallatakse nutifarmi süsteemi kaudu pilvcomputing-i kaudu (Fog-server, S).

POST meetodi päises määratakse muudetav ressurss (/{farm/animals}), samuti HTTP versioon ja sisutüüp, mis antud juhul on JSON objekt, mis esindab loomafarmi, mida süsteem peab haldama (Dulcineia/veise). Serveri vastus näitab, et päring oli edukas, saades HTTPS seisundikoodi 201 (resource created). GET meetod peaks määrama ainult nõutava ressursi URI-s (nt /farm/animals/1), mis tagastab selle ID järgi loomade JSON-esitluse serverist.

PUT meetodit kasutatakse, kui on vajalik uuendada teatud kindlat ressursi kirjet. Sellisel juhul määratakse ressursis URI parameetrile, mida on vaja muuta, ja praegusele väärtusele (näiteks märkides, et lehm on just praegu väljaspool, /farm/animals/1?state=walking). Lõpuks kasutatakse DELETE meetodit sama hästi kui GET meetodit, kuid see lihtsalt kustutab ressursi operatsiooni tulemusena.

MQTT kui ühesuunaline lahendus

Võtame sama nutika talu, kuid kasutame REST HTTP asemel protokolli MQTT. Kohalik server, millel on installitud Mosquitto teek, toimib vahendajana. Antud näites teenib lihtne arvuti (töötatakse talu serverina) Raspberry Pi MQTT kliendina, mille teostamiseks on kasutatud MQTT Paho teeki, mis on täielikult ühilduv Mosquitto vahendajaga.

See klient vastab IoT abstraktsiooni tasemele, mis esindab seadet, millel on avastamis- ja arvutusvõimed. Teisest küljest vastab vahendaja kõrgemale abstraktsiooni tasemele, mis esindab udusuhte arvutussõlme, mis on iseloomustatud suuremate töötlemis- ja andmete salvestamise võimetega.

Pakkumisel olevas «nutika talu» stsenaariumis on Raspberry Pi ühendatud akseleromeetri, GPS- ja temperatuurianduritega ning avaldab nende andmete postitamisel udusõlmes. Nagu te tõenäoliselt teate, käsitleb MQTT teemasid kui hierarhiat. Üks MQTT väljaandja võib postitada sõnumeid kindlas teemasete kogumis. Meie puhul on neid kolm. Loomade talli temperatuuri mõõtva anduri jaoks valib klient teema (animalfarm/shed/temperature). GPS asukoha ja loomade liikumise mõõtmise andurite jaoks avaldab klient värskendusi (animalfarm/animal/GPS) ja (animalfarm/animal/movement).

See teave edastatakse vahendajale, kes võib selle ajutiselt salvestada kohalikus andmebaasis juhuks, kui hiljem ilmub mõni muu huvitatud tellija.

Lisaks kohalikule serverile, mis toimib MQTT maaklerina ja kuhu Raspberry Pi, mis on MQTT kliendid, saadavad andmeid sensoritest, võib pilve tasandil olla veel üks MQTT maakler. Sellisel juhul võib kohalikule maaklerile edastatav teave ajutiselt salvestuda kohalikku andmebaasi ja/või saadetakse pilve. Maakler, mis kuulub tunde, kasutatakse selles olukorras, et siduda kõik andmed pilve MQTT maakleriga. Sellise arhitektuuri korral võib mobiilirakenduse kasutaja olla tellitud mõlemale maaklerile.

Ühenduse katkemise korral ühe maakleriga (näiteks pilvega) saab lõppkasutaja teavet teiselt (tundlike). See on iseloomulik tunnus segatud pilve ja tunde süsteemidele. Vaikesätete kohaselt võib mobiilirakendus olla seadistatud esimese ühenduse loomiseks tunde MQTT maakleriga ning ebaõnnestumise korral ühenduse loomiseks pilve MQTT maakleriga. See lahendus on vaid üks paljusid IoT-F2C süsteemide lahendusi.

Mitme protokolli lahendused

Ühe protokolli lahendused on populaarsed oma lihtsama rakendatavuse tõttu. Kuid on ilmselge, et IoT-F2C süsteemides on mõistlik ühendada erinevad protokollid. Idee on, et erinevatel tasanditel võivad töötada erinevad protokollid. Vaatame näiteks kolme abstraktsiooni: IoT, tunne ja pilve tasand. IoT tasandi seadmed peetakse tavaliselt piiratud võimekusega. Selles ülevaates käsitleme IoT tasandeid kui kõige piiratud, pilve kui kõige vähem piiratud ja tunde arvutust kui „midagi nende vahel”. Seega on IoT ja tunde abstraktsioonide vahel praegused protokolli lahendused MQTT, CoAP ja XMPP. Tunde ja pilve vahel on AMQP üks peamisi kasutatavaid protokolle koos REST HTTP-ga, mida kasutatakse ka IoT ja tunde kihtide vahel oma paindlikkuse tõttu.

Põhiprobleem seisneb protokollide funktsionaalses ühilduvuses ja sõnumite lihtsas tõlkimises ühest protokollist teise. Ideaalis peaks tuleviku Interneti asjade arhitektuur pilve ja tunde ressurssidega olema sõltumatu kasutatavast suhtlusprotokollist ja tagama erinevate protokollide head koostööd.

Kuna see hetk ei ole nii, on mõttekas ühendada protokolle, millel pole olulisi erinevusi. Selle eesmärgi saavutamiseks põhineb üks potentsiaalne lahendus kahe protokolli kombinatsioonil, mis järgivad sama arhitektuuristiili, REST HTTP ja CoAP. Teine ettepanek põhineb kahe protokolli ühendamisel, mis pakuvad „väljaanne-tellimise” mudelit, MQTT ja AMQP. Sarnaste kontseptsioonide kasutamine (kuna nii MQTT kui ka AMQP kasutavad vahendajaid, CoAP ja HTTP kasutavad REST-i) lihtsustab nende kombinatsioonide rakendamist ja nõuab vähem integreerimisjõupingutusi.

Joonisel (a) on esitatud kaks mudelit, mis põhinevad päringutel ja vastustel, HTTP ja CoAP, ning nende võimalik asukoht IoT-F2C lahenduses. Kuna HTTP on üks tuntumaid ja laialdaselt kohandatud protokolle kaasaegsetes võrkudes, on ebatõenäoline, et see asendatakse täielikult teiste sõnumivahetusprotokollidega. Tugevate seadmete vahel, mis asuvad pilve ja udude vahel, on REST HTTP mõistlik lahendus.

Teisest küljest on pilve ja IoT tasandite vahel seostumisel, kui seadmed on piiratud arvutusressurssidega, CoAP tõhusam. Üks CoAP-i suuri eeliseid on tegelikult selle ühilduvus HTTP-ga, kuna mõlemad protokollid põhinevad REST-i põhimõtetel.

Joonisel (b) on esitatud kaks „väljaanne-tellimine” mudeli interaktsiooni näidet, sealhulgas MQTT ja AMQP. Kuigi hüpoteetiliselt võiks mõlemat protokolli kasutada suhete loomiseks sõlmede vahel igal abstraktsiooni tasandil, tuleks nende positsioon määrata jõudluse alusel. MQTT on välja töötatud lihtsustatud protokollina piiratud arvutusvõimekusega seadmete jaoks, mistõttu saab seda kasutada seose loomiseks IoT ja udude vahel. AMQP sobib paremini võimsamate seadmete jaoks, mis asetaks selle ideaalselt udude ja pilve sõlmede vahele. IoT-s võib MQTT asemel kasutada protokolli XMPP, kuna seda peetakse kergekaaluliseks. Kuid seda ei kasutata sarnastes stsenaariumides nii laialdaselt.

Järeldused

On ebat, et ükski arutletud protokoll ei pruugi katta kogu süsteemi suhtlust, alates seadmetest, mille arvutusvõimsus on piiratud, kuni pilveserveriteni. Uuringud on näidanud, et kaks kõige perspektiivikamat varianti, mida arendajad sagedamini kasutavad, on MQTT ja RESTful HTTP. Need kaks protokolli on mitte ainult kõige küpsemad ja stabiilsemad, vaid sisaldavad ka hulgaliselt hästi dokumenteeritud ja edukaid rakendusi ning veebiallikasid.

Oma stabiilsuse ja lihtsa seadistamise tõttu on MQTT protokoll, mis on ajaga tõestanud oma suurepärast tulemuslikkust piiratud seadmetega IoT tasemel. Süsteemi osades, kus piiratud side ja aku tarbimine ei ole probleem, nagu näiteks teatud uduvaldkondades ja enamikus pilvekomputatsioonides, on RESTful HTTP lihtne valik. CoAP'i tuleb samuti arvesse võtta, kuna see areneb kiiresti IoT sõnumivahetusstandardina ning on tõenäoline, et lähiajal saavutab see stabiilsuse ja küpsuse tasemega, mis on sarnane MQTT ja HTTP-ga. Kuid standard areneb praegu, mis toob endaga kaasa lühiajalisi ühilduvuse probleeme.

Millest veel huvitavat lugeda blogis Cloud4Y

→ Arvuti teeb teile maitsvaks
→ AI aitab uurida Aafrika loomi
→ Suvi on peaaegu läbi. Peaaegu pole andmeid kaduma läinud
→ 4 viisi, kuidas pilve varundamisel raha säästa
→ Üksne föderaalne teabeallikas, mis sisaldab andmeid elanikkonna kohta

Telli meie Telegram-kanal, et mitte jääda ilma järgmise artikli lugemisest! Kirjutame mitte sagedamini kui kaks korda nädalas ja ainult olulistel teemadel.

Allikas: habr.com