Scalable Model-Based Management of Correlated Dimensional Time Series in ModelarDB+

TL;DR

This paper introduces a scalable, model-based approach for managing correlated high-frequency time series data, enabling efficient compression and query processing in infrastructure monitoring systems.

Contribution

It presents the first Multi-Model Group Compression (MMGC) method, GOLEMM, extending model types for better compression and providing algorithms for efficient aggregate queries in a new time series management system.

Findings

Up to 13.7x faster ingestion compared to traditional formats.

113x better compression due to adaptive modeling.

630x faster aggregate query performance.

Abstract

To monitor critical infrastructure, high quality sensors sampled at a high frequency are increasingly used. However, as they produce huge amounts of data, only simple aggregates are stored. This removes outliers and fluctuations that could indicate problems. As a remedy, we present a model-based approach for managing time series with dimensions that exploits correlation in and among time series. Specifically, we propose compressing groups of correlated time series using an extensible set of model types within a user-defined error bound (possibly zero). We name this new category of model-based compression methods for time series Multi-Model Group Compression (MMGC). We present the first MMGC method GOLEMM and extend model types to compress time series groups. We propose primitives for users to effectively define groups for differently sized data sets, and based on these, an automated grouping method using only the time series dimensions. We propose algorithms for executing simple and multi-dimensional aggregate queries on models. Last, we implement our methods in the Time Series Management System (TSMS) ModelarDB (ModelarDB+). Our evaluation shows that compared to widely used formats, ModelarDB+ provides up to 13.7 times faster ingestion due to high compression, 113 times better compression due to the adaptivity of GOLEMM, 630 times faster aggregates by using models, and close to linear scalability. It is also extensible and supports online query processing.

Tables

Table 1. TABLE I : Optimizations Implemented in MDB +

Component Set	Change
Data Ingestion	Read files in smaller chunks to reduce memory usage.
	Write segments directly to storage when bulk-loading.
	Replace PMC-MR with PMC-Mean to lower average error.
	Pre-allocate memory for Gorilla based on the length bound.
Query Processing	Use static and dynamic code generation for faster projections.
	Use the number of Spark partitions as a caching heuristic.
	Parallelize queries over Gids in Spark instead of Cassandra.
Segment Storage	Only decompress segments when used for query processing.

Full text

I Introduction

To maintain a high output from energy producing entities, such as wind turbines, they are monitored by regularly sampling high quality sensors with wired power and connectivity. Thus, invalid, missing and out-of-order readings are rare, and all but missing values can be corrected using established methods. The data is used by park owners and turbine manufactures for management and warranty purposes. From discussions with both, we learned that storing the raw sensor data is either infeasible or prohibitively expensive. Instead, only simple aggregates are stored, e.g., 1–10 minute averages, which remove informative outliers and fluctuations. As a running example, consider a company with 16 wind parks spread over 3 countries. A park contains 12 turbines on average and each turbine is monitored by 98 sensors with a 100 ms sampling interval ($SI$). While a data point is only 96 bits (timestamp and value), 44 TiB are stored per month. Metadata, e.g., location, is also stored for each time series to support analysis along multiple dimensions. Using a short $SI$ only during critical events could reduce the storage required. But what constitutes a critical event is often not known in advance so a short $SI$ is always needed.

As a remedy, sensor data can be efficiently stored within a known error bound (possibly zero) using models [5, 6]. Many state-of-the-art model-based compression methods use Multi-Model Compression (MMC) or Model-based Group Compression (MGC). MMC methods compress each time series using multiple model types to adapt as each time series’ structure changes over time [7, 8, 9, 1, 10]. MGC methods compress correlated time series as one stream of models to not store similar values from multiple time series [11, 12, 13]. However, no MMC methods exploit that time series are correlated, and each MGC method only uses one model type. We propose combining MMC and MGC to reduce the models (and bytes) required to store a group of time series as shown in Figure 1. We name this new category of model-based compression methods Multi-Model Group Compression (MMGC). To design an MMGC method, multiple questions must be answered. (i) How can a group of time series be compressed more using multiple model types? (ii) How should time series be grouped when using multiple model types? (iii) How can existing model types be used? (iv) How can queries be executed on models? To answer these we propose: The first MMGC method GOLEMM, an acronym for Group Online Lossy and lossless Extensible Multi-Model compression. Primitives so users effectively can group time series either manually or automatically. Algorithms for executing aggregates on models. To show our methods are practical we add them to the TSMS ModelarDB (MDB) [1]. ModelarDB+ (MDB+) is the new version. MDB+ is distributed, scales, supports online analytics, and is extensible. Compared to popular formats MDB+ has up to 13.7x faster ingestion, 113x better compression, and 630x faster aggregation. In summary, we make these contributions in the area of big data systems:

(i) The Multi-Model Group Compression (MMGC) category of model-based compression methods for time series.

(ii) GOLEMM, a Multi-Model Group Compression method and model types extended to compress time series groups.

(iii) Primitives for users to effectively group time series, and a method that automatically groups them using their dimensions.

(iv) Algorithms for executing simple and multi-dimensional aggregate queries on models representing time series groups.

(v) MDB+’s source-code people.cs.aau.dk/~skj/MDB+.tar.gz.

(vi) An evaluation of MDB+ on real-life and derived data.

The structure of the paper is as follows. Definitions are provided in Section II. Section III describes how MDB+ supports GOLEMM. Section IV documents our grouping primitives and our automated grouping method, while Section V describes our extended model types. In Section VI our query processing algorithms are described. An evaluation of MDB+ is given in Section VII. Related work is presented in Section VIII. Last, Section IX provides our conclusion and future work.

II Preliminaries

As we build upon [1], updated definitions from it are used with Model Type, Dimension, and Time Series Group added.

Time Series: A time series TS is a sequence of data points, in the form of timestamp and value pairs, ordered by time in increasing order $TS=\langle(t_{1},v_{1}),(t_{2},v_{2}),\ldots\rangle$. For each pair $(t_{i},v_{i})$, $1\leq i$, the timestamp $t_{i}$ represents when the value $v_{i}\in\mathbb{R}$ was recorded. A time series $TS=\langle(t_{1},v_{1}),\ldots,(t_{n},v_{n})\rangle$ with a fixed number of $n$ data points is a bounded time series.

Regular Time Series: A time series $TS=\langle(t_{1},v_{1}),(t_{2},v_{2}),\ldots\rangle$ is considered regular if the time elapsed between each data point is always the same, i.e., $t_{i+1}-t_{i}=t_{i+2}-t_{i+1}$ for $1\leq i$ and irregular otherwise.

