-
Notifications
You must be signed in to change notification settings - Fork 24.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TSDB: Implement downsampling on time-series indices #85708
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now we just throw tags away, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can wait for a follow up if you'd like.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe label it 6-8?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 393d7c2
); | ||
} | ||
}, | ||
e -> deleteRollupIndex( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
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
_rollup
endpoint 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_series
index setting)index.blocks.write: true
index setting)time_series_dimension: true
time_series_metric
Steps
The steps followed by the downsampling action are the following:
index.mode
index.routing_path
index.time_series.start_time
index.time_series.end_time
index.rollup.source.uuid
index.rollup.source.name
time_series_dimension
will be created in the rollup index with exactly the same mapping.time_series_metric
will be created and their field type will change toaggregate_metric_double
.TimeSeriesIndexSearcher
implementation 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