Time series database

From Wikipedia, the free encyclopedia

A time series database server (TSDS) is a software system that is optimized for handling time series data, arrays of numbers indexed by time (a datetime or a datetime range). In some fields these time series are called profiles, curves, or traces. A time series of stock prices might be called a price curve. A time series of energy consumption might be called a load profile. A log of temperature values over time might be called a temperature trace. Despite the disparate names, many of the same mathematical operations, queries, or database transactions are useful for analysing all of them. And the implementation of a database that can correctly, reliably, and efficiently implement these operations must be specialized for time-series data. Despite this specialized treatment, TSDSs are nonetheless subject to Brewer's Theorem[1] which states that CAP (Consistency, Availability, Partitionability) is a spectrum of capabilities and not a single achievable requirement, at least for large transaction bandwidth and large data sets.[2]

TSDSs are databases that are optimized for time series data. Software with complex logic or business rules and high transaction volume for time series data are not practical with the alternative to TSDS, relational database management systems. Flat file databases are not a viable option either, if the data and transaction volume reaches a maximum threshold determined by the capacity of individual servers (processing power and storage capacity). Queries for historical data, replete with time ranges and roll ups and arbitrary time zone conversions are difficult in a relational database. Compositions of those rules are even more difficult. This is a problem compounded by the free nature of relational systems themselves. Many relational systems are often not modelled correctly with respect to time series data. TSDS on the other hand impose a model and this allows them to provide more features for doing so.

Ideally, these repositories are often natively implemented using specialized database algorithms. However, it is possible to store time series as binary large objects (BLOBs) in a relational database or by using a VLDB approach coupled with a pure star schema. Efficiency is often improved if time is treated as a discrete quantity rather than as a continuous mathematical dimension. Database joins across multiple time series data sets is only practical when the time tag associated with each data entry spans the same set of discrete times for all data sets across which the join is performed.[3]

Overview

The TSDS allows users to create, enumerate, update and destroy various time series and organize them in some fashion. These series may be organized hierarchically and optionally have companion metadata available with them. The server often supports a number of basic calculations that work on a series as a whole, such as multiplying, adding, or otherwise combining various time series into a new time series. They can also filter on arbitrary patterns defined by the day of the week, low value filters, high value filters, or even have the values of one series filter another. Some TSDSs also build in a wealth of statistical functions.

For example, consider the following hypothetical "time series" or "profile" expression:

SELECT nymex/gold_price * nymex/gold_volume

To analyze this, the TSDS would join the two series nymex/gold_price and nymex/gold_volume based on the overlapping areas of time for each, multiply the values where they intersect, and then output a single composite time series.

Obviously, more complex expressions are allowed. TSDSs often allow users to manage a repository of filters or masks that specify in some way a pattern based on the day of a week and a set of holidays. In this way, one can readily assemble time series data. Assuming such a filter exists, one might hypothetically write

SELECT onpeak( cellphoneusage )

which would extract out the time series of cellphoneusage that only intersects that of 'onpeak'. Some systems might generalize the filter to be a time series itself.

This syntactical simplicity drives the appeal of the TSDS. For example, a simple utility bill might be implemented using a query such as:

SELECT MAX( onpeak( powerusagekw ) ) * demand_charge;
 
SELECT SUM( onpeak( powerusagekwh ) ) * energy_charge;

TSDS also generally have conversions to and from specific time zones implemented at the server level.

Example

A workable implementation of a time series database can be easily deployed in a conventional SQL-based relational database provided that the database software supports both binary large objects (BLOBs) and user-defined functions. SQL statements that operate on one or more time series quantities on the same row of a table or join can easily be written, as the user-defined time series functions operate comfortably inside of a SELECT statement. However, time series functionality such as a SUM function operating in the context of a GROUP BY clause cannot be easily achieved.

Specialized database systems designed for TSDS are often dubbed NoSQL, because of their break from SQL, the language of relational database management system queries. Some example database software packages optimized for dealing with large volumes of time series data include:

See also

References

  1. ↑ http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
  2. ↑ http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.20.1495&rep=rep1&type=pdf
  3. ↑ http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
  4. ↑ tsdb: A Compressed Database for Time Series Luca Deri, Simone Mainardi, Francesco Fusco: Proceedings of the 4th International Workshop on Traffic Monitoring and Analysis (TMA), Wien, 2012
This article is issued from Wikipedia. The text is available under the Creative Commons Attribution/Share Alike; additional terms may apply for the media files.