Woord vooraf. Meneer De Preester D., promotor bachelorproef Mevrouw Deraedt Ann., stage coördinator

0

Woord vooraf Ik ben Rodric Degroote en zit in mijn laatste jaar New Multimedia and Communication Technology (NMCT) aan de Howest in Kortrijk. Ter afsluiting van mijn Bachelor opleiding schreef ik deze scriptie inzake Azure DocumentDB en IoT, Internet of Things. Vorig jaar tijdens Server Side Advanced kwam ik voor de eerste keer tijdens mijn Bachelor opleiding in aanraking met de term IoT. We hebben toen ook enkele situaties opgezet en in realtime gezien wat IoT precies inhoudt. Vanaf dat moment wist ik dat IoT toch een belangrijke factor speelt op vlak van data verzamelen. Het kan in verschillende situaties toegepast worden, mits de juiste infrastructuur. Het zorgt ervoor dat men op bepaalde situaties kan inspelen en ervoor kan zorgen dat het alleen maar voor verbeteringen zorgt. Na een intensieve periode van 4 maanden is het zover. Met het schrijven van dit dankwoord leg ik de laatste hand aan mijn scriptie. Het was een periode waarin ik zeer veel heb geleerd, op professioneel gebied, maar ook op persoonlijk vlak. Zonder hulp van anderen is het schrijven van een scriptie een moeilijke opdracht. Daarom wil ik langs deze weg de volgende personen bedanken voor hun bereidwillige medewerking, begeleiding, steun en informatie. Meneer De Preester D., promotor bachelorproef Mevrouw Deraedt Ann., stage coördinator Ik wil ook mijn ouders en familie bedanken voor de vele moedige woorden en steun gedurende de afgelopen drie jaar. Ik wil graag mijn collega s van mijn stagebedrijf Televic bedanken voor de fijne samenwerking. Tijdens mijn stage, die 60 dagen duurde, heb ik zeer veel bijgeleerd op professioneel gebied. Het was een hechte groep die altijd bereid was om me te helpen. Ik wil in het bijzonder stilstaan bij mijn stagebegeleider bij Televic, meneer R. Lagatie, ik wil je graag bedanken voor de fijne samenwerking en alle kansen die ik bij Televic heb gekregen gedurende mijn stage periode. Tenslotte gaat een woord van dank uit naar alle personen die ik hier onbewust ben vergeten te vermelden en die op één of andere wijze hebben bijgedragen tot de verwezenlijking van deze scriptie. Ik wens de lezer nog veel plezier met het lezen van dit werk en daarmee ook de interessante wereld van Azure DocumentDB en het Internet of Things. Ik hoop dat dit werk een stuk verduidelijking biedt over deze wereld en dat ik U als lezer hopelijk kan aanmoedigen om zelf deze wereld te gaan verkennen en ervaren. Rodric Degroote, 22 maart 2016

Rodric Degroote Academiejaar 2015-2016 Samenvatting Deze scriptie zal aantonen wat Azure DocumentDB te bieden heeft op vlak van IoT en waarom een NoSQL database als Azure DocumentDB zal gebruikt worden. Tegenwoordig wordt er binnen de IoT wereld immens veel data gegenereerd dat het niet altijd mogelijk is om al die data efficiënt te gaan opslaan. Om voordeel te halen uit uw IoT omgeving is het noodzakelijk om over de goede infrastructuur te beschikken. Het doel van deze scriptie is om de gebruiker kennis te laten maken met Microsoft Azure, Azure DocumentDB en Internet of Things. Hiervoor is de volgende onderzoeksvraag opgesteld: Wat heeft Azure DocumentDB te bieden op het vlak van IoT en waarom zou je dit gaan gebruiken? Azure DocumentDB is de opslagmogelijkheid om de terabytes of petabytes aan data te gaan opslaan. Om een antwoord te kunnen formuleren op de onderzoeksvraag werden eerst de verschillende termen zoals Microsoft Azure, NoSQL, Internet of Things en Azure DocumentDB besproken. Daarna werd de focus volledig gelegd op het onderzoeken van Azure DocumentDB op het vlak van IoT. Op basis hiervan bleek dat Azure DocumentDB toch wat te bieden heeft op het vlak van IoT. Het is zeer handig als je het wil combineren met Microsoft Azure services zoals Azure IoT Hub of Azure Stream Analytics. 2

Rodric Degroote Academiejaar 2015-2016 Inhoudsopgave Woord vooraf... 1 Samenvatting... 2 Inhoudsopgave... 3 Figurenlijst... 5 Afkortingen... 6 Verklarende woordenlijst... 8 Voorstelling bedrijf... 10 1 Inleiding... 11 2 Microsoft Azure... 12 2.1 Introductie... 12 2.2 Wat... 12 2.3 On-premises vs Microsoft Azure... 12 2.4 Cloud Computing... 12 2.5 Categorieën... 13 2.5.1 SaaS... 13 2.5.2 PaaS... 13 2.5.3 IaaS... 13 3 NoSQL: The Big Picture... 14 3.1 Introductie... 14 3.2 Wat is NoSQL?... 14 3.2.1 Dynamische Schema... 14 3.3 Sharding... 15 3.3.1 Scale-up... 15 3.3.2 Scale-out... 15 3.4 NoSQL Categorieën... 16 3.4.1 Key-Value store... 16 3.4.2 (Wide) Column store... 16 3.4.3 Document store... 16 3.4.4 Graph database... 16 3.5 ACID vs BASE... 17 3.5.1 ACID... 17 3.5.2 BASE... 18 3.5.3 CAP Theorem... 18 4 Internet of Things: The big picture... 19 4.1 Introductie... 19 4.2 Wat... 19 4.3 De drie C s... 20 4.3.1 Communication... 20 4.3.2 Control en Automation... 20 4.3.3 Cost savings... 20 5 Internet of Things: Protocols... 21 3

Rodric Degroote Academiejaar 2015-2016 5.1 MQTT... 21 5.1.1 Architecture... 21 5.1.2 Security... 21 5.1.3 Quality of Service... 22 5.2 CoAP... 22 5.2.1 Architecture... 22 5.2.2 Quality of Service... 22 5.2.3 Security... 23 5.2.4 Content negotiation... 23 5.3 AMQP... 23 5.3.1 Architecture... 23 5.3.2 Bindings... 24 5.3.3 Quality of Service... 24 5.4 HTTP... 24 6 Azure DocumentDB: The big picture... 25 6.1 Introductie... 25 6.2 Wat... 25 6.3 Voordelen... 25 6.4 Resources... 26 6.4.1 Account... 27 6.4.2 Databases... 27 6.4.3 Collections... 27 6.4.4 JSON document... 27 6.5 Prijzen... 27 7 Azure DocumentDB: Internet of Things... 28 7.1 Internet of Things... 28 7.2 Data... 28 7.2.1 User generated content... 28 7.2.2 Cataloog data... 29 7.2.3 Log data... 29 7.2.4 User preferences data... 29 7.2.5 Device sensor data... 30 7.3 Tools... 30 7.3.1 Azure Stream Analytics... 30 7.3.2 Azure Event Hubs... 31 7.3.3 Azure IoT Hub... 31 8 Azure DocumentDB: use case... 32 8.1 Introductie... 32 8.2 Voorstelling... 32 8.2.1 Opstelling... 32 8.2.2 Uitwerking... 33 9 Conclusie... 34 10 Bronnen- & literatuurlijst... 35 4

