# InfluxDB 101 - verschillen v1, v2 & Cloud

Bedoeling van dit document is een overzicht te verschaffen betreffende de verschillen tussen InfluxDB v1, InfluxDB v2 en de cloud versie. Om de verschillen te kunnen duiden is het belangrijk eerst de basis principes van InfluxDB te begrijpen. Dit document is vooral uit een technisch perspectief geschreven: hoe werkt InfluxDB onder de motorkap. Er werd vooral gefocust op de meest essentiële zaken. Diepgaandere technische zaken zullen op een later moment worden toegelicht.

De bedoeling is dat er na het doornemen van dit document een gefundeerde keuze kan gemaakt worden voor enerzijds de versie en anderzijds het platform.

## OSS vs. cloud / Enterprise

Vooraleer ook maar "echt te starten" is het belangrijk te weten dat er een open-source (OSS) variant, Enterprise en cloud variant is.

De OSS-oplossing is volledig gratis te gebruiken, maar heeft wat beperkingen. Naast bepaalde beperkingen zijn sommige zaken in de andere opties technisch anders geïmplementeerd (zie verder, bv. sharding). Het grootste gemis bij de OSS-versie is feit dat er geen clusters gemaakt kunnen worden. Dit impliceert dat er enkel "single node clusters" kunnen opgesteld worden.

Dit impliceert dat er niet zomaar geschaald en gerepliceerd kan worden. Er moeten dus andere opties / oplossingen bekken worden.

De "Enterprise" variant gaat gepaard met een licentiekost. De exacte kost daarvoor is niet openlijk gecommuniceerd. Op fora is terug te vinden dat het al snel in de grootorde van 10.000 euro oploopt. Hierin zit dan o.a. support en clustering inbegrepen, daarnaast ook een aantal extra features (bv. koppeling LDAP).

De cloud oplossing is eigenlijk de Enterprise oplossing maar dan als een managed service. Hiervan zijn de prijzen wel beschikbaar, om een kosteninschatting te maken zal testing genoodzaakt zijn. Het lijkt in ieder geval een heel stuk goedkoper en eigenlijk de beste oplossing voor Cogenius. Dit op basis van ons klein vooronderzoek.

## v1 vs. v2

De technische verschillen worden vooral verder in dit document besproken. Wat vooral belangrijk is om in het achterhoofd te houden is dat v1 stable is, v1.8 is nog maar pas uit (13/04/2020). V2 is in beta, intussen zitten we aan beta versie 8 (10/04/2020). De nieuwste versie moet in theorie meer features hebben alsook een betere performantie bieden.

### De TICK-stack

Bij InfluxDB wordt er gesproken van de zogenaamde TICK-stack. Telegraf, InfluxDB, Chronograf en Kapacitor. Telegraf wordt vooral ingezet voor het verzamelen van de data (iewat vergelijkbaar met Logstash), InfluxDB zorgt voor de opslag, Chronograf wordt voornamelijk gebruikt voor dashboarding en Kapacitor kan gebruikt worden voor alerting en ETL-doeleinden. Daarnaast gebruiken veel mensen Grafana voor visualisaties i.p.v. Chronograf.

In v1 staan deze componenten vrij los van mekaar. In v2 zijn ze meer met mekaar verweven, wat an sich de stack wat eenvoudiger maakt.

Security wordt centraler beheerd en niet bv. voor elke component afzonderlijk. In v1 dien je de security instellingen per compontent in te stellen. In v2 staan er default reeds een aantal security parameters ingesteld, zoals basic auth. Meer nog, in v2 kan de basic auth niet uitgeschakeld worden, alsook wordt er gewerkt met security tokens en dergelijke.

### De query taal

In versie 1 is vrij gebruikelijk om SQL te gebruiken, weliswaar verreikt met wat extra's. Daarnaast wordt Flux ondersteund, een taal die gelijkt op klassieke SQL.