Sampling Interval: The sampling interval SI of a regular time series $TS=\langle(t_{1},v_{1}),(t_{2},v_{2}),\ldots\rangle$ is the time elapsed between each pair of consecutive data points in the time series: $SI=t_{i+1}-t_{i}$ for $1\leq i$.

Consider, e.g., a time series with wind speed in m/s $TS=\langle(100,9.43),(200,9.09),(300,8.96),(400,8.62),(500,8.50),$ $\ldots\rangle$. The timestamps are the ms since recording began. The interval $100\leq t_{i}\leq 500$ of $TS$ is an example of a bounded time series. Both time series are regular with a $SI$ of $100$ ms.

Model: A model of a time series $TS=\langle(t_{1},v_{1}),\ldots\rangle$ is a function $m$. For each $t_{i}$, $1\leq i$, $m$ is a real-valued mapping from $t_{i}$ to an estimate of the value $v_{i}$ for the corresponding data point in $TS$.

Model Type: A model type is pair of functions $M_{T}=(m_{t},e_{t})$. $m_{t}(TS,\epsilon)$ is a partial function, which when defined for a bounded time series $TS$ and a non-negative real number $\epsilon$ returns a model $m$ of $TS$ such that $e_{t}(TS,m)\leq\epsilon$. $e_{t}$ is a mapping from $TS$ and $m$ to a non-negative real number representing the error of the values estimated by $m$. We call $\epsilon$ the error bound.

Intuitively, linear regression is a model type while a linear function is a model. A model type defines how to represent a time series as a model $m$, how the error of $m$ is calculated ($e_{t}$), and how to interpret the error bound $\epsilon$. We say a model is fitted to a time series when its parameters are computed. The result of fitting a linear function to $TS$ within $\epsilon=0.25$ according to the uniform norm could, e.g., be $m=-0.003t_{i}+9.8$, $100\leq t_{i}\leq 500$ as its error is $|9.09-(-0.003\times 200+9.8)|=0.11$.

Gap: A gap between a regular bounded time series $TS_{1}=\langle(t_{1},v_{1}),\ldots,(t_{s},v_{s})\rangle$ and a regular time series $TS_{2}=\langle(t_{e},v_{e}),(t_{e+1},v_{e+1}),\ldots\rangle$ with the same sampling interval $SI$ and recorded from the same source, is a pair of timestamps $G=(t_{s},t_{e})$ with $t_{e}=t_{s}+m\times SI$, $m\in\mathbb{N}_{\geq 2}$, and where no data points exist between $t_{s}$ and $t_{e}$.

Regular Time Series with Gaps: A regular time series with gaps is a regular time series, $TS=\langle(t_{1},v_{1}),(t_{2},v_{2}),\ldots\rangle$ where $v_{i}\in\mathbb{R}\cup\{\bot\}$ for $1\leq i$. All sub-sequences in $TS$ of the form $\langle(t_{s},v_{s}),(t_{s+1},\bot),\ldots,(t_{e-1},\bot),(t_{e},v_{e})\rangle$ where $v_{s},v_{e}\in\mathbb{R}$, are denoted as gaps $G=(t_{s},t_{e})$.

A gap is shown in Figure 2. Time series from one source separated by gaps we refer to as a time series with gaps. For example, $TS_{g}=\langle(100,9.43),(200,9.09),(300,8.96),(400,$ $8.62),(500,8.50),(1100,7.08),\ldots\rangle$ has a gap $G=(500,$ $1100)$, is irregular, and has an undefined $SI$. However, as a regular time series with gaps $TS_{rg}=\langle(100,9.43),(200,9.09),$ $(300,8.96),(400,8.62),(500,8.50),(600,\bot),(700,\bot),(800,$ $\bot),(900,\bot),(1000,\bot),(1100,7.08),\ldots\rangle$ its $SI=100$ ms.

Dimension: A dimension with members $M$ is a 3-tuple $D=(\mathit{member}:\mathbb{TS}{}\to M,\mathit{level}:M\to\{0,1,\ldots,n\},\mathit{parent}:M\to M)$ where (i) $M$ is hierarchically organized descriptions of the time series in the set of time series $\mathbb{TS}{}$ with the special value $\top\in M$ as the top element of the hierarchy; (ii) $\mathit{level}$ is surjective; (iii) For $TS\in\mathbb{TS}{}$, $\mathit{level}(\mathit{member}(TS))=n$ and $\nexists m\in M$ where $\mathit{level}(m)>n$; (iv) For $TS\in\mathbb{TS}{}$, $m\in M$ and $k\neq\top$, if $\mathit{level(m)}=k$ then $\mathit{level}(\mathit{parent}(\mathit{member}(TS)))=k-1$; (v) $\mathit{parent}(\top)=\top$; (vi) $\mathit{level}(\top)=0$.

A time series belongs to a dimension’s lowest level. Each member (except $\top$) at a level $k$ has a parent at level $k-1$. Users can analyze data at different levels by grouping on a level. To better describe the relation of the time series to real-world entities we use named levels. For example, the location dimension for the time series in our running example is Turbine $\rightarrow$ Park $\rightarrow$ Region $\rightarrow$ Country $\rightarrow\top$. For a time series $TS$, $\mathit{member}(TS)$ returns a member for the Turbine level, while $\mathit{parent}(\mathit{member}(TS))$ returns a member for the Park level. If a $TS$ is from a wind turbine with id $9834$ located in Aalborg, $\mathit{member}(TS)=9834$, while $\mathit{parent}(9834)=\mathit{Aalborg}$ until $\mathit{parent}$ returns $\top$ indicating the top of the hierarchy.

Time Series Group: A time series group is a set of regular time series, possibly with gaps, $TSG=\{TS_{1},\ldots,TS_{n}\}$, where for $TS_{i},TS_{j}\in TSG$ it holds that they have the same sampling interval $SI$ and that $t_{1i}\bmod SI=t_{1j}\bmod SI$ where $t_{1i}$ and $t_{1j}$ are the first timestamp of $TS_{i}$ and $TS_{j}$, respectively.

For example, $TSG=\{TS,TS_{rg}\}$ is a time series group that contains the time series $TS$ and $TS_{rg}$, both with $SI=100$ ms. The irregular time series $TS_{g}$ cannot be in the group as its $SI$ is undefined. Time series can be correlated even if they have very different values, as scaling can be applied.

So models can represent a time series group within $\epsilon$, the group can be split into dynamically sized sub-sequences. These segments use models to represent the values of the time series in the group, and each segment can use a different model type.

