Shutterstock
Nylig annonsert $ 40 millioner B-finansieringsrunde, diversifiserer Timescale sin TimescaleDB-plattform med et par mål: å gjøre den mer skalerbar og legge til en ny analysemotor.
Som vi bemerket da vi diskuterte den generelle utgivelsen av Amazon Timestream i fjor høst, er tidsserieplattformer en gammel, men plutselig ny kategori i databaselandskapet. Selv om IoT ofte blir sitert (eller klandret) for utfallet av tidsseriedatabaseaktivitet, er det mange scenarier (f.eks. I kapitalmarkeder, transport og logistikk osv.) Der tid er den definerende parameteren.
Men la oss få denne bekjennelsen av brystene våre akkurat nå: TimescaleDB er et merkenavn som lett forveksles med Amazon Timestream (OK, Timescale kom først ut i markedet). Som et resultat finner vi oss ofte snubler over alt dette nesten identiske merkevarebygget og befant oss i å gå inn i global erstatningsmodus for å sikre at vi setter de riktige navnene i de riktige setningene.
Timescale er et av de kvasi-open source-selskapene som har brukt sin egen lisensieringssmak i måneden for å oppmuntre kundene til å leke med og forbedre koden, men forhindre at AWS i verden lanserer databaseskytjenester på sin community-utgave. 2.0-versjonen utgitt for noen måneder tilbake, liberaliserte lisensieringen litt for å oppmuntre kundene til å tilpasse koden.
I motsetning til bedre kjent InfluxDB, er Timescale veldig mye i SQL-modus, som Amazon Timestream. Men i motsetning til Timestream er TimescaleDB en PostgreSQL-variant. Dermed slutter TimescaleDB seg til det som bokstavelig talt er en mengde i PostgreSQL-samfunnet, men det er unikt i å være en av få, om ikke den eneste, PostgreSQL-varianter som er spesielt designet for tidsseriedata.
Timescale ga ut versjon 2.0 tilbake i februar og er nå på en månedlig tråkkfrekvens med flere punktutgivelser siden den gang. Hvis det er et felles tema for de nåværende utgivelsene, handler det om å skalere plattformen ut, støtte distribuert distribusjon og i horisonten, utvide plattformen til å støtte analyser.
Mens analytics skal være veldig nyttig for bruk av tidsseriedata, er de fleste databaser for tidsserier ikke bygget for dyp eller kompleks analyse. Ironisk nok kan det tilskrives størrelsen på rådata som strømmer inn; de fleste tidsseriedatabaser nedprøver (f.eks. komprimerer eller arkiverer) gamle data for å holde lagringskostnadene i sjakk. TimescaleDBs nylig introduserte funksjoner inkluderer muligheten til å analysere innkommende sanntidsdata (ukomprimert) med komprimerte historiske data. Mer om det om et øyeblikk.
Høydepunktet med nye funksjoner er støtte for distribuert distribusjon med flere noder. For å forklare det, må vi dykke under dekslene for å forklare TimescaleDBs unike arkitektur. Mange operative databaser er avhengige av skjæring, der de distribuerer forskjellige deler av samme tabell over flere noder. Selv om det ikke er en relasjonsdatabase, er det hvordan MongoDB skalerer ut. Men TimescaleDB er avhengig av en litt annen konstruksjon, som den kaller en “klump.”
En bit er som en database som bare kan legges til, for med tidsseriedata er langt det meste av aktiviteten med skriver eller innlegg i stedet for endringer. Og skrivene pleier å være i sammenhengende tidsintervaller, noe som står i kontrast til den mer tilfeldige distribusjonen som er vanlig med de fleste transaksjonsdatabaser. For Timescale er en del egentlig en skjær som også har flere tidsdelingspartisjoner. Når det er på tide å legge til en ny tidspartisjon i klumpen, legger systemet bare til det; det er ikke behov for å balansere eller laste systemet på nytt fordi den nye partisjonen vil være sammenhengende. Og alle disse biter leses som en enhetlig logisk tabell, selv om det under dekslene er tungt partisjonert og skjæret. En gruppe koblede biter i TimescaleDB administreres som hypertabeller som får hele forsamlingen til å se ut som en fysisk tabell.
Inntil nå kunne hypertabeller bare kjøres på en enkelt node. Imidlertid kan hypertables i 2.x-generasjonen spre seg over flere noder med alle deres bosatte biter. Resultatet er at TimescaleDB, som til nå har plass til terabyte data, nå kan blåse opp til et petabyte-område.
Nå som Timescale kan skaleres ut, vil det neste logiske trinnet være å legge til muligheten til å replikere en hel klynge av tabeller for høy tilgjengelighet og gi midler for å balansere eldre biter på tvers av klyngen. Det er basert på antagelsen om at med tidsseriedata er bare de nyeste tidsdelingspartisjonene aktive. Begge funksjonene er på veikartet.
En annen nylig forbedring er også relatert til skala. Mens tidsseriedatabaser er tunge, er det behov for å kjøre spørringer. Inntil nå har det funnet fullstendige tabellskanninger av indeksen å finne unike verdier. Andre relasjonsdatabaser, som Oracle, MySQL, IBM Db2 og CockroachDB, har allerede funksjoner som lar skanninger hoppe over irrelevante verdier i sammensatte indekser (f.eks. Indekser som sorteres på flere kolonner). Imidlertid har PostgreSQL manglet det, så foreløpig legger TimescaleDB til sin egen skip scan-funksjon. Når og hvis PostgreSQL-fellesskapet fyller dette hullet, forventer vi at Timescale sannsynligvis vil støtte det.
Den siste utgaven av utgivelser har også strømlinjeformet komprimering slik at du skriver til biter som allerede er komprimert. Som andre tidsseriedatabaser bruker Timescale komprimering på eldre verdier – det gjøres gjennom en søylevisning som den introduserte for et par år siden.
OK, la oss ta opp analysetråden igjen. De kunngjør et nytt prosjekt for å legge til en analytisk motor – den vil bli administrert separat fra den eksisterende TimescaleDB-operasjonsmotoren av åpenbare grunner – analytiske spørsmål bruker ressurser annerledes enn operasjonelle transaksjoner. Men på dette punktet er analyser fortsatt en ambisjon; Tidsskala har nådd ut til samfunnet for reaksjon og veiledning. Vi håper at, i motsetning til rivaler som InfluxData, at den nye motoren vil være basert på den samme underliggende teknologibasen som den eksisterende.
Big Data
Hvor er IBMs hybrid sky launchpad? Syv måter å gjøre sanntidsteknologi virkelig for organisasjonen din Maskinlæring på kanten: TinyML blir stor Hva er neste for Cloudera? McDonald's ønsker å 'demokratisere' maskinlæring for alle brukere på tvers av virksomheten.
Relaterte emner:
Data Management Digital Transformation Robotics Internet of Things Innovasjon Enterprise Software 