Differences Between InfluxDB 0.9 and InfluxDB 0.10 | InfluxData Documentation Archive

This page aims to ease the transition to InfluxDB 0.10 for those more familiar with 0.9. It is not intended to be a comprehensive list of the differences between the versions. See InfluxDB’s Changelog for detailed release notes.

There are not many breaking changes between InfluxDB version 0.9 and InfluxDB version 0.10:

Continuous Query execution is now controlled by the CREATE CONTINUOUS QUERY statement.
tsm is the only storage engine available in InfluxDB 0.10, although the system can still read b1 and bz1 shards.
Multiple fields per point is now more efficient
With tsm it is no longer possible to overwrite the field set for a point.
Clustering implementation has incompatible improvements.

Continuous Query Execution

In InfluxDB 0.9 the CREATE CONTINUOUS QUERY statement defines the Continuous Query’s (CQ) database and the query to be performed. Settings in the [continuous_queries] section of the configuration file control the frequency at which the CQ runs and how much historical data the CQ covers. All CQs share the same configuration settings; this makes it difficult to optimize CQ execution for both short and long sampling intervals.

In InfluxDB 0.10 the CREATE CONTINUOUS QUERY statement also controls CQ execution. By default, CQs run at the same interval as the CQ’s GROUP BY time() interval, and the system calculates the query for the most recent GROUP BY time() interval. A new and optional RESAMPLE clause allows users to specify how often the CQ runs and the time range over which InfluxDB runs the CQ. The 0.9 CQ configuration settings are no longer in the configuration file and have been replaced by a single setting which controls how often InfluxDB checks to see if a CQ needs to run.

New documentation:

Note: CQs defined in InfluxDB 0.9 will still run in InfluxDB 0.10, but at a reduced frequency and with no resampling of data. We strongly recommend that you update your CQs to the new 0.10 syntax to avoid incomplete downsampling.

Data Storage Engine

InfluxDB 0.9 defaulted to using BoltDB for the underlying storage files. The storage engine was referred to as the b1 engine, or bz1 for versions 0.9.3+ that supported compression of the BoltDB files. As the database matured and performance improved, it became clear that BoltDB would not scale to the target performance. Starting with InfluxDB 0.9.4 we added as an available storage engine the Time Structured Merge tree (TSM). TSM was never the default engine for any 0.9.x version of InfluxDB.

With InfluxDB 0.10, TSM is the only option for new shards. While InfluxDB 0.10.0 can still read the older b1 and bz1 shards from InfluxDB 0.9, it will only create new TSM shards. InfluxData recommends converting all legacy shards to TSM shards as soon as feasible. TSM is more performant and stable, and it will result in a significant reduction in disk usage.

Multiple fields per point is now more efficient

With prior storage engines, requesting a single field required retrieving the entire field set from disk. With TSM it is possible to retrieve a partial field set from a point. This makes it more efficient to store multiple fields per point, and will improve both write and read throughput. Telegraf plugins have been updated to reflect this change, using multiple fields per point with a single measurement per plugin, rather than a single field per point across multiple measurements per plugin.

It is no longer possible to overwrite the field set for a point.

In InfluxDB 0.9, the system silently overwrites the field set of an old point if you write a new point with the same measurement, tag set, and timestamp. This behavior functions as a delete workaround for dropping individual points.

In InfluxDB 0.10, the system no longer overwrites the entire field set; if you write a new point with the same measurement, tag set, and timestamp as an old point, the field set becomes the union of the old field set and the new field set, where any ties go to the new field set. See Frequently Encountered Issues for an example.

Because of this change, overwriting an old point no longer functions as a delete workaround for dropping individual points. In 0.10, users will need to use DELETE SERIES. See GitHub Issue #1647 for developments on DELETE SERIES.

Clustering

InfluxDB 0.9 supported only hybrid nodes and data nodes. InfluxDB 0.10 supports hybrid nodes, data nodes, and consensus nodes. This feature allows users to separate out consensus nodes in very large clusters or configurations where data nodes are under heavy load. Another option is to have two nodes that act as hybrid nodes and one minimal resource node that acts as a consensus node. This last option is similar to some other databases that allow you to run with two large servers and an “arbiter”.

The new configuration has changed how users set up clusters in 0.10. See Cluster Setup for more information.