Segment: A segment is a 5-tuple $S=(t_{s},t_{e},SI,G_{ts}:TSG\to 2^{\{t_{s},t_{s}+SI,\ldots,t_{e}\}},m)$ representing the data points for a bounded time interval of a time series group $TSG$. The 5-tuple consists of start time $t_{s}$, end time $t_{e}$, sampling interval $SI$, a function $G_{ts}$ which for the $TS\in TSG$ gives the set of timestamps for which $v=\bot$ in $TS$, and where the values of all other timestamps are defined by the model $m$ multiplied by a scaling constant $C_{TS}\in\mathbb{R}$.

To exemplify segments we use three time series from collocated turbines: $TS_{1}=\langle(100,9.43),(200,9.09),(300,$ $8.96),(400,8.62),(500,8.50)\rangle$, $TS_{2}=\langle(100,8.78),(200,$ $8.55),(300,8.32),(400,8.09),(500,8.96)\rangle$, and $TS_{3}=\langle(100,$ $9.49),(200,9.20),(300,8.92),(400,8.73),(500,8.65)\rangle$. Representing these with the linear function $m=-0.003t_{i}+9.40$ creates an approximation with the error $|8.96-(-0.003\times 500+9.40)|=1.06$ when using the uniform norm. If the error bound, e.g., is $1$, the segment $S=(100,400,100,G_{ts}=\emptyset,m=-0.003t_{i}+9.40)$, $1\leq i\leq 4$, is created.

III Supporting GOLEMM in MDB+

III-A Architecture of MDB+

MDB [1] interfaces a library (MDB Core) with the stock versions of Apache Spark for query processing and Apache Cassandra for storage in a master/worker architecture [1]. MDB+ adds a Partitioner to the master and updates all of MDB’s components. The Partitioner exposes primitives for effectively specifying time series groups and an automatic grouping method as shown in Figure 3(a) and detailed in Section IV. When ingesting, MDB+ compresses time series groups using GOLEMM which selects an appropriate model type for each segment as described in Section III-B. Three model types, extended to compress groups as described in Section V, are part of MDB+ Core: the constant PMC-Mean model (PMC-Mean) [14], the linear Swing model (Swing) [15], and Gorilla’s lossless floating-point compression algorithm (Gorilla) [16]. A key benefit of PMC-Mean and Swing is that they only use 32 bits and 64 bits per segment, respectively, regardless of the segment’s length. But PMC-Mean requires that the values can be approximated by a constant, while Swing requires that the values can be approximated by a linear function. This limitation is seen in Figure 1 under MGC where PMC-Mean creates many segments to represent approximately linear time series. As Gorilla uses delta-of-delta encoding, the values need not follow a specific pattern, but Gorilla uses 1-32 bits per value. So PMC-Mean and Swing are more efficient than Gorilla when time series follow constant or linear patterns, but can be inefficient if not. Users can also add more model types to MDB+ without recompiling it. So by using multiple models types, MDB+ can adapt as time series change at run-time. A fallback model type that stores raw values is also provided. It is only used for segments that cannot be represented by any other model type within the user-defined bounds.

A worker consists of three sets of components as shown in Figure 3(b). Each component is annotated with the software providing that functionality and components modified for MDB+ are gray. Data Ingestion constructs models of time series groups within user-defined bounds; Query Processing caches segments and processes queries; Segment Storage is a uniform interface with predicate push-down for the segment group store. While adding our new MDB+ methods to MDB, we also optimized MDB’s code as listed in Table I. Thus, MDB+ builds upon MDB by adding our methods and optimizations.

III-B Ingestion and Gaps in GOLEMM

GOLEMM consists of online ingestion, management of gaps, and dynamic splitting and merging of groups. For ingestion, GOLEMM uses a window-based approach to support bounded and unbounded times series. Data points for a group are added to a window and a model (from a user-configurable list of model types) is fitted to all data points in the window at each SI. When a data point is received that the models cannot be fitted to within the error bound $\epsilon$, the model with the best compression is emitted. An example is shown in Figure 4. At $t_{1}$ a data point from each time series in the group is appended to a buffer. A model of the first model type (PMC-Mean) is fitted to them. This is repeated for each $SI$ while possible within $\epsilon$. The model types in MDB+ Core incrementally update models with new data points. At $t_{6}$, PMC-Mean cannot represent all buffered data points within $\epsilon$. Therefore, GOLEMM uses the next model type (Swing). If this model type can fit a model to all buffered data points ingestion continues, otherwise, the next model type is used. Lossless model types, e.g., Gorilla, are limited by a user-configurable length instead of $\epsilon$. At $t_{16}$ a data point is received that the last model type (Gorilla) cannot fit a model to, so GOLEMM emits a segment with the model providing the best compression (a model of type Swing here). The data points the model represents are removed from the buffer and ingestion restarted using the first model type (PMC-Mean). GOLEMM creates disconnected segments (no duplicate data points) for better compression compared to connected segments [7]. If the model types in the list cannot represent any of the buffered data points, the fallback model type is used, see Section III-A.

If a gap occurs GOLEMM creates a new segment as shown in Figure 5. A model is fitted to data points from all three time series at $t_{1}$. At $t_{s}+SI$ a gap occurs in $TS_{2}$ and a new model is fitted to the data points from only two time series. As this model represents a subset of the group, the ids of the time series not represented are stored in the segment, see $S_{2}$. When data points are received from $TS_{2}$ again, the process is repeated, see $t_{e}$ and $S_{3}$. Thus, a segment represents data points for a static number of time series. This simplifies implementing user-defined model types as MDB+ manages gaps.

III-C Storage Schema

The general schema used by MDB+ to support GOLEMM is shown in Figure 6. Time Series stores SI, a Scaling constant ($C_{TS}$ in the definition of Segment), a group id gid, and user-defined denormalized dimensions for each time series, with each identified by a Tid. Only the SI must be set by the user. Gid is the group a time series has been assigned to by MDB+ using the provided primitives. Scaling defaults to $1.0$ and is applied to values during ingestion and query processing. Model maps a Mid to the Java Classpath of that model type. Segment stores data points as dynamically sized segments.

Segment’s primary key includes Gaps to prevent duplicate keys due to the dynamic splitting described in Section IV-D. While user-defined dimensions are stored in Time Series, no explicit time dimension is needed as aggregates in the time dimension can be computed efficiently using only StartTime and EndTime as described in Section VI-C. By exploiting that the regular time series with gaps in each group are aligned, their timestamps can be efficiently stored as StartTime, EndTime, SI in Time Series, and Gaps. Segment is modified for Cassandra. To improve predicate push-down, its primary key is changed to Gid, EndTime, Gaps [1]. Gaps are 64-bit integers with bits set to $1$ if that time series in the group has a gap. Also, the column StartTime is stored as the segment’s size to save space, but can recomputed as StartTime = EndTime - (Size $\times$ SI) [1].

