Previously if you issued a CQ with a resample interval higher than the
query interval, such as the following:
CREATE CONTINUOUS QUERY cq ON db
RESAMPLE EVERY 4m
BEGIN
SELECT mean(value) INTO cpu_mean FROM cpu GROUP BY time(2m)
END
This would result in strange behavior because the FOR value defaulted to
the GROUP BY interval and the minimum time passing before a CQ ran was
also the resample interval, so it wouldn't run the appropriate intervals
even if you set the resample duration to a higher value.
This tweaks the CQ runner to set the minimum interval before a bucket
becomes capable of running to the lower of the query interval or the
resample interval instead of always using the resample interval.
It also sets the default resample duration to be the higher value of the
query interval or the resample interval so the above query gets a
default of 4m instead of 2m and will execute 2 queries every 4 minutes.
If you manually set the resample duration to a lower value than the
resample interval, the old behavior will still happen and should be
considered an error.
This also makes trying to create a continuous query with a resample
duration of below the resample interval or query interval (whichever is
higher) as an error returned by the parser.
Fixes#5286.
* Add dir, hostname, and bind address to top level config since it applies to services other than meta
* Add enabled flags to example toml for data and meta services
* Wire up add/remove raft peers and meta servers to meta service
* Update DROP SERVER to be either DROP META SERVER or DROP DATA SERVER
* Bring over statement executor from old meta package
* Start meta service client implementation
* Update meta service test to use the client
* Wire up node ID/meta server storage information
This makes the following syntax possible:
CREATE CONTINUOUS QUERY mycq ON mydb
RESAMPLE EVERY 1m FOR 1h
BEGIN
SELECT mean(value) INTO cpu_mean FROM cpu GROUP BY time(5m)
END
The RESAMPLE option customizes how often an interval will be sampled and
the duration. The interval is customized with EVERY. Any intervals
within the resampling duration on a multiple of the resample interval
will be updated with the new results from the query.
The duration is customized with FOR. This determines how long an
interval will participate in resampling.
Both options are optional. If RESAMPLE is in the syntax, at least one of
the two needs to be given. The default for both is the interval of the
continuous query.
The service also improves tracking of the last run time and the logic of
when a query for an interval should be run. When determining the oldest
interval to run for a query, the continuous query service determines
what would have been the optimal time to perform the next query based on
the last run time. It then uses this time to determine the oldest
interval that should be run using the resample duration and will
resample all intervals between this time and the current time as opposed
to potentially forgetting about the last run in an interval if the
continuous query service gets delayed for some reason.
This removes the previous config options for customizing continuous
queries since they are no longer relevant and adds a new option of
customizing the run interval. The run interval determines how often the
continuous query service polls for when it should execute a query. This
option defaults to 1s, but can be set to 1m if the least common factor
of all continuous queries' intervals is a higher value (like 1m).
For DERIVATIVE aggregations there was only one check performed: if
aggregation function is given when using group by. However the nested
aggregation function syntax was not checked.
Fixes#4123
When using derivative, it is required that aggregate function is used as
sub-call when grouping by time is used. However, AST parsing used to check
if WHERE-clause contained condition with 'time'.
Fix this by changing check to see if groupByInterval is present.
Modify also related error case tests and add check for
select derivative(...) ... where time > ...
This commit adds the ability to list all shards in the cluster
and return their id, start time, end time, expiry time, and
owner ids. Shards are grouped by database.
Fixes#3562
Since we set up the aggregate queries so that iterator is ordered,
we only need to look at the first value. This cuts about 10 seconds
off a large single series query running first.
If 2 or more points during this map-and-reduce share the same timestamp,
the tie is broken by looking at the value. This ensures that these
functions operate in a deterministic manner.
This solution due to @jwilder
If no chunking was requested by the user, the co-ordinating node buffers all
results in RAM before emitting a single result. However buffering was not
merging results for rows which had data for the same series. This change fixes this.
Fixes issue #3242.
Any literal values in a math query e.g. the '2' in 'value * 2' are
stored as float64, so all other values must be cast to this type. This
does mean that precision may be lost if the integer values are greater
than 2^53.
When stringifying a query, we would print the identifier bare most
of the time. This caused issues when stringifying an identifier
that contained elements of syntax. For example, querying for the
value "in-bytes" would fail because the mapper would serialize it to
in-bytes and would parse it as an expression. Same problem occured
when using keywords as identifier names, such as select or in.
Fixes#3547
Michael Mattioli
David Norton
Jonathan A. Sternberg
Paul Dix
Paulo Pires
Mark Rushakoff
Mark Rushakoff
Nathaniel Cook
mengjingleli
Philip O'Toole
Philip O'Toole
Paweł Kowalak
Mateusz Dymiński
ch33hau
Nathaniel Cook
Sean Beckett
Konstantin Shaposhnikov
linearb
Nick Dawbarn
Cory LaNou
Jason Wilder
Ben Johnson
Jari Sukanen
Daniel Morsing
Jason Wilder
Cory LaNou
Gunnar
Haneysmith, Nathan
Josh Horwitz