Rodric Degroote Academiejaar 2015-2016 Figurenlijst Figuur 2-1 Microsoft Azure platform... 12 Figuur 2-2 Cloud Computing... 13 Figuur 3-1 SQL en NoSQL... 17 Figuur 3-2 CAP Theorem... 18 Figuur 4-1 Internet of Things... 19 Figuur 5-1 MQTT Protocol... 21 Figuur 5-2 AMQP Protocol... 23 Figuur 6-1 Azure DocumentDB... 25 Figuur 6-2 Azure DocumentDB resources... 26 Figuur 7-1 Azure Stream Analytics... 30 Figuur 7-2 Azure IoT Hub... 31 Figuur 8-1 RFID Systeem... 32 Figuur 8-2 Azure IoT Suite... 33 5

Rodric Degroote Academiejaar 2015-2016 Afkortingen IoT SQL SaaS PaaS IaaS NoSQL d.m.v. a.d.h.v. ACID BASE RFID NFC GSM GPRS 3G LTE MQTT TCP IP SSL TLS CoAP UDP HTTP REST Internet of Things Structured Query Language Software as a Service Platform as a Service Infrastructure as a Service Not only SQL door middel van aan de hand van Atomicity, Consistency, Isolation, Durability Base Availability, Soft State, Eventual Consistency Radio Frequency Identification Near Field Communication Global System for Mobile Communications General Packet Radio Service 3de Generatie Long Term Evolution Message Queue Telemetry Transport Transport Control Protocol Internet Protocol Secure Socket Layer Transport Layer Protocol Simple Object Access Protocol User Datagram Protocol Hyper Text Transfer Protocol Representational State Transfer 6

Rodric Degroote Academiejaar 2015-2016 AMQP WWW JSON i.p.v. URI SDK RDBMS Advanced Message Queuing Protocol World Wide Web Javascript Object Notation in plaats van Universal Resource Identifier Software Development Kit Relational Database Management System 7

Rodric Degroote Academiejaar 2015-2016 Verklarende woordenlijst Cloud Applicatie Web applicatie Backup Server Transactie Sensor Bandbreedte HTTP Response HTTP Request Resource Webcliënt Webserver Servers die beschikbaar zijn over het internet die bepaalde services aanbieden. Een programma dat bedoeld is voor eindgebruikers. Een applicatie zal draaien op een bepaald (of meerdere) besturingssysteem. Een programma dat zal draaien op een webserver en via een client (webbrowser) kan benaderd worden. Een reservekopie van je gegevens op een bepaald apparaat. Bij verlies van gegevens kan je die kopie gebruiken om zo uiteindelijk toch geen gegevens te verliezen. Een computer of een programma die diensten zal aanbieden aan clienten. Samenlopende wijzigingen in een database. Ofwel zullen alle transacties uitgevoerd worden of geen enkele. Een object die informatie kan verzamelen en van toepassing kan zijn in de IoT wereld. De hoeveelheid data die men kan versturen in één keer. Hoe meer bandbreedte te, hoe meer data kan verstuurd worden. Het antwoord van de server op een HTTP request. Een antwoord een resultaatcode gaan terugkeren. Enkele gekende resultaatcodes zijn 200 (OK), 404 (Not Found) en 500 (Internal Server Error) Een verzoek naar een server om informatie te verkrijgen. Enkele gekende HTTP-methoden zijn GET, POST, PUT en DELETE Een informatiebron. Computer of software (browser) die je toegang verschaft tot het internet. Apparaat waar men één of meerder websites op host, die toegankelijk zijn voor een webcliënt. Client-server model Een software architectuur voor de samenwerking tussen 2 of meerdere programma s. Een client verstuurd een verzoek naar server en server antwoord hierop. Ad Hoc query Meta-data On the fly query. Een query die je aanmaakt wanneer je het nodig hebt. Die kan iedere keer verschillen telkens die query wordt uitgevoerd. Zal meer informatie geven over andere data. 8

Rodric Degroote Academiejaar 2015-2016 Database User interface Relatie Protocol Stored Procedures Een verzameling van data. Bevat tabellen met daarin rijen. Iedere rij bevat dan een record met eventueel informatie. Het beeld dat de gebruiker te zien krijgt bij het openen van een applicatie of het surfen naar een website. Is een koppeling tussen een tabel A en een tabel B. Er bestaan verschillende soorten relaties namelijk één-op-één, veel-op-veel en één-op-veel. Een set met regels over de manier waarop 2 apparaten met elkaar communiceren. Hierin staat hoe bepaalde boodschappen moeten worden verzonden en hoe de ontvangen boodschappen moeten worden verwerkt. Een programma dat bewaard wordt binnen een database. Het zal draaien binnen de database zelf, op de databaseserver. De stored procedure heeft dan rechtstreeks toegang tot de gegevens die ze moet manipuleren, en hoeft alleen maar het resultaat door te sturen naar de gebruiker. 9

Rodric Degroote Academiejaar 2015-2016 Voorstelling bedrijf Televic ontwikkelt, produceert en implementeert hoogtechnologische en kwalitatieve communicatiesystemen voor specifieke nichemarkten. De groep is dan ook onderverdeeld in onafhankelijke firma s, die elk op hun markt focussen. Ik zal mijn stage volgen in Televic Education. Televic Education ontwikkelt educatieve web-toepassingen, waaronder voornamelijk het online oefen-en testplatform Edumatic. Televic creëert meerwaarde voor de klant door het ontwikkelen van maatwerk en een voortdurende innovatie in state-of-the-art technologie. Onze mensen blinken dan ook uit in wat ze doen, op elk niveau waar ook actief. Televic is een financieel onafhankelijke en stabiele groep. Verder bouwend op onze Europese successen, streven we ook elke dag naar een verdere internationale groei. Momenteel heeft Televic wereldwijd meer dan 400 tevreden mensen in dienst. 10

Rodric Degroote Academiejaar 2015-2016 1 Inleiding Deze scriptie zal het hebben over wat Azure DocumentDB te bieden heeft op het vlak van Internet of Things en waarom je dit zou gaan gebruiken. Azure DocumentDB is een opslagmogelijkheid op het Microsoft Azure platform die recent, afgelopen zomer, werd uitgebracht. Het eerste deel van de scriptie zal gaan over de verschillende termen zoals het Microsoft Azure platform, NoSQL, Internet of Things en Azure DocumentDB. Hier zal er uitgebreid gesproken worden over wat deze termen precies betekenen. Het tweede deel zal gaan bekijken wat Azure DocumentDB nu te bieden heeft op het vlak van Internet of Things en waarom je dit eventueel zou kunnen gebruiken. Er zal vooral gekeken worden welk soort data men kan gaan opslaan in Azure DocumentDB en of het geschikt is om te gebruiken binnenin een Internet of Things omgeving. 11

2 Microsoft Azure 2.1 Introductie Dit hoofdstuk zal het Microsoft Azure platform (zie Figuur 2-1) gaan beschrijven en alsook de techniek dat wordt gebruikt om al hun diensten aan te bieden. 2.2 Wat Microsoft Azure is een Cloud Computing platform ontwikkeld door Microsoft. Hier kan men gebruik maken van verschillende diensten zoals Azure Websites, SQL databases, Men kan in een veilige omgeving op een snelle manier resources aanmaken en onderhouden. Een resource kan meerdere zaken zijn, het kan ofwel eerder software ofwel eerder hardware gericht zijn. Men kan op Microsoft Azure namelijk een virtuele machine (= hardware) maken of anderzijds een web applicatie (= software). Figuur 2-1 Microsoft Azure platform 2.3 On-premises vs Microsoft Azure Met on-premises bedoelt men dat de gebruiker zelf verantwoordelijk is voor zijn eigen infrastructuur. Het is een voordeel als je kennis hebt om zelf zo n infrastructuur op poten te zetten, maar wat indien je niet over deze kennis beschikt? Microsoft Azure biedt hiervoor dan een oplossing. Bij het gebruik van Microsoft Azure hoef je geen rekening meer te houden met het op poten zetten van de hardware infrastructuur. Je bent wel verantwoordelijk voor je eigen software die je host op Microsoft Azure. Je hoeft alleen maar rekening te houden met je software. Software updates, patches zijn nog altijd je eigen verantwoordelijkheid. Een ander voordeel van Microsoft Azure is dat de gebruiker nieuwe versies van zijn software kan deployen zonder rekening te moeten houden met upgrades van de infrastructuur. Azure is hiervoor verantwoordelijk. 2.4 Cloud Computing Cloud Computing (zie figuur 2-2) is een modern alternatief voor de traditionele on-premises datacenters. Door het gebruik van Cloud Computing zal men niet meer zelf verantwoordelijk zijn voor de aankoop van hardware en het onderhoud ervan. De volledige verantwoordelijkheid ligt nu bij de leverancier van het platform, in ons geval Microsoft Azure. De gebruiker kan zo ook bepalen wat hij al dan niet nodig heeft. De prijs zal volledig afhankelijk zijn van de gebruikte resources. Om die resources te onderhouden, zal er meestal bij het gebruik van Cloud Computing ook een online platform aanwezig zijn. Hier kan men dan op een gemakkelijke manier de resources gaan aanmaken en onderhouden. Het Microsoft Azure platform is daar een goed voorbeeld van. 12