IV Grouping and Partitioning

IV-A Motivation

To provide the benefit of model-based storage and query processing while ensuring low latency, models must be fitted online [1]. Also, in a distributed system, time series in a group should be ingested by one node to minimize latency and bandwidth use. Thus, the time series must be grouped and partitioned before ingestion begins based on, e.g., metadata, historical data, or domain knowledge. As the best set of groups depends on the model types used, MDB+ has primitives so users effectively can specify which time series to group. Users can thus use their preferred grouping method with MDB+. Locating correlation through data mining [17, 18] is thus an orthogonal problem. MDB+ also has automatic grouping using the time series dimensions. Thus, this can be used when historical data or enough resources to analyze it are not available.

IV-B Primitives and Automatic Grouping

MDB+’s primitives allow groups to be specified as sets of time series, members that must be equal, levels for which members must be equal, or the distance between the dimensions (see below). They can be combined using AND and OR.

To group specific time series, their source (file or socket) must be provided, e.g., 4aTemp.gz 4bTemp.gz. A scaling constant can be added per time series. This provides precise control but is time-consuming. The other primitives allow time series to be grouped based on their dimensions, e.g., temperature sensors in proximity likely produce similar values. The similarity of dimensions for two groups can be computed as their Lowest Common Ancestor (LCA) level. This is the lowest level in a dimension where all time series in the groups share members starting from $\top$. An example is shown in Figure 7.

A group based on members is specified as a triple with a dimension, a level, and a member or a pair with a dimension and an LCA level. The triple Measure 1 Temperature, e.g., groups time series with the member Temperature at level one of the Measure dimension. The pair Location 2 groups time series if their LCA level is equal to or higher than two for the Location dimension. Zero specifies that all levels must be equal, and a negative number $n$ that all but the lowest $|n|$ levels must equal. A scaling constant can be defined for time series with a specific member as a 4-tuple of dimension, level, member, and constant. These primitives are intended for data sets with few dimensions but many series.

For data sets with many time series and dimensions, users can specify groups by the distance $[0.0;1.0]$ between dimensions. Intuitively, time series with high overlap between their members are correlated. The time series in Figure 7 are, e.g., more likely correlated if they share members at the Turbine level than the Country level. For the distance $0.0$ all members must match for time series to be grouped, and for $1.0$ all time series are grouped. Values in-between specify different degrees of overlap.

To automatically group time series, users can specify correlation as auto, making MDB+ group time series within the lowest non-zero distance possible in the data set. This distance is given by $(1.0/\mathit{\max(Levels)})/\mathit{|\mathbb{D}|}$ where $\mathit{Levels}$ is the set of levels in each dimension and $\mathbb{D}$ is the dimensions.

IV-C Static Grouping and Partitioning

MDB+’s Partitioner is shown in Figure 8. Based on the user’s configuration (time series, primitives), the Partitioner groups and partitions the time series across the cluster. For each time series, a reader is created based on the time series source. All references to levels in the dimensions are rewritten to indexes for MDB+’s denormalized schema shown in Section III-C, and auto is rewritten to the shortest non-zero distance.

Groups are constructed from the rewritten primitives. First, MDB+ tries to determine if the primitives create disjoint groups, and if it can, adds each time series directly to its group, otherwise, Algorithm 1 is used. In Line 1 a group is created per time series. Then, in Line 2–12, for each user-defined correlation $\mathit{clause}$, groups are merged until a fixed point is reached in the number of groups. In Line 9 $\mathit{correlated}$ evaluates the $\mathit{clause}$ and ensures that all time series in the groups are correlated before they are merged. As the clauses are applied in their defined order, users control their priority. In essence, Algorithm 1 computes cliques (as correlations are non-transitive) in a graph with time series as vertices and $\mathit{correlated}$ defining the edges. However, as edges are dynamically defined as groups of correlated series are found, all possible edges need not be materialized. While its complexity is $O(K\times N^{3})$ for $K$ clauses and $N$ time series, grouping is done once before ingestion and the actual run-time is very low, see Section VII.

To evaluate the primitives, $\mathit{correlated}$ uses different functions. We only describe the one grouping by distance, as the remaining follow directly from the description of the primitives. First, the distance between the dimensions of the two time series groups is calculated as $dist=(\sum_{d\in\mathbb{D}}\mathit{weight_{d}}\times((\mathit{levels_{d}}-\mathit{lca_{d}})/\mathit{levels_{d}}))/|\mathbb{D}|$ where $\mathit{levels_{d}}$ is the number of levels in $d$, and $\mathit{lca_{d}}$ is the two groups’ LCA level for $d$. Users can change the impact of a dimension by a $\mathit{weight}$ (default is $1$). As it is more intuitive to increase the weight for important dimensions than to decrease it, $weight_{d}$ is the reciprocal of the user-provided weight. For the dimension in Figure 7, the distance between the time series with $Tid=2$ and $Tid=3$ is, e.g., $1\times((4-3)/4)=0.25$. The distance is then capped by $\min(\mathit{dist},1.0)$, and the groups merged if the distance is at most the threshold set by the user or auto.

Last, a set of time series groups $\mathbb{TSG}$ is created so each worker receives approximately the same number of data points per second. The method used is based on [19], and tries to minimize $\max_{SG_{1}\in\mathbb{TSG}}(data\_points\_per\_minute(SG_{1}))-\min_{SG_{2}\in\mathbb{TSG}}(data\_points\_per\_minute(SG_{2}))$.

IV-D Dynamically Splitting Groups

As events can change the values of a time series, e.g., a turbine can be damaged, GOLEMM splits a group if its time series become temporarily uncorrelated. This is shown in Figure 9. GOLEMM discards emitted data points, but they are included in the example to show how the time series change over time. At $t_{m}$ the group is ingested using the Segment Generator $SG_{0}$. At $t_{n}$ its time series are no longer correlated leading to poor compression. The group is then split into two and ingestion continues with $SG_{1}$ and $SG_{2}$. $SG_{0}$ synchronizes ingestion to simplify merging and merges the split groups if they become correlated again. Then at $t_{i}$ the group ingested by $SG_{1}$ is split causing each time series to be ingested separately.

To reduce the number of non-beneficial splits and the overhead of determining when to split, GOLEMM uses two heuristics: poor compression ratio and the error between buffered data points. If the compression ratio of a new segment is below a user-configurable fraction of the average (default is $1/10$) and data points are buffered, Algorithm 2 is run. A new segment indicates that the structure of the time series has changed as the next value would exceed the error or length bound. Algorithm 2 groups time series if their buffered data points are within twice the user-defined error bound ($2\epsilon$) using the error function of the last emitted model in Line 6–10. Thus, groups of size one to $\mathit{|TSG|}$ can be created. In Figure 9 two groups are created both at $t_{n}$ ($SG_{1}$ and $SG_{2}$) and at $t_{i}$ ($SG_{1}$ and $SG_{3}$). Time series currently in a gap are grouped.

