Shutterstock
Nyligen aviserad finansieringsrunda på $ 40 miljoner B, diversifierar Timescale sin TimescaleDB-plattform med ett par mål: att göra den mer skalbar och lägga till en ny analysmotor.
Som vi noterade när vi diskuterade den allmänna utgåvan av Amazon Timestream förra hösten är tidsserieplattformar en gammal men plötsligt ny kategori i databaslandskapet. Även om IoT ofta citeras (eller klandras) för uppkomsten av tidsseriedatabasaktivitet, finns det många scenarier (t.ex. på kapitalmarknader, transport och logistik, etc.) där tid är den definierande parametern.
Men låt oss få bort denna bekännelse just nu: TimescaleDB är ett varumärke som lätt kan förväxlas med Amazon Timestream (OK, Timescale kom ut på marknaden först). Som ett resultat befinner vi oss ofta i att snubbla över allt detta nästan identiska varumärke och befann oss i att gå in i globalt utbytesläge för att se till att vi sätter rätt namn i rätt meningar.
Timescale är ett av de kvasi-open source-företag som har tillämpat sin egen licenssmak i månaden för att uppmuntra kunder att leka med och förbättra kod men förhindra AWS i världen från att lansera molntjänster för databaser på sin community-utgåva. 2.0-versionen släpptes för några månader tillbaka liberaliserade licensieringen något för att uppmuntra kunder att justera koden.
Till skillnad från bättre kända InfluxDB är Timescale väldigt mycket i SQL-läge, som Amazon Timestream. Men till skillnad från Timestream är TimescaleDB en PostgreSQL-variant. Således ansluter sig TimescaleDB till det som bokstavligen är en publik i PostgreSQL-gemenskapen, men det är unikt eftersom det är en av få, om inte den enda, PostgreSQL-varianter som har utformats specifikt för tidsseriedata.
Timescale släppte version 2.0 tillbaka i februari och är nu på en månatlig kadens med flera punktutgivningar sedan dess. Om det finns ett gemensamt tema för de aktuella versionerna handlar det om att skala ut plattformen, stödja distribuerad distribution och i horisonten, utöka plattformen för att stödja analyser.
Även om analys bör vara mycket användbar för tidsserier för dataanvändningsfall, är de flesta tidsseriedatabaser inte byggda för djup eller komplex analys. Ironiskt nog beror det på storleken på rådata som häller in; de flesta tidsseriedatabaser nedprover (t.ex. komprimera eller arkivera) gamla data för att hålla lagringskostnaderna i kontroll. TimescaleDB: s nyligen introducerade funktioner inkluderar möjligheten att analysera inkommande realtidsdata (okomprimerad) med komprimerad historisk data. Mer om det på ett ögonblick.
Höjdpunkten i nya funktioner är stöd för distribuerad distribution med flera noder. För att förklara det måste vi dyka under omslaget för att förklara TimescaleDBs unika arkitektur. Många operativa databaser är beroende av skärning, där de distribuerar olika delar av samma tabell över flera noder. Även om det inte är en relationsdatabas är det hur MongoDB skalar ut. Men TimescaleDB förlitar sig på en något annorlunda konstruktion, som den kallar en “bit”.
En bit är som en endast tilläggsdatabas, för med tidsseriedata är den överlägset mesta aktiviteten med skrivningar eller inlägg snarare än förändringar. Och skrivningarna brukar vara i på varandra följande tidsintervall, vilket står i kontrast till den mer slumpmässiga distributionen som är vanlig med de flesta transaktionsdatabaser. För Timescale är en bit i huvudsak en skärva som också har flera tidsskillnadspartitioner. När det är dags att lägga till en ny tidspartition i biten lägger systemet bara till det; det finns inget behov av att balansera om eller ladda om systemet eftersom den nya partitionen kommer att vara angränsande. Och alla dessa bitar läses som en enhetlig logisk tabell, även om det under täcket är kraftigt uppdelat och skärdat. En grupp länkade bitar i TimescaleDB hanteras som hypertabeller som gör att hela monteringen ser ut som en fysisk tabell.
Hittills kan hypertabeller bara köras på en enda nod. Men i 2.x-generationen kan hypertabeller spridas över flera noder med alla sina bosatta bitar. Resultatet är att TimescaleDB, som hittills kan rymma terabyte data, nu kan blåsa upp till ett petabyte-intervall.
Nu när Timescale kan skala ut kommer nästa logiska steg att lägga till möjligheten att replikera ett helt kluster av tabeller för hög tillgänglighet och tillhandahålla medel för att balansera äldre bitar över klustret. Det bygger på antagandet att med tidsseriedata är det bara de senaste tidsskivpartitionerna som är aktiva. Båda funktionerna finns på färdplanen.
En annan förbättring nyligen har också samband med skala. Medan tidsseriedatabaser är svåra är det nödvändigt att köra frågor. Hittills har det krävt fullständiga tabellskanningar för att hitta unika värden. Andra relationsdatabaser, som Oracle, MySQL, IBM Db2 och CockroachDB, har redan funktioner som gör att skanningar kan hoppa över irrelevanta värden i sammansatta index (t.ex. index som sorteras i flera kolumner). Men PostgreSQL har saknat det, så för tillfället lägger TimescaleDB till sin egen hoppa över skanningsfunktion. När och om PostgreSQL-gruppen fyller detta gap, förväntar vi oss att Timescale förmodligen kommer att backa upp det.
Den senaste versionen har också effektiviserat komprimeringen så att du skriver till bitar som redan är komprimerade. Liksom andra tidsseriedatabaser tillämpar Timescale komprimering på äldre värden – det görs genom en kolumnvy som den introducerade för ett par år sedan.
OK, låt oss hämta analystråden igen. De tillkännager ett nytt projekt för att lägga till en analytisk motor – den kommer att hanteras separat från den befintliga TimescaleDB-operativa motorn av uppenbara skäl – analytiska frågor förbrukar resurser annorlunda än operativa transaktioner. Men vid denna tidpunkt är analys fortfarande en ambition; Tidsskala har nått ut till samhället för reaktion och vägledning. Vi hoppas att, till skillnad från konkurrenter som InfluxData, att den nya motorn kommer att baseras på samma underliggande teknikbas som den befintliga.
Big Data
Var är IBMs hybrid moln launchpad? Sju sätt att göra realtidsteknik verklig för din organisation Maskininlärning vid kanten: TinyML blir stort Vad är nästa för Cloudera? McDonald's vill 'demokratisera' maskininlärning för alla användare över hela verksamheten
Relaterade ämnen:
Datahantering Digital Transformation Robotics Internet of Things Innovation Enterprise Software 