2.5 Categorieën Cloud Computing wordt in het algemeen onderverdeeld in 3 categorieën: SaaS, PaaS en IaaS (SPI). Dit zijn termen voor de verschillende soorten services die worden aangeboden. Figuur 2-2 Cloud Computing 2.5.1 SaaS Software as a Service Hier zal men software gaan aanbieden als een service. Hier zal software beschikbaar gesteld worden voor de gebruiker waar meestal een abonnement aan gekoppeld is. Een uitstekend voorbeeld van SaaS is Office 365. Abonnees betalen dan maandelijks of jaarlijks een bedrag om hier gebruik van te mogen maken. Enkele andere voorbeelden van SaaS zijn: Microsoft One Drive, Dropbox, 2.5.2 PaaS Platform as a Service Hier zal de gebruiker een ontwikkelde applicatie laten runnen op een platform. Het platform moet wel PaaS ondersteunen vooraleer je een applicatie kunt gaan toevoegen. Je hebt zelf geen hardware nodig, maar huurt hardware van een 3 de partij. Hoe meer hardware je leent, hoe hoger de prijs zal zijn. Een uitstekend voorbeeld van PaaS is Azure App Service. Hier kan de gebruiker zijn eigen ontwikkelde website gaan hosten op Microsoft Azure. 2.5.3 IaaS Infrastructure as a Service Hier zal de gebruiker gebruik kunnen maken van infrastructuur aangeboden door een Cloud leverancier. Een uitstekend voorbeeld van IaaS zijn de virtuele machines die een gebruiker kan aanmaken op Microsoft Azure. Hier kan je dan een virtuele machine opstarten met als OS Windows Server 2016. 13

3 NoSQL: The Big Picture 3.1 Introductie Dit hoofdstuk zal meer uitleg geven over wat NoSQL precies is en welke categorieën er zijn wat betreft de databases om je data te gaan bewaren. Er zullen ook verschillende technieken aan bod komen om optimaal met je data te kunnen omgaan. Tot slot worden de verschillende soorten principes wat betreft de regels waaraan een NoSQL of SQL database moet voldoen uitgelegd. 3.2 Wat is NoSQL? Not Only SQL NoSQL verschilt op enkele vlakken van de traditionele relationele database (RDBMS). Het zal gebruikt worden om data te kunnen opslaan en ophalen. NoSQL werd ontwikkeld om te gebruiken in situaties waar SQL niet praktisch is. Hiermee wordt bedoeld dat NoSQL vaak wordt gebruikt in situaties waar men data snel en in grote hoeveelheden wilt gaan behandelen (voorbeeld.: IoT), in zo n situaties zou het dan onlogisch zijn om SQL te gaan gebruiken. SQL wordt vaak gebruikt in situaties waar men een gestructureerde aanpak van data wil hebben d.m.v. het gebruik van schema s en relaties. In situaties waar schema s constant zouden moeten veranderen, zou het onlogisch zijn om SQL te gebruiken. Je zou dan ieder moment uw schema moeten aanpassen en de data gaan omzetten naar het nieuwe schema. 3.2.1 Dynamische Schema Relationele databases (SQL) verwachten een schema vooraleer je data kunt gaan opslaan in een database. Wanneer men een persoon met de properties naam, voornaam en adres wil gaan opslaan, dan zal je SQL database op voorhand moeten weten wat je wilt gaan opslaan. Onderstaande afbeelding toont hoe een schema in SQL eruit kan zien. Een nadeel hiervan is dat tijdens het ontwikkelen van een applicatie het schema in je database vaak kan veranderen (dit bij het eventueel implementeren van nieuwe features). Wil je bijvoorbeeld het telefoonnummer van een persoon gaan bewaren, dan moet je eerst een kolom gaan toevoegen, waarna je dan de data gaat migreren naar het nieuwe schema. In tegenstelling tot SQL zal NoSQL standaard geen gebruik maken van een schema om zijn data te gaan bewaren of op te halen. Er zal ook niet gekeken worden wat men zal gaan opslaan. Het ene record zal een key city bevatten, terwijl het andere record dit niet bevat. Dit komt omdat het geen rekening houdt met een schema die vertelt hoe data zal bewaard worden. Doordat men realtime wijzigingen kan aanbrengen aan een NoSQL database zal er minder tijd gespendeerd moeten worden aan de database zelf en zal de ontwikkeling ervan veel sneller verlopen. Developers kunnen in de backend-code van hun applicatie enkele validaties uitvoeren vooraleer de data wordt opgeslaan. Zo kan er enige controle over de data gebeuren, maar behoudt men toch de voordelen van het werken met een dynamische schema. 14

3.3 Sharding Alle servers (database servers, web servers, ) hebben een limiet op het aantal verbindingen dat het kan accepteren en hoeveel data het kan behandelen. Op het moment dat een server op dat limiet komt, kan het zijn dat de server zal vertragen of zelf volledig niet meer beschikbaar zal zijn. Een oplossing hiervoor is het gebruik van sharding. Sharding bestaat uit 2 soorten strategieën namelijk: scaling up en scaling out. Beide soorten zullen in dit hoofdstuk worden uitgelegd. Bij het gebruik van NoSQL databases binnen de omgeving van IoT, zal het belangrijk zijn om aan scaling te doen, dit om ervoor te zorgen dat je data ten alle tijden beschikbaar is. 3.3.1 Scale-up Verticale scaling Bij scaling up zal men de server gaan upgraden. Hier zal men extra geheugen, een snellere processor en meer opslag gaan toevoegen aan de server. Dit zal ervoor zorgen dat de limiet van de server zal verhogen, zodat de server meer verbindingen kan accepteren en data kan gaan behandelen. Meestal is dit maar een voorlopige oplossing, vooral als het aantal verbindingen en data opslag blijft stijgen. De volgende logische stap zou dan zijn om weer aan scale up te doen, maar er komt ooit een moment dat het limiet overschreven zal worden en dat je box te klein zal worden om alles nog te kunnen behandelen. Een oplossing hiervoor zou dan zijn om aan scaling out te doen. Hardware kosten kunnen hoog oplopen Het limiet zal ooit worden bereikt 3.3.2 Scale-out Horizontale scaling Bij scaling out zal men meerdere servers gaan toevoegen aan het netwerk. Een voordeel hiervan is dat er een grote hoeveelheid aan opslag weer beschikbaar zal zijn. De huidige server kan dan als backup apparaat dienen. Wanneer er dan een server stilvalt, kan deze dan worden opgestart, zodat de data altijd beschikbaar zal zijn. Maar het aantal verbindingen kan ook verdeeld worden over alle servers. Hoe meer servers je toevoegt, hoe meer data het inneemt in je datacenter Het implementeren van scaling-out is moeilijker en vereist enige kennis 15

