Shutterstock
Frisk fra en nyligt annonceret finansieringsrunde på $ 40 millioner B diversificerer Timescale sin TimescaleDB-platform med et par mål: at gøre den mere skalerbar og tilføje en ny analysemotor.
Som vi bemærkede, da vi diskuterede den generelle udgivelse af Amazon Timestream sidste efterår, er tidsserieplatforme en gammel, men pludselig ny kategori i databaselandskabet. Selvom IoT ofte citeres (eller bebrejdes) for resultatet af tidsseriedatabaseaktivitet, er der adskillige scenarier (fx på kapitalmarkeder, transport og logistik osv.), Hvor tid er den definerende parameter.
Men lad os få denne tilståelse væk fra vores kister lige nu: TimescaleDB er et mærke, der let forveksles med Amazon Timestream (OK, Timescale kom først ud på markedet). Som et resultat finder vi os ofte, at vi snubler over al denne næsten identiske branding og befandt os i at gå i global udskiftningstilstand for at sikre, at vi sætter de rigtige navne i de rigtige sætninger.
Timescale er en af de kvasi-open source-virksomheder, der har anvendt sin egen licenssmag i måneden for at tilskynde kunderne til at lege med og forbedre koden, men forhindre verdens AWS'er i at lancere databaseskytjenester på sin community-udgave. 2.0-versionen, der blev frigivet for et par måneder tilbage, liberaliserede licensen lidt for at tilskynde kunderne til at tilpasse koden.
I modsætning til bedre kendte InfluxDB er Timescale meget i SQL-tilstand, ligesom Amazon Timestream. Men i modsætning til Timestream er TimescaleDB en PostgreSQL-variant. Således slutter TimescaleDB sig til det, der bogstaveligt talt er en skare i PostgreSQL-samfundet, men det er unikt at være en af de få, om ikke den eneste, PostgreSQL-varianter, der er specielt designet til tidsseriedata.
Timescale udgav version 2.0 tilbage i februar og er nu på en månedlig kadence med flere prikudgivelser siden da. Hvis der er et fælles tema for de aktuelle udgivelser, handler det om at skalere platformen ud, støtte distribueret implementering og i horisonten udvide platformen til at understøtte analyser.
Mens analyser skal være meget nyttige i tilfælde af dataserier, er de fleste databaser i tidsserier ikke bygget til dyb eller kompleks analyse. Ironisk nok kan det tilskrives størrelsen af rådata, der strømmer ind; de fleste tidsseriedatabaser nedprøver (f.eks. komprimerer eller arkiverer) gamle data for at holde lageromkostningerne i skak. TimescaleDBs nyligt introducerede funktioner inkluderer mulighed for at analysere indgående realtidsdata (ukomprimeret) med komprimerede historiske data. Mere om det om et øjeblik.
Højdepunktet i nye funktioner er understøttelse af distribueret distribution med flere knudepunkter. For at forklare det er vi nødt til at dykke under coveret for at forklare TimescaleDBs unikke arkitektur. Mange operationelle databaser er afhængige af sharding, hvor de distribuerer forskellige dele af den samme tabel på tværs af flere noder. Selvom det ikke er en relationsdatabase, er det, hvordan MongoDB skalerer ud. Men TimescaleDB er afhængig af en lidt anden konstruktion, som den kalder en “klump.”
En klump er som en append-only-database, for med tidsseriedata er langt det meste af aktiviteten med skriver eller indsatser snarere end ændringer. Og skrivene har tendens til at være i fortløbende tidsintervaller, hvilket står i kontrast til den mere tilfældige distribution, der er almindelig med de fleste transaktionsdatabaser. For Timescale er en klump i det væsentlige en skår, der også har flere tidsskillepartitioner. Når det er tid til at tilføje en ny tidspartition i klumpen, tilføjer systemet det bare; der er ikke behov for at genbalancere eller genindlæse systemet, fordi den nye partition vil være sammenhængende. Og alle disse klumper læses som et samlet logisk bord, selvom det er omsluttet af omslagene, men det er kraftigt opdelt og splittet. En gruppe af sammenkædede bidder i TimescaleDB styres som hypertabeller, der får hele samlingen til at ligne en fysisk tabel.
Indtil nu kunne hypertabeller kun køre på en enkelt node. Imidlertid kan hypertables i 2.x-generationen spredes over flere noder med alle deres residente klumper. Resultatet er, at TimescaleDB, som indtil nu kunne rumme terabyte data, nu kan blæse op til et petabyteområde.
Nu hvor Timescale kan skaleres ud, vil det næste logiske trin være at tilføje muligheden for at replikere en hel klynge af tabeller for høj tilgængelighed og give midlerne til at genoprette ældre klumper på tværs af klyngen. Det er baseret på den antagelse, at kun tidssnitspartitioner er aktive med tidsseriedata. Begge funktioner er på køreplanen.
En anden nylig forbedring er også relateret til skala. Mens tidsseriedatabaser er skrive-tunge, er der behov for at køre forespørgsler. Indtil nu har det at finde unikke værdier krævet komplette tabelscanninger af indekset. Andre relationsdatabaser, såsom Oracle, MySQL, IBM Db2 og CockroachDB, har allerede funktioner, der gør det muligt for scanninger at springe irrelevante værdier over i sammensatte indekser (f.eks. Indekser, der sorteres i flere kolonner). Imidlertid har PostgreSQL manglet det, så for nu tilføjer TimescaleDB sin egen skip scan-funktion. Når og hvis PostgreSQL-samfundet udfylder dette hul, ville vi forvente, at Timescale sandsynligvis vil bakke det op.
Den seneste udgave af udgivelser har også strømlinet komprimering, så du skriver til klumper, der allerede er komprimeret. Ligesom andre tidsseriedatabaser anvender Timescale komprimering på ældre værdier – det gøres gennem en søjleformet opfattelse, som den introducerede for et par år siden.
OK, lad os hente analysetråden igen. De annoncerer et nyt projekt for at tilføje en analytisk motor – den styres adskilt fra den eksisterende TimescaleDB operationelle motor af åbenlyse grunde – analytiske forespørgsler forbruger ressourcer forskelligt fra operationelle transaktioner. Men på dette tidspunkt er analyser stadig en ambition; Tidsskala har nået ud til samfundet for reaktion og vejledning. Vi håber, at den nye motor, i modsætning til rivaler som InfluxData, vil være baseret på den samme underliggende teknologibase som den eksisterende.
Big Data
Hvor er IBMs hybrid sky launchpad? Syv måder at gøre realtidsteknologi til virkelighed for din organisation Maskinindlæring på kanten: TinyML bliver stor Hvad er det næste for Cloudera? McDonald's ønsker at 'demokratisere' maskinindlæring for alle brugere på tværs af sine operationer
Relaterede emner:
Data Management Digital Transformation Robotics Internet of Things Innovation Enterprise Software 