At $t_{j}$ in Figure 9 two of the time series become correlated again and are merged into one group. Then, at $t_{k}$ all the time series are correlated again so $SG_{0}$ takes over ingestion. Like for splitting, GOLEMM merges groups by grouping time series if their buffered data points are within $2\epsilon$. However, when merging, only one time series from each group is compared as the groups consist of correlated time series (if not a split would have occurred). To simplify merging, it is only attempted at the end of a $SI$ when all groups have received data points for the period. To reduce the overhead of merging, a split group is only marked for merging after a number of segments are emitted. The required number of segments starts at one and is doubled after each merge attempt. The intuition is that a failed merge attempt further indicates that the splits are preferable.

V Model Extensions

MMGC needs multiple model types that can fit models to time series groups. However, most existing model types fit models to only one time series [5, 6]. A segment can store a model per time series, but it only reduces the amount of metadata. Instead, MDB+ Core uses model types extended to fit models to a time series group based on two general ideas.

For model types that fit models to values by ensuring they are within an upper and lower bound according to the uniform norm, e.g., PMC-Mean and Swing, we only need to ensure that the minimum and maximum value for each timestamp are within the error bound. PMC-Mean represents a set of values $V\subset\mathbb{R}$ as $\operatorname{avg}(V)$ within $\epsilon$ of $\min(V)$ and $\max(V)$. Thus, PMC-Mean needs no changes as it only tracks $\min(V)$, $\max(V)$, and $\operatorname{avg}(V)$. See PMC-Mean in Figure 10. Swing produces a linear function that intersects with the first value and can represent subsequent values within $\epsilon$. For groups, the first value can be computed using PMC-Mean. The following values are added one at a time. See Swing in Figure 10.

For model types using lossless compression, e.g., Gorilla, values from a time series group should be stored in time ordered blocks. This allows exploitation of both temporal correlation and correlation across time series. As the time series in a group are correlated, $n-1$ values in a block have a small delta-of-delta compared to the previous value, which Gorilla encodes using only a few bits per value. See Gorilla in Figure 10.

As a glimpse of the benefit of our extensions, we compress seven real-life time series together. These time series contain measurements of energy frequency from a small park of wind turbines. By grouping them, MDB+ uses 67.2% less storage ($\epsilon=0\%$) compared to compressing them separately.

VI Query Processing

VI-A Query Interface

As a model can reconstruct its data points within $\epsilon$, MDB+ supports arbitrary SQL queries on data points using a Data Point View with the schema (Tid int, TS timestamp, Value float, <Dimensions>). <Dimensions> are the denormalized user-defined dimensions. They are cached in-memory and added during query processing. Some models (e.g., PMC-Mean and Swing) can compute many aggregates in constant time [1]. Thus, aggregates can be computed in linear time in the number of models instead of the number of data points. As a model usually represents many data points, this greatly reduces query time as shown in Section VII. Aggregates on models are provided as UDAFs on a Segment View with the schema (Tid int, StartTime timestamp, EndTime timestamp, SI int, Mid int, Parameters blob, Gaps blob, <Dimensions>). UDAFs for simple aggregates are suffixed with S, e.g., MAX_S, while UDAFs for aggregates in the time dimension are named *CUBE<AGGREGATE>_<INTERVAL>*, e.g., CUBE_AVG_HOUR. Aggregates on models in the user-defined dimensions can be reduced to simple aggregates with a GROUP BY on the appropriate columns in the Segment View. As a result, we only show how simple aggregates and aggregates in the time dimension can be executed on models.

VI-B Aggregate Queries

To allow users to query time series instead of time series groups, a mapping between $Tid$s and $Gid$s is performed during query processing using the ids stored in the Time Series table, see Figure 6. Queries and results only use $Tid$s. $Gid$s are pushed to the segment group store so it only has to index $Gid$s. MDB only supports predicate push-down for Tid, StartTime, and EndTime [1], but MDB+ also pushes user-defined dimensions by rewriting members in the WHERE clause to the $Gid$s of the groups with time series with these members.

A simple aggregate using the Segment View is shown in Figure 11. First, the master replaces the $Tid$s and members in the queries’ WHERE clause with $Gid$s and sends it to the workers (Rewriting). Then, each worker creates an iterator for the relevant segments in its segment group store (Initialize) and computes the aggregate for each segment read using the iterator (Iterate). Last, to support distributive and algebraic functions, the result is computed from the intermediates (Finalize).

VI-C Aggregate Queries in the Time Dimension

As the Segment table stores the start time and end time for each segment, see Figure 6, aggregates in the time dimension can be computed from it. An example of aggregation in the time dimension using the Segment View is shown in Figure 12. The query computes the sum per hour on models representing the time series with $Tid=1$–$3$ using the UDAF CUBE_SUM_HOUR. After rewriting, the aggregate is computed for the interval from $t_{s}=00{:}13$ until $01{:}00$ which is the next timestamp delimiting two aggregation intervals. Then it is computed from $01{:}00$ until $02{:}00$, and from $02{:}00$ to and including $t_{e}=02{:}48$. The last interval is inclusive as the segments are disconnected, see Section III-B. The pseudo-code for executing aggregates in the time dimensions using the Segment View is shown in Algorithm 3. In Line 1 the query is rewritten (Rewriting), each worker creates an iterator for the relevant segments in Line 2 (Initialize), and in Line 3–10 the aggregate is computed for each segment and time interval (Iterate). Last, the final result is computed and returned in Line 13 to support distributive and algebraic functions (Finalize).

VII Evaluation

VII-A Overview and Evaluation Environment