In versie 2 dien je Flux te gebruiken. Hoeft geen nadeel te zijn, zoals vermeld, gelijkaardig aan SQL. De extra tooling die voorzien is maakt het vrij eenvoudig om data te bevragen.

### InfluxDB Relay

Wanneer er voor de OSS versie geopteerd wordt kan een project genaamd InfluxDB relay het gemis van een cluster in zekere zin opvangen. Merk op dat Relay enkel ondersteuning heeft voor v1. Voor v2 moet er quasi gehoopt worden op een serieuze community effort.

Kort samengevat maakt Relay het mogelijk om de writes te dupliceren over verschillende InfluxDB instanties. Reads kunnen via een degelijke reverse proxy en load balancer (bv. Traefik, HAProxy, cloud load balancers, ...) verdeeld worden over verschillende instanties. Merk dus op dat de schaalbaarheid voor writes gebonden is aan een single node.

Is het een oplossing: ja. Is de oplossing ideaal: nee. Waarom? Uit onze eerste testen is gebleken dat het opzetten ervan niet te onderschatten is. Het is zeker en vast doenbaar, maar vereist wel wat technische kennis. Eens de initiële set-up is voltooid zal er moeten gehoopt worden op verdere ontwikkeling van Relay door de community. Daarnaast zal extra monitoring inbouwen van belang zijn. Aangezien "hosten" absoluut niet de core business van Cogenius is, lijkt me de cloud variant (los van v1 / v2) aangeraden. Clustering werkt in de cloud variant out of the box.

## Write-Ahead Log (WAL)

Om durability van writes te verzekeren wordt er gebruik gemaakt van een Write-Ahead Log (WAL). Het formaat is geoptimaliseerd om snel naar disk te kunnen schrijven maar is niet geschikt om te bevragen.

Elke write / delete wordt toegevoegd aan de WAL. In InfluxDB v1. wordt er een nieuw WAL aangemaakt zodra er 10MB aan data is. Wanneer InfluxDB zou crashen kan de WAL "replayed" worden.

In de cloud variant van InfluxDB v2 is de WAL geen "eenvoudig" bestand. De write-aheads worden verwerkt via Kafka. In de community version wordt er wel nog gebruik gemaakt van bestanden.

## Time-Structured Merge tree (TSM)

Alle data dient opgeslagen te worden. Indien dit in een (enkel) bestand zou gebeuren wordt de omvang al snel te groot. Het doorzoeken (query's) zou te lang duren alsook zou dit bestand niet in het geheugen passen.

InfluxDB maakt daarom gebruik van "Time-Structured Merge Tree" (TSM). De structuur is geoptimaliseerd o, enerzijds data efficient (compact) op te slaan en daarnaast makkelijker te query'en is (makkelijk in-memory laden).

Een TSM bestand groepeert `field values` a.d.h.v. de `series key`, geordend volgens `timestamp`. De `series key` bestaat uit de naam van de `measurement`, de `tag(s)` en de desbetreffende `field key`.

Voorbeeldje uit sample data set (waterniveau):

h2o_feet,location=coyote_creek water_level=2.943,level description="below 3 feet" 1566014400
h2o_feet,location=coyote_creek water_level=2.831,level description="below 3 feet" 1566014760
h2o_feet,location=coyote_creek water_level=2.717,level description="below 3 feet" 1566015120

* `h2o_feet` = `measurement`
* `location=coyote_creek` = `tag (key:value)`
* `water_level` = `field`
* `level_description` = `field`

Tags worden ingezet voor zaken waarop je gaat zoeken. Bv. geef mij eens het gemiddelde waterniveau op een bepaalde locatie. Locatie is daarbij de tag.

Het formaat is kolom-gebaseerd (voordeel voor in-memory). Data wordt ideaal gezien op gelijke tijdsintervallen bijgehouden. I.p.v. alle waarden op te slaan wordt er gebruik gemaakt van offsets en delta's.

Men neemt een bepaalde starttijd, de daaropvolgende record maakt dan gebruik van de offset. De offset is bv. 60 seconden, dat is compacter op te slaan dan de feitelijke timestamp. Idem dito voor de andere waarden. Meestal is het verschil kleiner dan de werkelijke waarde.

Eigenlijk gelijkt dit op de manier waarop jullie nu reeds de data compressen. Om deze in InfluxDB efficient op te slaan zal de data dus eigenlijk eerst moeten gedecompresseerdt worden.

Voordelen TSM:

* Enkel series lezen die nodig zijn om een query uit te voeren (= performantie)
* Compressie: kan meer opgeslagen worden dan werkelijke data
* Structuur die makkelijk te mappen is in-memory

### Hoe werkt een write?

1. Write actie afgevuurd door gebruiker
2. Opslaan in de WAL
3. Opslaan in cache (in-memory)
4. Na 10 min / 25MB data in de WAL (defaults):
1) "Snapshot operation": schrijf in-memory cache weg naar TSM
2) WAL bijwerken
3) Cache clearen