3.4 NoSQL Categorieën Er bestaan 4 categorieën databases binnen de term NoSQL, namelijk de key-value store, de wide column store, de document-store en de graph database. 3.4.1 Key-Value store Deze database komt het meest voor van alle 4 categorieën databases. Het zal ook dienen als basis voor de andere categorieën. De key-value store database zal zijn data gaan bewaren d.m.v. een unieke key en een value. Het opslaan en ophalen van data zal gebeuren a.d.h.v. de key. Enkele voorbeelden: Azure Table Storage, Riak, Redis, 3.4.2 (Wide) Column store Extensible Record Stores De wide column store database zal zijn data gaan bewaren d.m.v. kolommen. Iedere tabel bevat dus rijen van kolommen. Die kolommen (Super kolommen genaamd) kunnen op hun beurt dan een aantal kolommen bevatten. Wide column stores kunnen aanzien worden als een tweedimensionale key-value store database. Enkele voorbeelden: Apache HBase, Cassandra (Facebook), Accumulo, 3.4.3 Document store De document store database zal data gaan bewaren in documents. Dit zijn niet de gewone documenten die we over het algemeen gebruiken (Voorbeeld: PDF, Word en Excel documenten). Het zijn JSON documenten, met properties en values die worden opgeslaan en opgehaald. Enkele voorbeelden: MongoDB, CouchDB en DocumentDB 3.4.4 Graph database De graph database zal zijn data gaan opslaan in een grafiekvorm. Het zal data gaan opslaan in Nodes, die op hun beurt dan properties hebben. Nodes kunnen ook relaties bevatten, die op hun beurt ook properties bevatten. Graph databases zijn ideaal te gebruiken bij applicaties waar relaties zeer belangrijk zijn. Een voorbeeld hiervan is Twitter. Hier kan een persoon A (node) met properties (Name, Lastname, ) een relatie hebben met persoon B (node) met properties (Name, Lastname, ). Die relatie kan dan zijn dat persoon A gestart is met het volgen van persoon B op Twitter. Die relatie kan dan ook eventueel properties bevatten. Enkele voorbeelden: Neo4j 16

3.5 ACID vs BASE De ACID en BASE-regels zijn enkele regels waaraan een database moet voldoen. Deze regels zorgen ervoor dat een transactie betrouwbaar wordt uitgevoerd. Een voorbeeld is het maken van een overschrijving naar een andere account. Hier moet er geld worden afgetrokken van je rekening en gestort worden op de andere rekening. Deze regels zullen ervoor zorgen dat alles correct verloopt. Terwijl SQL databases (RDBMS) meer gebruik zal maken van de ACID-regels, zullen NoSQL databases meer gebruik maken van de BASE-regels (zie Figuur 3-1). BASE is eerder een alternatief voor ACID. Figuur 3-1 SQL en NoSQL 3.5.1 ACID Consistentie over beschikbaarheid Atomicity (Atomair) zorgt ervoor dat alle wijzigingen correct zullen worden opgeslaan. Bij het moment dat er iets fout loopt zullen alle wijzigingen ongedaan worden. Atomicity zal ervoor zorgen dat een transactie volledig of niet wordt uitgevoerd, zodat er geen halve wijzigingen worden doorgevoerd. Als een transactie 100 rijen update en het systeem valt uit na de 20 ste update, dan zal de database de 20 succesvolle wijzigingen ongedaan maken. Consistency (Consistent) hier moet de database zich altijd in een consistente (geldige) staat bevinden. Wanneer er een overschrijving wordt gedaan van rekening A naar rekening B, dan moet zowel het geld op rekening B gestort worden en van rekening A afgetrokken worden. Mocht er zich een fout voordoen, dan zou het niet mogen zijn dat alleen het geld wordt afgetrokken en niet gestort wordt, dit zorgt immers voor inconsistente data. Isolation (Geïsoleerd), alle transacties worden gescheiden van elkaar uitgevoerd. Een transactie zal de data van een andere transactie niet kunnen wijzigen. Durability (Duurzaam), wanneer een transactie voltooid is, dan zal dit ook zo blijven. Bij een herstart van het systeem veroorzaakt door een systeem fout, dan moet de data nog altijd op de correcte manier beschikbaar zijn. 17

3.5.2 BASE Beschikbaarheid over consistentie Base Availability (Beschikbaarheid), zorgt er dus voor dat men een grotere zekerheid heeft dat de meerderheid van je data toch nog beschikbaar zal zijn mocht er zich een probleem op één van de servers voordoen. Availability wordt bereikt door data te gaan repliceren op verschillende servers. Voorbeeld als je data is verdeeld over 5 servers op een verschillende locatie en er valt op het huidig moment één server uit, dan zal een response gestuurd worden met de boodschap dat je data voorlopig niet beschikbaar is (failed). Het zou ook kunnen dat de data op moment van aanvraag inconsistent is, dan zal er ook geen data naar de client worden verstuurd. Soft state, dit is de staat waarin je database zich zal bevinden. Dit wil zeggen dat doordat men gebruik maakt van Eventual Consistency er toch nog wijzigingen kunnen worden doorgevoerd, zelfs op momenten wanneer niemand wijzigingen doorvoert. Eventual Consistency, tijdens het uitvoeren van wijzigingen naar de database zou het kunnen dat op bepaalde tijdstippen je data inconsistent is. Pas wanneer alle wijzigingen zijn doorgevoerd naar alle servers waar de data zich op bevindt, zal je data weer consistent zijn. 3.5.3 CAP Theorem De term CAP Theorem (zie Figuur 3-2) wordt vaak opgehaald bij het onderzoeken van SQL, NoSQL en Big. De CAP Theorem geeft aan dat het onmogelijk is voor distributed computer systemen (meerdere systemen aan elkaar gekoppeld) om zowel Consistency, Availability en Partition Tolerance aan te bieden. Nog even de termen kort beschrijven: Consistency bij het ophalen van data naar eender welke server zal de data altijd gelijk zijn. Het maakt niet uit naar welke server je een request stuurt, de data die je krijgt zal altijd een exacte copy zijn. Availability bij het versturen van een request naar een server zal je altijd een response terug krijgen. Partition Tolerance je volledig systeem blijft draaien, zelfs als er een server niet meer bereikbaar is of wegvalt door een fout. Figuur 3-2 CAP Theorem 18

4 Internet of Things: The big picture 4.1 Introductie Dit hoofdstuk zal het IoT of Internet of Things (zie Figuur 4-1) gebeuren gaan beschrijven. Het zal ook meer informatie geven over de verschillende protocols die gebruikt worden om communicatie mogelijk te maken tussen de verschillende apparaten (zie 5. Internet of Things: Protocols). 4.2 Wat IoT, Internet of Things, is een netwerk van aangesloten apparaten, via kabel of draadloos, die de mogelijkheid heeft om data te gaan versturen en verzamelen zonder enige tussenkomst van een gebruiker. Er zal ook gebruik gemaakt worden van sensors, om bepaalde data te gaan verkrijgen. Enkele technieken die door zo n sensor gebruikt worden op vlak van Local Area Connecties, zijn RFID, NFC, Wi-Fi en Bluetooth. Maar er kan ook gebruik gemaakt worden van Wide Area Connecties, dit zijn dan GSM, GPRS, 3G and LTE. Figuur 4-1 Internet of Things De Things in Internet of Things kan dus eender wat zijn. Het kan een persoon zijn met een hartmonitor die data verzamelt, het kan een wagen zijn die de status van je banden bijhoudt, het kan een serre zijn die bijhoudt wanneer de plantjes worden besproeid, Al die informatie kan in realtime gebeuren of worden bewaard om dan op een later tijdstip weer te geven. Het Internet of Things zal dus verschillende things met elkaar gaan verbinden. Terwijl vroeger gekeken werd om industriële apparaten met elkaar te connecteren, wordt er nu gekeken om alles te connecteren met elkaar, zowel industriële apparaten als dagelijkse middelen die we gebruiken. De data zal worden verzameld a.d.h.v. sensors. De fysieke apparaten zullen elk één of meerdere sensoren bevatten. Iedere sensor heeft zijn eigen functie. Dit kan bijvoorbeeld het opvragen van je locatie of temperatuur zijn, De data gegenereerd door deze sensors wordt eventueel doorgestuurd naar een bepaalde locatie waar men dan de data analyseert. 19