We compare MDB+ to state-of-the-art big data formats and systems used in industry (ORC, Parquet, Cassandra), the popular TSMS InfluxDB (together termed industry formats), and the model-based MMC TSMS MDB [1]. The industry formats all use lossless compression, while MDB and MDB+ are model-based and support lossless and lossy compression. RDBMSs are not included due to their poor compression for time series [1]. To separate the effect of our methods from the difference in implementation between MDB and MDB+, we evaluate MDB+ using the best correlation primitives (MDB+$+$GB), using auto with weighted dimensions (MDB+$+$GA), and with grouping disabled (MDB+$-$G). MDB+$-$G should be faster when queries only require a few time series per group, e.g., simple aggregate and point/range queries, while MDB+$+$GA and MDB+$+$GB should perform better for ingestion, compression, and queries on entire groups. MDB+ can thus be configured depending on the exact use case. We use seven nodes, each with an i7-2620M, 8 GiB of 1333 MHz DDR3 memory, a 7,200 RPM hard drive, and 1 Gbit Ethernet. Ubuntu 16.04, InfluxDB 1.4.2, Hadoop 2.8.0, Spark 2.1.0, and Cassandra 3.9 are installed on ext4. The master is a Primary / Secondary HDFS NameNode and Spark Master, while the six workers are Cassandra Nodes, HDFS Datanodes, and Spark Slaves. Spark is used for query processing, except for InfluxDB as the open-source version and existing Spark connectors do not support distribution. Instead, we partition each data set across all workers using range-partitioning and execute queries across workers in parallel from the master. Default configurations are used when possible, and changed values are selected to work well with the hardware and data sets used. For MDB+ we use length limit $50$, split fraction $10$, and write segments in batches of $50{,}000$. The default error bound is 10% for MDB and MDB+. InfluxDB-Java 2.10 is used, and data points are written in batches of $50{,}000$. Spark is limited to 4 GiB driver memory and 3 GiB executor memory so Cassandra and HDFS are stable, predicate push-down is enabled for all formats, and automatic unpersist of micro-batches is disabled. For Cassandra, the commitlog is set to 128 MiB, maximum batch size to 50 MiB, and DataStax Spark Connector version 2.0.3 is used. We only run the required software and disable replication. Graphs show the number of workers on the x-axis labels, use striped bars for MDB+$+$GB and MDB+$+$GA, and have a gap on the y-axis if the results differ very significantly between formats. MDB+ is designed for unbounded time series, but our evaluation uses three static real-life data sets. Unbounded time series are created by repeating static time series. The industry formats use the schema: (Tid int, TS timestamp, Value float, <Dimensions>). timestamp is each format’s timestamp type. Cassandra uses (Tid, TS, Value) as primary key, InfluxDB stores time series as one measurement with Tid as a tag, and for ORC and Parquet we store a file per series on HDFS in a folder named Tid=n so Spark can prune by Tid.

VII-B Data Sets and Queries

Data Set “EP” This real-life data set consists of 45,353 regular time series with gaps from energy production (e.g., humidity and wind speed) for 508 days, has $SI=60$ s, has two dimensions Production: Entity $\rightarrow$ Type and Measure: Concrete $\rightarrow$ Category, and uses 339 GiB as uncompressed CSV.

Data Set “EF” This real-life data set consists of 197 regular time series with gaps from wind parks (e.g., rotation speed and temperature). The data was collected with an approximate $SI=100$ ms from a Windows OPC DA server. A pre-processing step rounds timestamps to the nearest 200 ms and removes data points with equal timestamps (due to collection limitations not present in a production setup). It has two dimensions Location: Entity $\rightarrow$ Park $\rightarrow$ Country and Measure: Concrete $\rightarrow$ Category, and uses 372 GiB as uncompressed CSV.

Data Set “HD” MDB+ was motivated by the energy domain, but we demonstrate its generality using a data set from histdata.com (e.g., currency exchange rates, commodities, and indexes). It consists of 330 regular time series with gaps from 2000-2019, has $SI=60$ s, one dimension Forex: Concrete $\rightarrow$ Category $\rightarrow$ Pair, and uses 32.75 GiB as uncompressed CSV.

Queries The queries are based on discussions with turbine owners: small simple aggregate queries simulate interactive analysis (S-AGG), large-scale simple aggregate queries evaluate scalability (L-AGG), medium-scale multi-dimensional aggregate queries simulate reporting (M-AGG). Point/range (P/R) queries extract sub-sequences. Half of S-AGG aggregate one time series while the rest GROUP BY Tid for five time series. L-AGG aggregate the full data set where half GROUP BY Tid. M-AGG is multi-dimensional aggregates on energy production measures. Half GROUP BY month and dimension, while the rest GROUP BY month, dimension and Tid. P/R queries (not MDB+’s intended use case but included for completeness) have WHERE clauses on either TS or Tid and TS.

VII-C Experiments

Ingestion Rate MDB+’s ingestion rate is evaluated by bulk loading without queries (B) on one node to directly compare with InfluxDB. We ingest EP energy production measures ($3500$ gzipped CSV files, 6.59 GiB) using spark-shell with default parameters. Dimensions are read from a 6.7 MiB CSV file. For the industry formats, dimensions are appended to data points from an in-memory cache. We also measure MDB+’s scalability on all six workers using bulk loading (B) and online analytics (O) with aggregate queries executed on random time series using Segment View during ingestion. MDB+ uses a specialized ingestor on one node, and Spark Streaming with 5 s micro-batches and one receiver per worker when distributed. We measure MDB+ ingestion time while ingesting an unbounded time series on one node for 1.5 days, to show it is stable.

The results are shown in Figure 28. MDB+$+$GB and MDB+$+$GA create the same 1761 groups with 1.99 time series on average. Due to its better compression, MDB+$+$GA ingests 2.16–13.7x faster than the other formats. MDB+$-$G is already 1.89x faster than MDB due to our optimizations (see Table I). On one node, MDB+ performed equivalently using spark-shell’s default configuration and the cluster’s configuration. On six nodes, MDB+ achieves a 4.98–5.56x speedup for bulk loading and a 4.68–5.06x speedup for online analytics. The ingestion rate is stable and increases by 3% over 1.5 days; short-term ingestion rate drops match JVM garbage collections.

**Effect of Error Bound and Grouping ** Compression is evaluated using EP, EF, and HD. $\epsilon$ is 0%, 1%, 5%, and 10% for MDB and MDB+, and 0% for the industry formats. For EP, Measure determines correlation better than Production, whose weight thus is decreased to only group time series with equal Production members by MDB+$+$GA. For each data set we show the storage and model types used, and actual average error as $(\sum_{n=1}^{|DP|}|rv_{n}-av_{n}|/\sum_{n=1}^{|DP|}|rv_{n}|)$ $\times 100$ where $DP$ is ingested data points, $av_{n}$ is the $n$th approximated value, and $rv_{n}$ is the $n$th real value. As EP, EF, and HD contain correlated time series, grouping should reduce the storage used. We compare our grouping methods with a baseline value-based method that groups time series with equivalent min and max values (computed offline). Last, using instrumentation, we find the overhead of both static grouping, and dynamic splitting and merging of groups during ingestion, see Section IV.