## Time Series Index (TSI)

TSM kan traag worden wanneer de cardinaliteit (= aantal series keys) stijgt. Deze bottleneck wordt weggenomen door de Time Series Index (TSI). Deze datastructuur is geoptimaliseerd voor het opslaan van de series keys.

De TSI werkt volgens een Log-Structured Merge Tree ([LSM](https://en.wikipedia.org/wiki/Log-structured_merge-tree)).

Dus:

* TSM slaat de data op, gegroepeerd volgens de series key
* TSI slaat de series keys op gegroepeerd volgens measurements, tag en field key (merk op: tag, niet: tag**s**)

TSI zal dus volgende beantwoorden:

1) Welke measurements, tags en fields bestaan er?
2) Gegeven een measurement, tag, fields: welke series key bestaan er?

Hierdoor kunnen series keys sneller opgezocht worden, waardoor de cardinaliteit omhoog kan / mag.

## Shard

InfluxDB v1 (v2 zie verder) heeft een vrij simpele sharding oplossing. Een shard is een directory die volgende zaken bevat:

* WAL files
* TSM files
* TSI files

Shards zijn in InfluxDB tijdsgebonden. In InfluxDB maak je een database aan. Een database heeft altijd een retention policy (hoelang moet de data bijgehouden worden; kan oneindig zijn). Daarnaast wordt opgegeven wanneer een shard moet aangemaakt worden. Elke shard bevat de data voor een gegeven start- en eindtijd.

Samengevat

* Database (= bijmekaar horende data) heeft een:
* Retention policy (= data opruim policy) heeft een:
* Duration: wanneer mag de data weg? Deze zal in de "achtergrond" opgekuist worden
* Shard duration: "duurtijd waarin data wordt opgesplitst".

Voorbeeldje: een database heeft een retention policy van 30 dagen. De shard duration is ingesteld op 1 dag. Er zullen bijgevolg ongeveer 30 shards aangemaakt worden.

Gesteld dat de retention policy een duration van 24u heeft en een shard een duration heeft van 1h dan zijn er bijvoorbeeld volgende shards:

Shard 1: 26/04/2019 00:00 - 01:00
Shard 2: 26/04/2019 01:00 - 02:00
Shard ...
Shard 24: 26/04/2019 23:00 - 00:00
Shard 25: 27/04/2019 00:00 - 01:00
Shard 26: 27/04/2019 01:00 - 02:00

Gesteld dat het nu 27/04/2019 1:15 is, dan is shard 26 de zogenaamde hot shard. Shard 26 wordt continue aangepast, er wordt op die shard zo min mogelijk aan compaction en dergelijke gedaan. Simpelweg omdat die data nog te vers is, en nog te veel wordt aangepast. De andere shards zullen wel compaction ondergaan en de oudste zullen stilletjes verwijderd worden. Wanneer precies hangt af van hoeveel load de database te verwerken krijgt: verwijder van oude data is niet prioritair.

