Shutterstock
Dopo un round di finanziamento da 40 milioni di dollari annunciato di recente, Timescale sta diversificando la sua piattaforma TimescaleDB con un paio di obiettivi: renderla più scalabile e aggiungere un nuovo motore di analisi.
Come abbiamo notato quando abbiamo discusso della versione generale di Amazon Timestream lo scorso autunno, le piattaforme di serie temporali sono una categoria vecchia ma improvvisamente nuova nel panorama dei database. Sebbene l'IoT sia spesso citato (o accusato) per il risultato dell'attività del database delle serie temporali, esistono numerosi scenari (ad es. nei mercati dei capitali, nei trasporti e nella logistica, ecc.)Ma togliamoci subito questa confessione: TimescaleDB è un marchio che può essere facilmente confuso con Amazon Timestream (OK, Timescale è uscito per primo sul mercato). Di conseguenza, molto spesso ci troviamo a inciampare in tutto questo marchio quasi identico e ci siamo trovati ad entrare in modalità di sostituzione globale per assicurarci di inserire i nomi giusti nelle frasi giuste.
Timescale è una di quelle aziende quasi open source che ha applicato la propria licenza del mese per incoraggiare i clienti a giocare e migliorare il codice, ma impedisce alle AWS del mondo di lanciare servizi cloud di database sulla sua edizione della community. La versione 2.0 rilasciata alcuni mesi fa ha leggermente liberalizzato la licenza per incoraggiare i clienti a modificare il codice.
A differenza del più noto InfluxDB, Timescale è molto in modalità SQL, come Amazon Timestream. Ma a differenza di Timestream, TimescaleDB è una variante di PostgreSQL. Pertanto, TimescaleDB si unisce a quella che è letteralmente una folla nella comunità di PostgreSQL, ma è unica nell'essere una delle poche, se non l'unica, varianti di PostgreSQL che sono state progettate specificamente per i dati delle serie temporali.
Timescale ha rilasciato la versione 2.0 a febbraio e ora ha cadenza mensile con diversi rilasci di punti da allora. Se c'è un tema comune alle versioni correnti, si tratta di ridimensionare la piattaforma, supportare la distribuzione distribuita e, all'orizzonte, estendere la piattaforma per supportare l'analisi.
Sebbene l'analisi dovrebbe essere molto utile per i casi d'uso di dati di serie temporali, la maggior parte dei database di serie temporali non è creata per analisi approfondite o complesse. Ironia della sorte, ciò è attribuibile alla grandezza dei dati grezzi che si riversano; la maggior parte dei database di serie temporali esegue il downsampling (ad esempio, comprime o archivia) i vecchi dati per tenere sotto controllo i costi di archiviazione. Le funzionalità introdotte di recente da TimescaleDB includono la capacità di analizzare i dati in ingresso in tempo reale (non compressi) con dati storici compressi. Ne parleremo tra poco.
Il clou delle nuove funzionalità è il supporto per la distribuzione distribuita e multi-nodo. Per spiegarlo, dobbiamo tuffarci sotto le coperte per spiegare l'architettura unica di TimescaleDB. Molti database operativi si basano sullo sharding, in cui distribuiscono parti diverse della stessa tabella su più nodi. Sebbene non sia un database relazionale, è il modo in cui MongoDB si espande. Ma TimescaleDB si basa su un costrutto leggermente diverso, che chiama “pezzo”.
Un blocco è come un database di sola aggiunta perché con i dati delle serie temporali, di gran lunga la maggior parte dell'attività è con scritture o inserimenti anziché con modifiche. E le scritture tendono ad essere in intervalli di tempo consecutivi, il che contrasta con la distribuzione più casuale comune con la maggior parte dei database delle transazioni. Per Timescale, un chunk è essenzialmente un frammento che ha anche più partizioni time slice. Quando è il momento di aggiungere una nuova partizione temporale nel blocco, il sistema semplicemente la aggiunge; non è necessario ribilanciare o ricaricare il sistema perché la nuova partizione sarà contigua. E tutti questi blocchi vengono letti come una tabella logica unificata, sebbene sotto le coperte sia pesantemente partizionata e frammentata. Un gruppo di blocchi collegati in TimescaleDB sono gestiti come ipertabelle che fanno sembrare l'intero assemblaggio un'unica tabella fisica.
Fino ad ora, le ipertabelle potevano essere eseguite solo su un singolo nodo. Tuttavia, nella generazione 2.x, le hypertable possono diffondersi su più nodi con tutti i loro blocchi residenti. Il risultato è che TimescaleDB, che fino ad ora poteva contenere terabyte di dati, ora può aumentare fino a un intervallo di petabyte.
Ora che la scala temporale può essere scalata, il prossimo passo logico sarà aggiungere la possibilità di replicare un intero cluster di tabelle per l'alta disponibilità e fornire i mezzi per riequilibrare i blocchi più vecchi nel cluster. Ciò si basa sul presupposto che con i dati delle serie temporali siano attive solo le partizioni degli intervalli di tempo più recenti. Entrambe le funzionalità sono sulla tabella di marcia.
Un altro recente miglioramento riguarda anche la scala. Sebbene i database delle serie temporali siano molto scritti, è necessario eseguire query. Fino ad ora, la ricerca di valori univoci richiedeva scansioni complete della tabella dell'indice. Altri database relazionali, come Oracle, MySQL, IBM Db2 e CockroachDB dispongono già di funzionalità che consentono alle scansioni di ignorare valori irrilevanti negli indici compositi (ad es. indici che ordinano su più colonne). Tuttavia, a PostgreSQL mancava questo, quindi per ora TimescaleDB sta aggiungendo la propria funzione di skip scan. Quando e se la comunità di PostgreSQL colmerà questa lacuna, ci aspetteremmo che Timescale probabilmente lo supporterà.
L'ultimo raccolto di versioni ha anche semplificato la compressione in modo da scrivere su blocchi già compressi. Come altri database di serie temporali, Timescale applica la compressione ai valori precedenti, tramite una visualizzazione a colonne introdotta un paio di anni fa.
OK, riprendiamo il thread di analisi. Stanno annunciando un nuovo progetto per aggiungere un motore analitico – sarà gestito separatamente dal motore operativo TimescaleDB esistente per ovvie ragioni – le query analitiche consumano risorse in modo diverso dalle transazioni operative. Ma a questo punto, l'analisi è ancora un'aspirazione; Timescale ha contattato la comunità per una reazione e una guida. Ci auguriamo che, a differenza di rivali come InfluxData, che il nuovo motore sia basato sulla stessa base tecnologica di base di quello esistente.
Big Data
Dov'è l'ibrido di IBM piattaforma di lancio cloud? Sette modi per rendere reale la tecnologia in tempo reale per la tua organizzazione Machine learning all'avanguardia: TinyML sta diventando grande Quali sono le prospettive di Cloudera? McDonald's vuole “democratizzare” l'apprendimento automatico per tutti gli utenti nelle sue operazioni
Argomenti correlati:
Gestione dei dati Trasformazione digitale Robotica Internet delle cose Innovazione Software aziendale 