TSDB: Implement downsampling on time-series indices#85708
TSDB: Implement downsampling on time-series indices#85708csoulios merged 78 commits intoelastic:masterfrom
Conversation
Not needed for timeseries indices
Removed most of the configuration, which is extracted from the index mapping. Modified TransportRollupAction to extract the rollup config from the field caps
Removed most of the configuration, which is extracted from the index mapping. Modified TransportRollupAction to extract the rollup config from the field caps.
|
Pinging @elastic/es-analytics-geo (Team:Analytics) |
|
Hi @csoulios, I've created a changelog YAML for you. |
server/src/main/java/org/elasticsearch/index/mapper/TimeSeriesParams.java
Show resolved
Hide resolved
nik9000
left a comment
There was a problem hiding this comment.
I looked at it for a while and left some comments. I think I want to have another look on Monday too.
| numSent.addAndGet(-items); | ||
| if (failure != null) { | ||
| long items = request.numberOfActions(); | ||
| numSent.addAndGet(-items); |
There was a problem hiding this comment.
I think this one might still be worth looking at.
x-pack/plugin/rollup/src/main/java/org/elasticsearch/xpack/rollup/v2/TransportRollupAction.java
Outdated
Show resolved
Hide resolved
x-pack/plugin/rollup/src/main/java/org/elasticsearch/xpack/rollup/v2/TransportRollupAction.java
Show resolved
Hide resolved
| } else if (e.getValue().values().iterator().next().getMetricType() != null) { | ||
| metricFieldCaps.put(field, fieldCaps); | ||
| } else { | ||
| // TODO: Field is not a dimension or a metric. Treat it as a tag |
There was a problem hiding this comment.
For now we just throw tags away, right?
There was a problem hiding this comment.
Yes, in a following PR we will add the tags. I left this there as a placeholder
x-pack/plugin/rollup/src/main/java/org/elasticsearch/xpack/rollup/v2/TransportRollupAction.java
Show resolved
Hide resolved
x-pack/plugin/rollup/src/main/java/org/elasticsearch/xpack/rollup/v2/TransportRollupAction.java
Outdated
Show resolved
Hide resolved
| if (resizeResponse.isAcknowledged()) { | ||
| // 6. | ||
| publishMetadata(originalIndexName, tmpIndexName, rollupIndexName, listener); | ||
| // 5. Add rollup index to data stream and publish rollup metadata |
There was a problem hiding this comment.
Should we wait for all of the replicas to recover? I think a health check for green on the index is enough for that. I'm not sure that's a thing we always want, but it seems like a reasonable default.
There was a problem hiding this comment.
It can wait for a follow up if you'd like.
There was a problem hiding this comment.
Not sure why we should wait for the replicas to recover. I was thinking that this can happen in parallel. Any concerns we may lose the primary shard while deleting the source index?
I am afraid that waiting for replicas to recover may take lots of time.
x-pack/plugin/rollup/src/main/java/org/elasticsearch/xpack/rollup/v2/TransportRollupAction.java
Show resolved
Hide resolved
- Set refresh_interval to -1 - Refresh index before adding to data stream - Force merge index in the end
nik9000
left a comment
There was a problem hiding this comment.
Let's get this in. There's certainly more to do but I feel like this is a good start for rollups.
| // 5. Refresh rollup index | ||
| refreshIndex(rollupIndexName, parentTask, ActionListener.wrap(refreshIndexResponse -> { | ||
| if (refreshIndexResponse.getFailedShards() == 0) { | ||
| // 6. Add rollup index to data stream and publish rollup metadata |
| ); | ||
| } | ||
| }, | ||
| e -> deleteRollupIndex( |
There was a problem hiding this comment.
I wonder if there is a good way to reduce the duplicate calls here. Oh well, in a follow up.
| new ElasticsearchException( | ||
| "Failed to force-merge index [" + rollupIndexName + "]", | ||
| e | ||
| ) |
There was a problem hiding this comment.
Will this fail the request but not cause the destination index to be deleted? What will ILM think of that?
There was a problem hiding this comment.
I was thinking about it. If we reach at this point, rollup will be successful even if force-merge fails. Also, at this point we have delete the source index, so there's no way to rollback and restart the operation.
On the other hand, if force-merge fails we end up with a perfectly healthy rollup index with multiple segments. So, do you think at this point we can log and swallow the exception?
There was a problem hiding this comment.
In 393d7c2, I changed it so that it does not fail the rollup action.
| * operation. | ||
| */ | ||
| logger.error( | ||
| "Failed to force-merge rollup index [" + rollupIndexName + "]", |
There was a problem hiding this comment.
👍
It's probably worth a test that fails here and makes sure we don't fall over. I think this will do the job but it's probably worth tracing this path. Both as a "for now" thing and to make sure that changes in the future don't cause us to lose this property.
This PR implements downsampling operation on time series indices.
The PR creates a _rollup endpoint that allows users to downsample an index and can be
accessed by the following call:
POST /<source_index>/_rollup/<rollup_index>
{
"fixed_interval": "1d"
}
Requirements
An index can be downsampled if all of the following requirements are met:
Must be a time series index (have the index.mode: time_series index setting)
Must not be writeable (have the index.blocks.write: true index setting)
Must have dimension fields marked with mapping parameter time_series_dimension: true
Must have metric fields marked with mapping parameter time_series_metric
Relates to elastic#74660
Fixes elastic#65769
Fixes elastic#69799
Finally, this PR is based on the code written for elastic#64900
This PR adds support for an ILM action that downsamples a time-series index by invoking the _rollup endpoint (#85708) A policy that includes the rollup action will look like the following PUT _ilm/policy/my_policy { "policy": { "phases": { "warm": { "actions": { "rollup": { "fixed_interval": "24h" } } } } } } Relates to #74660 Fixes #68609
This PR implements downsampling operation on time series indices.
The PR creates a
_rollupendpoint that allows users to downsample an index and can beaccessed by the following call:
Requirements
An index can be downsampled if all of the following requirements are met:
index.mode: time_seriesindex setting)index.blocks.write: trueindex setting)time_series_dimension: truetime_series_metricSteps
The steps followed by the downsampling action are the following:
index.modeindex.routing_pathindex.time_series.start_timeindex.time_series.end_timeindex.rollup.source.uuidindex.rollup.source.nametime_series_dimensionwill be created in the rollup index with exactly the same mapping.time_series_metricwill be created and their field type will change toaggregate_metric_double.TimeSeriesIndexSearcherimplementation to traverse over the (sorted by_tsid,@timestamp) source index and create the rollup index.TODO
Relates to #74660
Fixes #65769
Fixes #69799
Finally, this PR is based on the code written for #64900