Shutterstock
Vers van een onlangs aangekondigde financieringsronde van $40 miljoen B, diversifieert Timescale zijn TimescaleDB-platform met een aantal doelen: het schaalbaarder maken en een nieuwe analyse-engine.
Zoals we opmerkten toen we afgelopen herfst de algemene release van Amazon Timestream bespraken, zijn tijdreeksplatforms een oude, maar plotseling nieuwe categorie in het databaselandschap. Hoewel IoT vaak wordt genoemd (of de schuld krijgt) van het resultaat in databaseactiviteit in tijdreeksen, zijn er tal van scenario's (bijvoorbeeld in kapitaalmarkten, transport en logistiek, enz.) waarin tijd de bepalende parameter is.
Maar laten we deze bekentenis nu meteen van ons afzetten: TimescaleDB is een merknaam die gemakkelijk wordt verward met Amazon Timestream (OK, Timescale kwam als eerste op de markt). Als gevolg hiervan struikelen we heel vaak over al deze bijna identieke branding en kwamen we in de wereldwijde vervangingsmodus terecht om ervoor te zorgen dat we de juiste namen in de juiste zinnen zetten.
Timescale is een van die quasi-open source-bedrijven die zijn eigen licentiesmaak van de maand heeft toegepast om klanten aan te moedigen om met code te spelen en deze te verbeteren, maar om te voorkomen dat de AWS's van de wereld database-cloudservices lanceren op de community-editie. De 2.0-versie die een paar maanden geleden werd uitgebracht, liberaliseerde de licenties enigszins om klanten aan te moedigen de code aan te passen.
In tegenstelling tot het bekendere InfluxDB, is Timescale erg in de SQL-modus, zoals Amazon Timestream. Maar in tegenstelling tot Timestream is TimescaleDB een PostgreSQL-variant. TimescaleDB voegt zich dus bij wat letterlijk een menigte is in de PostgreSQL-gemeenschap, maar het is uniek omdat het een van de weinige, zo niet de enige, PostgreSQL-varianten is die specifiek zijn ontworpen voor tijdreeksgegevens.
Timescale heeft in februari versie 2.0 uitgebracht en is nu maandelijks op gang met verschillende dot-releases sindsdien. Als er een gemeenschappelijk thema is voor de huidige releases, dan gaat het om het uitschalen van het platform, het ondersteunen van gedistribueerde implementatie en het op termijn uitbreiden van het platform om analyses te ondersteunen.
Hoewel analyse erg handig zou moeten zijn voor gebruiksgevallen van tijdreeksgegevens, zijn de meeste tijdreeksdatabases niet gebouwd voor diepgaande of complexe analyses. Ironisch genoeg is dat toe te schrijven aan de hoeveelheid onbewerkte gegevens die binnenstromen; de meeste tijdreeksdatabases downsamplen (bijv. comprimeren of archiveren) van oude gegevens om de opslagkosten onder controle te houden. De onlangs geïntroduceerde functies van TimescaleDB omvatten de mogelijkheid om inkomende realtime (niet-gecomprimeerde) gegevens te analyseren met gecomprimeerde historische gegevens. Daarover zo meteen meer.
Het hoogtepunt van nieuwe functies is ondersteuning voor gedistribueerde implementatie met meerdere knooppunten. Om het uit te leggen, moeten we onder de dekens duiken om de unieke architectuur van TimescaleDB uit te leggen. Veel operationele databases zijn afhankelijk van sharding, waarbij ze verschillende delen van dezelfde tabel over meerdere knooppunten verdelen. Hoewel het geen relationele database is, is het wel hoe MongoDB uitschaalt. Maar TimescaleDB vertrouwt op een iets andere constructie, die het een “chunk” noemt.
Een chunk is als een database die alleen kan worden toegevoegd, omdat bij tijdreeksgegevens verreweg de meeste activiteit wordt uitgevoerd met schrijven of invoegen in plaats van met wijzigingen. En de schrijfbewerkingen zijn meestal in opeenvolgende tijdsintervallen, wat in contrast staat met de meer willekeurige distributie die gebruikelijk is bij de meeste transactiedatabases. Voor Timescale is een chunk in wezen een shard die ook meerdere time slice-partities heeft. Wanneer het tijd is om een nieuwe tijdpartitie in de chunk toe te voegen, voegt het systeem deze gewoon toe; het is niet nodig om het systeem opnieuw te balanceren of opnieuw te laden omdat de nieuwe partitie aaneengesloten zal zijn. En al deze brokken worden gelezen als één uniforme logische tabel, hoewel deze onder de dekens zwaar is gepartitioneerd en geshard. Een groep gekoppelde chunks in TimescaleDB wordt beheerd als hypertabellen waardoor de hele assemblage eruitziet als één fysieke tabel.
Tot nu toe konden hypertables alleen op één knooppunt draaien. In de 2.x-generatie kunnen hypertabellen zich echter over meerdere knooppunten verspreiden met al hun residente chunks. Het resultaat is dat TimescaleDB, dat tot nu toe terabytes aan gegevens kon bevatten, nu kan worden opgeblazen tot een petabyte-bereik.
Nu Timescale kan uitschalen, is de volgende logische stap het toevoegen van de mogelijkheid om een volledig cluster van tabellen te repliceren voor hoge beschikbaarheid en om de middelen te bieden voor het opnieuw in evenwicht brengen van oudere chunks over het cluster. Dat is gebaseerd op de aanname dat bij tijdreeksgegevens alleen de meest recente tijdsegmentpartities actief zijn. Beide functies staan op de roadmap.
Een andere recente verbetering heeft ook te maken met schaal. Hoewel tijdreeksdatabases schrijfintensief zijn, is het nodig om query's uit te voeren. Tot nu toe waren voor het vinden van unieke waarden volledige tabelscans van de index vereist. Andere relationele databases, zoals Oracle, MySQL, IBM Db2 en CockroachDB hebben al functies waarmee scans irrelevante waarden in samengestelde indexen kunnen overslaan (bijvoorbeeld indexen die op meerdere kolommen sorteren). PostgreSQL heeft dat echter gemist, dus voorlopig voegt TimescaleDB zijn eigen skip-scanfunctie toe. Wanneer en als de PostgreSQL-gemeenschap deze leemte opvult, verwachten we dat Timescale dit waarschijnlijk zal backporteren.
De nieuwste versie van releases heeft ook de compressie gestroomlijnd, zodat je schrijft naar chunks die al zijn gecomprimeerd. Net als andere tijdreeksdatabases past Timescale compressie toe op oudere waarden — het doet dit via een kolomweergave die het een paar jaar geleden heeft geïntroduceerd.
Oké, laten we de analyse-thread weer oppakken. Ze kondigen een nieuw project aan om een analyse-engine toe te voegen — deze zal om voor de hand liggende redenen afzonderlijk van de bestaande operationele TimescaleDB-engine worden beheerd — analytische query's verbruiken bronnen anders dan operationele transacties. Maar op dit moment is analytics nog steeds een streven; Timescale heeft contact opgenomen met de gemeenschap voor reactie en begeleiding. We hopen dat, in tegenstelling tot rivalen zoals InfluxData, de nieuwe engine gebaseerd zal zijn op dezelfde onderliggende technologiebasis als de bestaande.
Big Data
Waar is IBM's hybride cloud lanceerplatform? Zeven manieren om realtime technologie echt te maken voor uw organisatie Machine learning aan de edge: TinyML wordt groot Wat biedt Cloudera nu? McDonald's wil machine learning 'democratiseren' voor alle gebruikers in al haar activiteiten
gerelateerde onderwerpen:
gegevensbeheer Digitale transformatie Robotica Internet of Things Innovatie Enterprise Software 