4.3 De drie C s Voordelen Communication, Control and Automation, Cost savings Het Internet of Things heeft zowel een impact op het leven van de gewone mens als dat van bedrijven. Het zal allerlei zaken efficiënter laten voorlopen doordat informatie nog beter en sneller verdeeld kan worden. Terwijl het Internet of Things meerdere voordelen heeft op onze gemeenschap zijn er toch 3 belangrijke voordelen van IoT die een grote impact zullen hebben, waaronder zeker voor de bedrijven. 4.3.1 Communication Een groot voordeel van het Internet of Things is dat communicatie veel vlotter zal gaan verlopen tussen verschillende apparaten. Men zal sneller de informatie krijgen die men nodig heeft en op die manier kan men er dus voor zorgen dat alles efficiënter en kwalitatiever kan verlopen. 4.3.2 Control en Automation De geconnecteerde apparaten kunnen nu op een centrale plaats gecontroleerd worden. Doordat men informatie kan opvragen over een bepaald apparaat kan men bijvoorbeeld zien of een apparaat al dan niet moet worden vervangen. Een ander belangrijk onderdeel is het automatiseren van taken. Dit zal er voor zorgen dat zaken automatisch gebeuren en er geen tussenkomst nodig is van een gebruiker. Dit doordat de apparaten met elkaar kunnen gaan communiceren en zo voor een snellere uitvoeringstijd gaan zorgen. 4.3.3 Cost savings Internet of Things zal vooral voor bedrijven kosten gaan besparen. Al de informatie die zal worden verzameld zal ervoor zorgen dat men precieze data verkrijgt en geen schattingen meer. Hierdoor kan men bepaalde schattingen beter gaan beoordelen. Zoals eerder vermeld zorgt IoT ervoor dat men meer informatie kan opvragen over een bepaald apparaat in de cyclus van een bedrijf. Mocht er zich een probleem voordoen met dat apparaat dan kun je hierop gaan inspelen en deze gaan vervangen. Dit zorgt er voor dat niet heel je proces stilvalt wegens een defecte apparaat. 20

5 Internet of Things: Protocols 5.1 MQTT Message Queue Telemetry Transport MQTT (zie Figuur 5-1) zal ervoor zorgen dat er communicatie mogelijk is tussen client en een broker a.d.h.v. publish en subscribe berichten. Het protocol werkt bovenop het TCP/IP protocol en zal vooral gebruikt worden in omgevingen met beperkte resources. Hiermee bedoel ik dan bijvoorbeeld een netwerk met een lage bandbreedte. MQTT zal niet al te veel bandbreedte gaan gebruiken, maar zal er wel voor zorgen dat het bericht altijd goed verstuurd en ontvangen zal worden. 5.1.1 Architecture Een typische MQTT architectuur bestaat altijd uit een publisher, subscriber en een MQTT Broker. De client kan zowel een sensor of een ander apparaat zijn die communiceert met de server. De server is dan meestal de MQTT Broker. Een MQTT Broker ontvangt dus de berichten (= data) van de sensors en andere apparaten die zich gesubscribed hebben op de broker. Figuur 5-1 MQTT Protocol Een publisher en een subscriber staan volledig onafhankelijk van elkaar. Men kan van elkaar geen informatie terug gaan vinden zoals zijn IP-adres, location,.. Een broker is een centraal apparaat die niets anders doet dan berichten doorsturen en ontvangen. Enkele voorbeelden van MQTT Brokers zijn HiveMQ en Mosquitto. Een broker heeft een topic waarop de sensors en apparaten dan een subscription hebben. Het kan ook zijn dat die apparaten meerdere subscriptions hebben op verschillende topics. 5.1.2 Security Een broker kan ook een gebruikersnaam en wachtwoord vragen vooraleer een klant kan connecteren. Om de privacy te garanderen van die klanten kan de connectie geëncrypteerd worden (SSL/TLS). 21

5.1.3 Quality of Service Wat betreft de Quality of Service binnenin MQTT bestaan er 3 niveaus. 5.1.3.1 Fire and Forget Het bericht zal misschien worden ontvangen, maar dit kan niet met enige zekerheid bevestigd worden. De ontvanger hoeft namelijk niet te bevestigen dat hij het bericht goed ontvangen heeft en het bericht zal ook niet bewaard worden mocht het niet goed ontvangen geweest zijn. Het versturen van zo n bericht kan falen als de klant niet geconnecteerd is met de broker of als er zich een probleem heeft voorgedaan op de server zelf. 5.1.3.2 Delivered at least once Het bericht zal zeker één keer ontvangen en bevestigd moeten worden. Het kan zijn dat het bericht meermaals werd verstuurd wanneer er zich een fout heeft voorgedaan op de server, dit vooraleer het bericht als succesvol werd bevestigd. Het bericht zal worden bewaard tot bevestigd wordt dat het bericht werd ontvangen, zo niet zal het bericht opnieuw worden verstuurd. 5.1.3.3 Delivered exactly once Het bericht zal maximum één keer worden verstuurd. Het bericht zal bewaard worden tot de ontvanger bevestigt dat het bericht succesvol werd ontvangen. Exactly once is de veiligste methode, maar weliswaar de traagste van de drie. Dit komt omdat men zeker wil zijn dat er geen duplicatie van berichten voorkomt. 5.2 CoAP Constrained Application Protocol CoAP zal ervoor zorgen dat elektronische apparaten met elkaar zullen kunnen communiceren over het Internet. Het is vooral bedoeld voor kleine apparaten zoals sensors, switches, Dus in het algemeen voor apparaten die moeten worden bediend en gecontroleerd worden vanop een bepaalde afstand en die maar over een beperkt aantal resources (laag geheugen, trage processor) beschikt. CoAP draait boven op UDP en zal gebruik maken van het interactie model, dit wil zeggen dat er een UDP pakket zal verstuurd worden naar je sensor of ander apparaat en daarna ontvangen we het packet terug met de data. 5.2.1 Architecture Een typische CoAP architectuur bestaat altijd uit een server en een client. Dit wil zeggen dat er een request zal verstuurd worden van de client naar de server, en dat de server hierop zal antwoorden met een response. Om dit te verwezenlijken zal gebruik gemaakt worden van de HTTP methods (GET, POST, PUT en DELETE). CoAP is immers ontwikkeld om te kunnen samenwerken met HTTP en het RESTful web. 5.2.2 Quality of Service Hier kan een ontvangen bericht aangeduid worden als confirmable of non-confirmable. Confirmable berichten zullen verplicht bevestigd moeten worden door de ontvanger, terwijl dit bij nonconfirmable niet verplicht is. Non confirmable werkt een beetje volgens hetzelfde principe als dat van fire and forget principe binnenin het MQTT protocol. 22