EP results are seen in Figure 28 with MDB+$+$GB correlation set as Production 0, Measure 1 ProductionMWh as EP has multiple energy production measures per entity. MDB+$+$GB creates 39,164 groups with an average size of 1.16 from 45,353 time series in only 17.86 minutes, while MDB+$+$GA creates 35,643 groups with an average size of 1.27 in only 21.13 minutes. Recall that static grouping is only run once before ingestion begins. Splitting and merging use at most 1.19% of the run-time. MDB+ uses up to 16.2x less storage than the industry formats, while the highest average error is only 0.34% ($\epsilon=10\%$). MDB+$+$GB uses 1.44–1.56x less storage than MDB+$-$G, while MDB+$+$GA uses 1.18–1.37x less storage than MDB+$-$G as all measurements in the same category on each entity are grouped.

EF results are seen in Figure 28 with MDB+$+$GB correlation set as 0.4166667 which groups the same measurement. MDB+$+$GB creates 26 groups of average size 7.58 from 197 time series in 0.02 s; MDB+$+$GA creates 50 groups of average size 3.94 in 0.03 s. Splitting and merging use at most 1.88% of the run-time. MDB+ uses up to 113x less storage than the other formats, while the highest average error is only 1.72% ($\epsilon=10\%$). MDB+$+$GB uses 1.60–1.96x less storage than MDB+$-$G, while MDB+$+$GA uses 1.37–1.75x less storage than MDB+$-$G as the same measurements in a park are grouped.

For HD MDB+$+$GB is not included in Figure 28 as MDB+$+$GA outperformed our manual attempts. MDB+$+$GA creates 132 groups of average size 2.5 from 330 time series in 0.05 s. Splitting and merging use at most 0.014% of the run-time. MDB+ uses up to 48.08x less storage than the other formats, while the highest average error is only 0.15% ($\epsilon=10\%$). MDB+$-$G uses 1.36–2.54x less storage than MDB+$+$GA as prices for each pair are grouped.

Surprisingly, MDB+$-$G performs like MDB despite using the more restrictive PMC-Mean and not PMC-MR (see Table 4).

Figure 28–28 show that all model types are used for all data sets, and that MDB+ adapts to groups by using Gorilla more. This is expected as all time series in an entire group must exhibit a constant or linear pattern to efficiently use PMC-Mean or Swing with MMGC, in contrast to MMC.

When grouping EP with the baseline value-based method, 8,487 groups of average size 5.34 are created. As MDB+ stores gaps in 64 bits, groups larger than 64 are split. The storage required is 8.00–6.49 GiB ($\epsilon=0$–$10\%$). As EP contains no Location dimension, our methods cannot group time series from co-located entities which might explain why the baseline is slightly better. For EF, 71 groups of average size 2.77 are created, using 1.09–0.89 GiB ($\epsilon=0$–$10\%$), and thus the baseline is slightly worse than our methods despite both grouping time series with similar measures. Last, for HD only 252 groups of average size 1.31 are created and a few groups had to be split. The storage required is 2.66–0.52 GiB ($\epsilon=0$–$10\%$), so the baseline again performs worse than our methods. In general, the baseline (value-based grouping) is worse than our grouping methods when considering all data sets, and furthermore requires the full data set to be analyzed offline.

Automatic and Distance-based Grouping We evaluate distance-based grouping by ingesting all data sets with distances up to $0.50$. The number of dimensions and levels limit the possible distances, e.g., EP’s are in $0.25$ increments. The results for EP and EF are shown in Figure 28. For HD only 0.3333334 is below $0.5$, and using 0.66666667 uses 1.39–6.33x more storage than MDB+$-$G. For distances above zero 35643–6757 groups of average size 1.27–6.71 are created for EP, and 65–26 groups of average size 3.03–7.58 for EH. As expected, only the lowest distance decreases storage for all data sets compared to MDB+$-$G. Thus, our automatic grouping method is sound and users can exploit distance-based grouping as using 0.4166667 uses less storage than auto for EF.

Scale-out Using L-AGG we evaluate the scalability of all formats on the cluster, and of MDB+$+$GB on 1–32 Standard_D8_v3 Azure nodes (chosen based on Spark, Cassandra, and Azure documentation). Both use the same configuration, but Spark can use 50% of each node’s memory on Azure as no crashes occur. EP is duplicated until the data ingested by each node exceeds its memory, so MDB+$+$GB cannot cache it all in memory. The values of each duplicated data set are multiplied with a random value in the range [0.001, 1.001) to avoid repeated values. Queries are run using an appropriate method: InfluxDB’s Java Client (J), ModelarDB’s Segment View (S) and Data Point View (DP), and a Spark Data Frame (F) for Cassandra, Parquet, and ORC.

Cluster results are shown in Figure 28. MDB+$+$GB outperforms almost all other formats: Parquet is only 1.66x faster despite its column-oriented layout which favors S-AGG. However, Parquet is 2.41x slower than MDB+$+$GB to ingest data, does not support online analytics, and uses up to 11.6x more storage for EP. InfluxDB runs out of memory despite only sharing with the OS. In [1] we show that MDB outperforms InfluxDB at scale. The average query result error is only 0.024% for MDB+$-$G, MDB+$+$GA, and MDB+$+$GB. Azure results are shown in Figure 28. MDB+$+$GB scales linearly for S and DP, which is expected as MDB+ assigns each time series group to a node so shuffling is avoided.

Additional Query Processing Performance To further evaluate MDB+ query performance we run S-AGG, P/R, and M-AGG on EP and EH on the cluster. MDB cannot run M-AGG as dimensions are not supported, nor can InfluxDB as dynamically sized time intervals are not supported [20].

S-AGG results are shown in Figures 28–28. For EP, MDB+ is much faster than Cassandra and only slightly slower than the rest. MDB+$-$G is slightly slower than MDB so supporting queries on groups adds a very small overhead on EP’s short time series. MDB+$-$G and MDB+$+$GB perform similarly despite MDB+$+$GB reading a group for 25.7% of the Tids. The average query result error is only 0.043% for MDB+. For EF, MDB+$-$G is only significantly slower than Parquet (4.38x) due to its column-oriented layout, but Parquet ingests 2.12x slower and uses 41.03–43.82x more storage for EF. Also, despite using significantly less storage, the average query result error is only 0.033% for MDB+$-$G, 0.26% for MDB+$+$GA, and 0.28% for MDB+$+$GB. EF has long time series. As the average group size grows, queries must read larger groups to get a single time series and thus slow down. Users can thus prioritize query performance (for monitoring) or compression (for archiving).