Sharding zorgt voor schaalbaarheid en heeft als bijkomend voordeel dat replicatie eenvoudig kan verkregen worden.

**Het slechte nieuws**: dit is maar beperkt ondersteunt in de OSS-versie. Om out-of-the-box te kunnen schalen en repliceren is InfluxDB Enterprise / InfluxDB Cloud vereist.

### Sharding bij InfluxDB v2

In InfluxDB v2 is de sharding (totaal) anders aangepakt. Sharding is nu nog meer gefocust op horizontaal schalen.

De implementatie zoals hierboven beschreven impliceert dat er een WAL, TSM en TSI per shard nodig is. Dit brengt twee problemen met zich mee:

1) Veel redundante data, vooral voor de TSI
2) Writes veroorzaken zowel een write naar TSI evenals TSM (per shard): onnodig veel writes

Naast de performantie impact is ook gebleken dat niet iedereen nood heeft aan retention policies. Veel mensen gebruiken InfluxDB bv. om historische data op te slaan (en te bevragen). Omwille van deze redenen heeft een shard geen duratrion niet meer. Een shard is nu niet meer dan een blok, een blok die kan gebruikt worden om te schalen en te repliceren. Vergelijkbaar zoals bij de meeste andere database / opslagsystemen.

#### Sharding InfluxDB v2 OSS

Aangezien de OSS versie geen clusters ondersteunt heeft sharding weinig toegevoegde meerwaarde. Sharding is niet beschikbaar in de OSS versie. Eigenlijk kan de versie gezien worden als een waarin gebruik gemaakt wordt van exact 1 shard.

## Conclusie / aanbeveling

Wij zouden sowieso de cloud oplossing aanraden. Hiervoor zijn twee belangrijke redenen:

1. Het betreft een managed service (minder onderhoud)
2. Scaling, clustering en replicatie is inbegrepen

De keuze tussen versie 1 en 2 ligt ietwat moelijker. Versie 1 heeft het voordeel stable te zijn en daarnaast een grote community te hebben. Versie 2 is dan weer veel belovend, maar zal ongetwijfeld nog aanpassingen ondergaan. Daarnaast is de community rond versie 2 momenteel logischerwijs nog wat kleiner.

Merk op dat er momenteel nog geen eenvoudige straight-forward manier is om data van v1 naar v2 over te zetten. Het is mogelijk, maar dus niet zonder de nodige extra stappen te nemen. Men voorziet wel eens v2 de GA status heeft bereikt hier werk van te maken.

Het prijs model van v1 en v2 in de cloud is tevens totaal verschillend. Voor v1 is de prijs voornamelijk gebaseerd op de hardware die je nodig denkt te hebben, er is een beperkte keuze. De goedkoopste optie kost $ 249 / maand. In v2 is het prijsmodel afhankelijk van wat je precies verbruikt, wat wellicht goedkoper zal zijn (zie rekenvoorbeeldje hieronder). Tevens is er een "Free plan", de retention policy kan hierbij weliswaar maximaal 30 dagen bedragen.

Pricing v1: https://cloud.influxdata.com/plan-picker
Pricing v2: https://www.influxdata.com/influxdb-cloud-pricing/

| Omschrijving | Aantal | Kost | Totaal / maand (30 dagen) |
| ------------------------- |:----------------------------------------- | -------------- | -------------- |
| Aantal query's / minuut | 5; 300 per uur (0.5s per query) | $0.0015/second | $ 162 |
| Aantal writes in MB / dag | 50MB | $0.0015/MB | $ 2.25 |

Totaal: $ 164,25 / maand

Er is een lichte voorkeur voor versie 2, aangezien dit toch wel wat meer toekomstperspectief biedt en hoogstwaarschijnlijk een lagere kost impliceert.