5.2.3 Security Omdat CoAP gebruik maakt van UDP en geen TCP, zal er geen gebruik gemaakt kunnen worden van SSL/TLS. 5.2.4 Content negotiation Zoals HTTP, zal ook CoAP content negotiation ondersteunen. Clienten kunnen bepalen a.d.h.v het Accept optie in welk formaat ze hun resources willen ontvangen. De server zal dan a.d.h.v het Content-Type optie de client vertellen in welk soort ze hun resource zullen ontvangen. 5.3 AMQP Advanced Message Queuing Protocol AMQP (zie Figuur 5-2) zal vooral gebruikt worden om berichten tussen applicaties of bedrijven te versturen. Het zal systemen gaan verbinden en bedrijven de informatie aanbieden die ze nodig hebben om alles nog efficiënter te laten verlopen. 5.3.1 Architecture Een basis AMQP architectuur bestaat altijd uit een producer, exchange, queue en subscribers. De broker wordt gevormd door de exchange en de queues samen. Figuur 5-2 AMQP Protocol 5.3.1.1 Producer Een producer wordt ook weleens de publisher genoemd. Een producer zal namelijk een bericht gaan aanmaken (met daarin ook een routing key) en deze dan gaan versturen naar een AMQP server, ook wel de broker genoemd. 5.3.1.2 Broker Een AMQP broker bestaat uit een exchange en eventueel meerdere queues. De Exchange is de plaats waar de producer zijn bericht zal toekomen. De exchange zal dit bericht dan doorsturen naar de juiste queue. Op basis van bindings zal men kunnen bepalen naar welke queue (route) het bericht moet worden doorgestuurd. 23

5.3.1.3 Queues Een queue is de locatie waar berichten worden bewaard en waar berichten worden opgehaald door de subscribers op die queue. 5.3.2 Bindings Een binding zal een relatie gaan beschrijven tussen een exchange en een bericht in de queue. Het zal bepalen naar welke queue een bericht zal verstuurd worden. Als een queue niet gekoppeld is aan een exchange (type), dan zal de queue ook geen berichten gaan ontvangen. Een exchange zal bepalen naar waar het bericht gaat a.d.h.v. het type exchange en de routing key in het bericht. Er bestaan immers 3 verschillende exchange types. Hieronder vind je meer informatie terug over de verschillende types. 1. Direct Exchange Hier zal de routing key, meegegeven met het bericht, overeenkomen met de naam van een bepaalde queue. 2. Fanout Exchange Hier zal men het bericht kopiëren en versturen naar alle queues die verbonden zijn met dit exchange. 3. Topic Exchange Hier kan men gebruik maken van wildcards (%, _) om berichten te gaan versturen naar verschillende geconnecteerde queues. 5.3.3 Quality of Service AMQP maakt gebruik van TCP. Het zal dus zorgen voor een betrouwbare communicatie van punt A naar punt B en omgekeerd. Met betrouwbaar wordt bedoeld dat wanneer een bericht verstuurd wordt en er zich een probleem voordoet, het bericht opnieuw verstuurd zal worden tot het bericht succesvol is toegekomen. Men kan ook instellen per bericht of deze al dan niet durable is. Hiermee zal men bepalen of het bericht zal worden behouden of niet. Zelfs wanneer er zich een probleem voordoet op de broker, zal het durable bericht nog steeds beschikbaar zijn nadat de broker is heropgestart. 5.4 HTTP Hypertext Transfer Protocol HTTP zal zorgen dat er communicatie mogelijk is tussen een webcliënt en een webserver. Het HTTP protocol wordt zowel gebruikt op het World Wide Web (WWW) als op lokale netwerken (hier spreken we dan over een intranet). HTTP maakt gebruikt van het client-server model. Een client zal gebruik maken van een HTTP request om data te gaan ophalen, terwijl de server dan antwoordt met een HTTP response. 24

6 Azure DocumentDB: The big picture 6.1 Introductie Dit hoofdstuk zal meer uitleg bieden over wat Azure DocumentDB (zie Figuur 6-1) nu precies is en wat het te bieden heeft op vlak van opslag en IoT (zie 7. Azure DocumentDB: IoT). Er zal ook gekeken worden wat soort resources er gebruikt worden in Azure DocumentDB en wat de prijzen zijn voor het aanmaken van zo n database. 6.2 Wat Tegenwoordig wordt er zoveel data in omgang gebracht, dat al die gegenereerde data ook nog moet kunnen worden opgeslaan. Hierbij geldt niet alleen de data die zal worden opgeslaan, maar ook de onderliggende data schema kan veel veranderen. Daarom maakt men gebruik van een schema-free NoSQL document database, die een gemakkelijke en snelle manier aanbiedt om ongestructureerde data te gaan ophalen en opslaan. Figuur 6-1 Azure DocumentDB Helaas bieden de meeste schema-free databases niet de mogelijkheid om complexe queries uit te voeren of gebruik te maken van transacties. Om dit te verwezenlijken heeft Microsoft Azure, Azure DocumentDB ontwikkeld. Azure DocumentDB is een simpel en schaalbare NoSQL database dat zich meer focust op advanced beheermogelijkheden zoals SQL-based query taal, stored procedures en atomaire (zie 3.5.1 BASE) transacties 6.3 Voordelen Voordelen Mogelijkheden Hieronder vind je enkele voordelen bij het gebruik van Azure DocumentDB. Azure DocumentDB is een schema-free NoSQL document service ontwikkeld voor moderne, mobiele en web applicaties. Azure DocumentDB zal ervoor zorgen dat je data op een snelle manier kan gaan ophalen of opslaan. Het biedt een flexibel schema aan en de mogelijkheid om aan scale up of scale down te doen. Zoals eerder vermeld zal het geen schema verwachten om de JSON documents bij te gaan houden, want deze worden by default automatisch geïndexeerd. In DocumentDB zal je ook gebruik kunnen maken van complexe ad hoc queries. Dit zijn queries die niet bepaald kunnen worden tot op het moment dat de query wordt aangemaakt. Het wordt aangemaakt op het moment dat er informatie nodig is en het bestaat uit dynamische gestructureerde SQL delen. 25

Doordat Azure DocumentDB gebruik maakt van JSON documents zal het ervoor zorgen dat je je schema gewoon kunt aanpassen, zonder zich zorgen te maken om eventuele data die je kan verliezen. Door de diepe integratie van Javascript in Azure DocumentDB zal je ook je applicatie logica op een efficiëntere en directe manier kunnen gaan uitvoeren. Azure DocumentDB was namelijk één van de eerste services die gebruik maakte van de Javascript engine (chakra) om zo de mogelijkheid te bieden om te gaan programmeren binnenin de database engine. Microsoft Azure staat ook volledig in voor het beheer van je database en de bijhorende machine resources. Omdat het beschikbaar is als een database-service, hoef je zich geen zorgen te maken over het beheer van virtuele machines of van eventuele deploy en configuratie software. Microsoft Azure zal ook automatisch zorgen voor een backup van je data. Hierdoor kan je de volledige focus leggen op het ontwikkelen van uw applicatie i.p.v. teveel tijd te spenderen aan het beheren van je database. 6.4 Resources Azure DocumentDB behandelt data door het gebruik van goed omschreven database resources (zie Figuur 5-2). Deze resources zullen ook gerepliceerd worden om zo een hoge beschikbaarheid aan te bieden. Al die resources kunnen ook bereikt worden a.d.h.v. een logische URI. Een URI zal gebruikt worden om anderen toegang te geven tot die bepaalde resource. Azure DocumentDB zal hiervoor een simpele HTTP RESTful communicatie model gaan voorzien voor alle resources. Figuur 6-2 Azure DocumentDB resources Alle resources binnen het concept van Azure DocumentDB zullen voorgesteld en opgeslaan worden als JSON documenten. De resources zullen aangezien worden als een item en zal dus een JSON document zijn, met weliswaar meta-data inbegrepen. 26