P/R is not MDB+’s intended use case but included for completeness. For EP, MDB+$+$GB is faster than Parquet (4.55x) and MDB (1.14x), but slower than InfluxDB (20.18x), Cassandra (3x), and ORC (1.52x). For EF, MDB+$-$G is faster than Cassandra (1.34x) and Parquet (1.05x), but slower than InfluxDB (766x), ORC (28.35x), and MDB (1.47x). While InfluxDB is faster for P/R, it cannot execute L-AGG and M-AGG, is 5.13x slower to ingest data, and uses up to 6.49x more storage. The average query result error is 0.012–2.01% for MDB+. Thus, MDB+ is competitive with the big-data formats. EF grouping has a trade-off between storage and performance.

M-AGG results are shown in Figures 28–28. For EP, M-AGG-1 queries GROUP BY category which matches the groups created by MDB+$+$GB. Thus, MDB+$+$GB only reads the time series required for each query, making it 1.52–45.14x faster than the other formats. M-AGG-2 queries GROUP BY concrete and as MDB+$+$GB can execute queries on each time series in a group, unlike simple aggregates, it is 1.97–49.52x faster. The average query result error is 0.0027% for MDB+. For EH, M-AGG-1 queries GROUP BY park and MDB+$-$G is 3.17–630x faster, while it is 2.93–579x faster for M-AGG-2 where the queries GROUP BY entity. The average query result error is 0.014–0.17% for MDB+. For EF, MDB+$+$GB is a trade-off as it groups all energy production measures together.

Summary of Evaluation Compared to the other formats, MDB+ provides a high and stable ingestion rate (up to 13.7x faster) due to an efficient ingestion method and high compression (up to 113x less storage required) while supporting online analytics. The high compression is due to GOLEMM compressing correlated time series together in groups using multiple model types. These groups are created automatically by MDB+ (MDB+$+$GA) or by users (MDB+$+$GB). GOLEMM uses suitable model types for each data set and error bound pair. MDB+ is up to 50.94x, 497x, and 630x faster for L-AGG, S-AGG, and M-AGG, respectively, due to model-based query processing, while still competitive for P/R. We have also shown that MDB+ scales linearly.

VIII Related Work

Surveys exist about models for time series [5, 6], compression of sensor data [3, 4], signal processing in the energy domain [21], Hadoop-based OLAP [22] and TSMSs [23].

Group Compression: Compression of correlated time series is mainly used for sensor data acquisition [3]. Yang et al. [2], e.g., cluster time series based on regression models and suppress transfer of similar data for each cluster. Methods for TSMSs have been proposed. Gamps [11] approximates time series using constant functions and then relaxes the error bounds before compressing them together. MTSC [12] uses graph-based methods to partition time series into correlated groups, uses constant functions for compression, and represents each group as a base signal and offsets. CORAD [13] is a lossy dictionary compression algorithm. Each segment is encoded as values from a pre-trained dictionary and deduplication is used for correlated segments. Some methods use groups for other purposes than improving compression. Sprintz [24] uses groups so decompression can use SIMD, while EdgeDB [25] uses groups to reduce the number of I/O operations. Other domains also use group compression, e.g., Elgohary et al. [17] compress correlated features for machine learning together.

Multi-Model Compression: MMC was proposed in [7]. Model types fit models to data points in parallel until they all fail, the model with the best compression is stored. The Adaptive Approximation (AA) algorithm [8] fits models in parallel and creates segments as each model type fails. After all model types fail, segments from the model type with the best compression are stored. In [9] regression models are fitted in sequence with coefficients incrementally added. The model providing the best compression is stored when a user-defined number of coefficients is reached. AMMMO [10] only uses lossless compression methods. Each segment is analyzed to create a set of candidate methods, and the best method for each data point is then selected from this set.

Model-Based Data Management Systems: DBMSs with support for models have been proposed. MauveDB [26] integrates models into an RDBMS using views, to support data cleaning without exporting data to another application. FunctionDB [27] natively supports polynomial function models and evaluates queries on these if possible. Plato [28] uses models for data cleaning and allow user-defined model types to be added. Recent work [29] on Plato focuses on providing tight deterministic error guarantees for a set of queries on models. Guo et al. [30] combine an in-memory tree index, a distributed key-value store, and MapReduce to store and query models in a distributed system. MDB [1] is a model-based TSMS, with a MMC compression method that supports user-defined model types, that integrates with Spark and Cassandra.

MMGC**, GOLEMM, and MDB+:** In contrast to existing model-based compression algorithms [11, 12, 13, 7, 8, 9, 10] and systems [26, 27, 28, 30, 1, 29], MDB+ uses multiple model types to compress time series groups. This unifies MMC and MGC, and creates the new MMGC category of model-based compression methods with GOLEMM being the first. In addition, MDB+ can automatically group correlated time series using only their dimensions, and provides primitives for user to effectively specify groups. As groups are created before ingestion, workers receive data directly from the time series. Compared to GOLEMM, the compression methods used for smart meter data [4] (e.g., Huffman Encoding and LZ-based methods) are not optimized for regular time series with gaps. They also only use one representation each, making them unable to adapt as time series change [5], while GOLEMM compensates for the weaknesses of one model type by using another at run-time. In terms of compression, Figure 28–28 clearly shows that GOLEMM outperforms LZ4 as used by Cassandra. Also, MDB+’s extension API allows users to add the methods as new model types without recompiling the system. In summary, MDB+ provides state-of-the-art compression and query performance by storing groups of correlated time series as compressed models and executing OLAP queries on these.

IX Conclusion & Future Work

Motivated by the need to efficiently manage huge data sets of time series from reliable sensors, we presented several novel contributions: (i) The * Multi-Model Group Compression (MMGC)* category of model-based compression methods for time series. (ii) The first MMGC method GOLEMM and model types extended to compress time series groups. (iii) Primitives so users effectively can group time series, and based on these, an automated method using the time series dimensions. (iv) Algorithms for executing simple and multi-dimensional aggregate queries on models of time series groups. We added our methods to the model-based TSMS ModelarDB. We named this version ModelarDB+. Our evaluation showed that compared to widely used systems, ModelarDB+ provides up to: 13.7x faster ingestion due to high compression, 113x better compression due to GOLEMM’s adaptivity, and 630x faster aggregates as they are computed from models.

In future work, we will simplify using ModelarDB+ and increase its query performance by: (i) Developing indexing techniques exploiting that data is stored as models. (ii) Developing query and cluster aware grouping and partitioning methods. (iii) Supporting high-level analytical queries, e.g., similarity search, on models. (iv) Removing or inferring parameter arguments.

X Acknowledgments

This research was supported by the DiCyPS center funded by Innovation Fund Denmark, the GOFLEX project EU grant No 731232, and Microsoft Azure for Research. We also thank our data providers for the real-life data sets and domain insights.