Time series database
This article needs additional citations for verification. (August 2016) (Learn how and when to remove this template message)
A time series database (TSDB) 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. The implementation of a database that can correctly, reliably, and efficiently implement these operations must be specialized for time-series data.
TSDBs are databases that are optimized for time series data. Software with complex logic or business rules and high transaction volume for time series data may not be practical with traditional 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. TSDBs 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.
A TSDB 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 TSDBs also build in additional statistical functions that are targeted to time series data.
For example, consider the following hypothetical "time series" or "profile" expression:
select nymex/gold_price * nymex/gold_volume
To analyze this, the TSDB 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.
More complex expressions are allowed. TSDBs 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 TSDB. 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;
TSDBs also generally have conversions to and from specific time zones implemented at the server level.
Supporting time series data in a relational database
A workable implementation of a time series database can be 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.
IBM's Informix which is an extensible Object Relational database system includes a timeseries data type extension which includes optimized timeseries storage, a timeseries specific function library, and the ability to map timeseries data to virtual tables in relational format. This gives it the ability to process standard SQL constructs such as GROUP BY and analytical functions against timeseries data.
List of time series databases
The following list of open source and commercial systems provide support for time series data.
|eXtremeDB||Commercial||SQL, Python, C / C++, Java, and C#||[unreliable source?]|
|InfluxDB||MIT. Chronograf AGPLv3, Clustering Commercial||Go|||
|Informix TimeSeries||Commercial||C/C++|||
|Kx kdb+||Commercial||q|||
|Riak-TS||Apache License 2.0||Erlang|||
- Canary Labs
- "eXtremeDB on linuxquestions.org wiki". wiki.linuxquestions.org. Retrieved 2017-09-26.
- Joshi, Nishes. Interoperability in monitoring and reporting systems. Masteroppgave, University of Oslo, 2012.
- "influxdb license". GitHub. Retrieved 2016-08-14.
- "influxdb clustering". influxdata.com. Retrieved 2016-03-10.