6.4.1 Account Wanneer je gebruik wilt maken van Azure DocumentDB moet je eerst in het bezit zijn van een Azure subscription. Zo n Azure subscription zal je toegang geven tot de services die Microsoft Azure aanbiedt, hieronder bevindt zich namelijk Azure DocumentDB. Eénmaal je zo n Azure subscription hebt, kun je overgaan tot het aanmaken van een DocumentDB database account. Een DocumentDB database account is een unieke namespace die je toegang geeft tot het gebruik van Azure DocumentDB. 6.4.2 Databases Iedere DocumentDB database account kan één of meerdere collections en users bevatten. Een collection zal dienen als beschikbare data partitie voor het behandelen en opslaan van data. Je kan meerdere databases gaan aanmaken onder een DocumentDB database account. 6.4.3 Collections Iedere JSON document zal automatisch door Azure DocumentDB geïndexeerd worden, wat het filteren en sorteren van documenten gemakkelijker maakt. Het uitvoeren van een query zal altijd gebeuren op een collectie. Hier zal je data bewaard en opgehaald worden. Je kunt een database collection aanmaken op het Microsoft Azure platform of door gebruik te maken van de aangeboden DocumentDB SDK s. Enkele SDK s die Microsoft Azure aanbiedt voor Azure DocumentDB zijn.net SDK, Node.js SDK, Java SDK, Python SDK en Javascript SDK 6.4.4 JSON document Iedere collection kan op zijn beurt meerdere JSON documenten bevatten. Deze kunnen allemaal een verschillend schema bevatten wat heel gemakkelijk is bij het gebruik van dynamische schema s. Wanneer je zelf geen ID meegeeft in je JSON document, zal Azure DocumentDB dit automatisch gaan doen. Even ter verduidelijking, bij het opslaan van data moet je gebruik maken van het JSON formaat. Je kan geen gewone pdf, excel en word documenten gaan opslaan bij het gebruik van Azure DocumentDB. Met documenten worden JSON documenten bedoeld. 6.5 Prijzen Betalen voor de gebruikte resources Azure DocumentDB zal zijn prijzen berekenen a.d.h.v. het aantal verzamelingen binnenin een Azure DocumentDB database account. Elk account kan dus één of meerdere databases bevatten en heeft ook geen limiet wat betreft het aantal verzamelingen in een database. Er is wel default een limiet van 100 verzamelingen ingesteld maar dit kan worden aangepast. Azure DocumentDB verzamelingen zijn beschikbaar in verschillende service lagen. Een verzameling zal per uur gefactureerd worden, afhankelijk van het soort verzameling die je hebt aangemaakt zal de prijs variëren. Bij het aanmaken van een verzameling S1 ben je hier niet aan vastgebonden. Het is perfect mogelijk om eerst een S1 verzameling aan te maken en daarna te gaan scalen naar een S3 verzameling en daarna terug naar een S1 verzameling. 27

7 Azure DocumentDB: Internet of Things 7.1 Internet of Things Azure DocumentDB is een opslag mogelijkheid voor het opslaan van je data. Het zal dan ook alleen maar gebruikt kunnen worden binnen IoT om de gegeneerde data van IoT apparaten te gaan opslaan en ophalen a.d.h.v. samengestelde queries. Azure DocumentDB wordt ook gehost als een database-service op het Microsoft Azure platform. Dit zal er dus voor zorgen dat je ook gebruik kunt maken van andere services op het platform in combinatie met Azure DocumentDB. Het biedt enkele handige tools aan voor bedrijven om gemakkelijk IoT oplossingen te gaan ontwikkelen en deployen. Enkele gekende voorbeelden hiervan zijn Azure Stream Analytics, Azure Event Hubs en Azure IoT Hub. Op het Microsoft Azure platform zal je ook een visueel overzicht te zien krijgen van uw Azure DocumentDB database. Hier kan je op een gemakkelijke manier je data gaan beheren. Azure DocumentDB maakt gebruik van dynamische schema s. Dit zal ervoor zorgen dat je niet vastgebonden bent aan een bepaalde schema. In principe zal dan iedere IoT omgeving die gebruik maakt van zo n schema s Azure DocumentDB kunnen gaan gebruiken. In een IoT omgeving heb je verschillende factoren waar je rekening mee moet houden. Je hebt een apparaat die data zal genereren en een apparaat die de data zal ontvangen. Maar een IoT omgeving zal niet alleen blijven bij het versturen en ontvangen van data. Men kan ook analyse tools gaan gebruiken om die data te gaan analyseren en eventueel te filteren. Eénmaal je data bewaard is kan het op een visuele manier worden voorgesteld. Soms wordt er ook verwacht dat je data zal worden bewaard. Hier is een tool zoals Azure DocumentDB dan handig om te gebruiken. Maar welk soort data zal geschikt zijn bij het gebruik van Azure DocumentDB? Zoals eerder vermeld zal het alleen maar JSON documenten kunnen gaan opslaan. In feite zal het kunnen gebruikt worden in iedere omgeving waar men JSON documenten wilt gaan opslaan. Maar wat zal er bewaard worden in zo n JSON document? (zie 7.2 Data) 7.2 Data Azure DocumentDB kan gebruikt worden om verschillende soorten data te gaan opslaan. Hieronder vind je terug welk soort data vooral in Azure DocumentDB wordt bewaard. 7.2.1 User generated content Eén van de mogelijkheden waarom Azure DocumentDB kan gebruikt worden is om user generated content (UGC) van web en mobiele applicaties te gaan bewaren. Enkele UGC voorbeelden zijn chat sessies, tweets, blog posts, ratings en comments. New Republic heeft recent besloten om Azure DocumentDB te gebruiken om zijn User generated content te gaan opslaan. De inhoud van die chat sessies, comments, posts, kunnen bewaard worden in Azure DocumentDB zonder enige zorgen te maken over het relationeel mappen van je objecten enz. Het heeft ook als voordeel dat men gebruik maakt van dynamische schema s. Het toevoegen van een propertie kan eenvoudig worden toegepast, waardoor men sneller kan gaan ontwikkelen. Klant: News Republic 28

7.2.2 Cataloog data Een andere mogelijkheid voor het gebruik van Azure DocumentDB is het bijhouden van cataloog data. Hier zal men in bepaalde scenario s attributen voor entities zoals klanten, plaatsen of producten gaan bijhouden. Enkele voorbeelden van cataloog data zijn user accounts, product catalogen, apparaat registraties voor IoT, stuklijst systemen enz. Die attributen kunnen veranderen met tijd om te voldoen aan de eisen van een applicatie, vandaar dat het gebruik van een schemaless database een voordeel zal bieden tijdens het ontwikkelen en onderhouden van je applicatie. Klant: Telenor With Azure DocumentDB, we didn t have to say no to the business, and we weren t a bottleneck to launching the promotion in fact, we came in ahead of schedule. Andreas Helland, Telenor, Mobility Architect 7.2.3 Log data Een andere mogelijkheid voor het gebruik van Azure DocumentDB is het bijhouden van log data. Logging gebeurt meestal in grote volumes en zal niet gebonden zijn aan een vast schema (bevatten meestal verschillende attributen). Log data zal ook geen complexe relaties gaan bevatten wat Azure DocumentDB ideaal maakt voor dit soort data. Een ander voordeel is dat log data meestal zal gegenereerd worden in JSON bestanden omdat het een lightweight format is en gemakkelijk te lezen voor de gebruikers. Klant: Telenor 7.2.4 User preferences data Een andere mogelijkheid voor het gebruik van Azure DocumentDB is het bijhouden van user preferences data. Gebruikers zullen bij het aanmaken van een account op een web of mobiele applicatie enkele voorkeuren kunnen instellen. Deze instellingen kunnen dan bewaard worden in Azure DocumentDB. Bij het opstarten van je applicatie zal men op een snelle manier die data kunnen ophalen om zo de user interface exact te renderen zoals de gebruiker eerder heeft ingesteld. Om dit te verwezenlijken zal er gebruik gemaakt worden van het JSON formaat omdat het gemakkelijk te lezen is door Javascript. Vandaar dat Azure DocumentDB ideaal is voor het opslaan van user preferences data. Azure DocumentDB biedt ook tunable consistency aan wat ervoor zorgt dat data snel kan worden opgehaald met lage latency writes. Klant: SGS International With Azure, you can spin infrastructure up and down quickly, with no loss of investment. You can simply be more responsive to the business. You can say yes instead of no. Shane Davis, SGS International, Senior Director 29

7.2.5 Device sensor data Een andere mogelijkheid voor het gebruik van Azure DocumentDB is het bijhouden van apparaat sensor data. Hier zal er meer gericht gekeken worden naar het feit waarom Azure DocumentDB kan gebruikt worden binnen de omgeving van IoT, die namelijk data van miljoenen geconnecteerde apparaten kan verzamelen. Men zal data die later moet worden opgehaald om visueel voor te stellen gaan bewaren in Azure DocumentDB. Eénmaal de data is bewaard kan het later gebruikt worden om queries op toe te passen (ophalen van data). Het kan gecombineerd worden met tools zoals Analytics Stream om zo data te gaan reduceren, en later terug te gaan bewaren in Azure DocumentDB. Data bewaard in Azure DocumentDB kan gebruikt worden als referentie data als onderdeel van real time analytics. 7.3 Tools 7.3.1 Azure Stream Analytics Realtime-verwerking van streaminggegevens in de Cloud. Azure Stream Analytics (zie Figuur 7-1) zal je data gaan analyseren en beheren op een zo n snel mogelijke manier. Het is een handige analyse oplossing om in realtime een overzicht te krijgen van de gegenereerde data van al je IoT apparaten. Azure Stream Analytics kan ook in combinatie met Azure DocumentDB gebruikt worden. Data die geanalyseerd werd door Azure Stream Analytics kan rechtstreeks opgeslaan worden in Azure DocumentDB. Binnen IoT wordt er zeer veel data gegenereerd maar men heeft niet altijd alle data nodig. Op Azure Stream Analytics kan je de data gaan filteren (SQL-based) op bepaalde criteria s wat ervoor zorgt dat je minder opslag nodig hebt. Azure Stream Analytics is ook volledig geïntegreerd met Azure Event Hubs (zie 7.3.2 Azure Event Hubs). Figuur 7-1 Azure Stream Analytics 30

7.3.2 Azure Event Hubs Telemetrieopname op Cloudniveau uit websites, apps en apparaten Azure Event Hubs is een publish en subscribe (zie 5.1 MQTT) service die miljoenen events per seconde real-time zal gaan verwerken van geconnecteerde apparaten en applicaties. Nadat er data is verzameld in de Event Hub, kun je de data gaan bewaren in een Azure DocumentDB of een andere NoSQL oplossing. Een andere mogelijkheid is om de data te gaan analyseren door een tool zoals Azure Stream Analytics en dan de overgebleven data gaan opslaan in Azure DocumentDB of een visueel overzicht te gaan tonen op een webapplicatie. 7.3.3 Azure IoT Hub Public Final Azure IoT Hub (zie Figuur 7-2) heeft sterke gelijkenissen met Azure Event Hubs, maar verschilt toch op enkele vlakken. Azure IoT Hub zal ervoor zorgen dat je al je IoT apparaten op een eenvoudige en snelle manier zal kunnen verbinden. Het zal ook ondersteuning bieden voor verschillende besturingssystemen (Linux, Windows, ) en protocollen (HTTP, AMQP en MQTT). Het zal gebruik maken van bidirectionele communicatie tussen de verschillende aangesloten IoT apparaten. Een apparaat zal kunnen communiceren met de Cloud en zo de status kunnen gaan doorsturen van het apparaat naar bv. Azure IoT Hub, terwijl de Cloud ook zal kunnen communiceren met de aangesloten apparaten om bv. een melding te versturen naar het apparaat. Figuur 7-2 Azure IoT Hub 31

8 Azure DocumentDB: use case 8.1 Introductie Dit hoofdstuk zal een use case gaan bespreken die een duidelijk beeld zal geven over hoe men Microsoft Azure en Azure DocumentDB kan gebruiken in een IoT omgeving. 8.2 Voorstelling Locatie Tracking 8.2.1 Opstelling Als men spreekt over locatie tracking dan denkt men meestal aan services zoals Bing Map, Google Maps of aan bedrijven zoals UPS of FedEx waar men op ieder moment de locatie van je pakket kan gaan bekijken. Maar er is ook nog een ander type van locatie tracking dat zeer handig zou uitkomen voor bedrijven namelijk het tracken van personeel en/of activa binnen het bedrijf. RFID is een technologie die hiervoor kan gebruikt worden voor dit soort van tracking mits GPS niet volledig betrouwbaar is om binnen een bedrijf te gebruiken mocht men heel het bedrijf willen in kaart brengen. Om het personeel of activa te tracken binnen het gebouw kan men iedereen voorzien van een RFID tag. De RFID readers worden dan geplaatst op belangrijke plaatsen in het gebouw zoals in-en uitgangen en de hallen van het gebouwen. Iedere keer een personeelslid passeert langs zo n reader dan wordt dit geregistreerd in de database. Iedere beweging van een personeelslid zal dus geregistreerd worden (verlaten van een lokaal, verlaten van het gebouw, ) Figuur 8-1 RFID Systeem Naast de vermelde readers, kan men ook gebruik maken van mobiele RFID readers die geconnecteerd zijn met WI-FI. Deze kunnen dan gebruikt worden om producten handmatig te scannen. Dit kan dan gekoppeld worden met software die het mogelijk maakt om producten hun locatie te gaan registreren wanneer ze bijvoorbeeld aankomen en in de stock worden geplaatst. Heel dit systeem kan opgezet worden in combinatie met het Microsoft Azure Platform en alsook Azure DocumentDB. Hieronder vind je terug hoe dit zal verlopen. 32

8.2.2 Uitwerking RFID-reader Azure IoT Hub Azure Stream Analytics Azure DocumentDb Kort samengevat zal iedere keer een personeelslid passeert langs zo n RFID reader zal zijn locatie worden doorgestuurd naar de Azure IoT hub via AMQP (zie 5.3 AMQP), HTTP (zie 5.4 HTTP) of een ander protocol die dan op zijn beurt de data kan gaan opslaan in Azure DocumentDB. De RFID reader zal in verbinding staan met een software programma die al de nodige data (naam personeelslid, tijdstip, datum, ) zal gaan verzamelen en bijhouden (in JSON formaat). Het apparaat waarop de software draait zal rechtstreeks in connectie staan met een Azure Service, in dit geval Azure IoT Hub (zie Figuur 7-2). Mocht je apparaat draaien op een protocol die Azure IoT Hub (AQMP of HTTP) niet ondersteunt, dan kun je gebruik maken van een eigen geconfigureerde Cloud protocol gateway. Eénmaal je apparaat geconnecteerd is met Azure IoT Hub dan kan je de data gaan versturen. Mocht er analyse van je data (registratie personeel) nodig zijn dan kun je gebruik maken van Azure Stream Analytics. De output van Azure Stream Analytics, in JSON formaat, kun je dan gaan opslaan in Azure DocumentDB of een andere NoSQL optie op het Microsoft Azure platform. Figuur 8-2 Azure IoT Suite Nadat de registratie van je personeel is opgeslagen in Azure DocumentDB kan je dit ook gaan ophalen. Een voorbeeld hiervan is om een visueel overzicht te tonen van de registraties van je personeel. Zo kan je duidelijk zien waar je personeel zich precies bevindt. Dit kun je verwezenlijken door het aanmaken van een Azure App Service, die dient om een eigen ontwikkelde website te hosten op het Microsoft Azure platform. 33