-
Notifications
You must be signed in to change notification settings - Fork 25.7k
Improving performance of get data streams API by avoiding getting effective mappings #138948
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
Changes from 3 commits
4607a68
731bc34
8e017eb
8bbd8f6
ea33136
376211e
33c321e
27ecc4a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,6 @@ | ||
| pr: 138948 | ||
| summary: Improving performance of get data streams API by avoiding getting effective | ||
| mappings | ||
| area: Data streams | ||
| type: bug | ||
| issues: [] |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -32,6 +32,7 @@ | |
| import org.elasticsearch.cluster.metadata.DataStreamLifecycle; | ||
| import org.elasticsearch.cluster.metadata.IndexMetadata; | ||
| import org.elasticsearch.cluster.metadata.IndexNameExpressionResolver; | ||
| import org.elasticsearch.cluster.metadata.MetadataCreateDataStreamService; | ||
| import org.elasticsearch.cluster.metadata.MetadataDataStreamsService; | ||
| import org.elasticsearch.cluster.metadata.MetadataIndexTemplateService; | ||
| import org.elasticsearch.cluster.metadata.ProjectMetadata; | ||
|
|
@@ -278,12 +279,22 @@ static GetDataStreamAction.Response innerOperation( | |
| } else { | ||
| indexTemplate = MetadataIndexTemplateService.findV2Template(state.metadata(), dataStream.getName(), false); | ||
| if (indexTemplate != null) { | ||
| final Settings settings; | ||
| try { | ||
| settings = metadataDataStreamsService.getEffectiveSettings(state.metadata(), dataStream); | ||
| } catch (IOException e) { | ||
| throw new RuntimeException("Failed to get effective settings for data stream: " + dataStream.getName(), e); | ||
| } | ||
| /* | ||
| * Here we intentionally avoid the full MetadataDataStreamService::getEffectiveSettings and instead do a shortcut that | ||
| * does not merge all mappings together in order to fetch the settings from additional settings providers. The reason | ||
| * is that this code can be called fairly frequently, and we do not need that information here -- we only need the | ||
| * settings so that we can get some ilm information and the index mode, neither of which come from additional settings | ||
| * providers. | ||
| */ | ||
| ComposableIndexTemplate template = MetadataCreateDataStreamService.lookupTemplateForDataStream( | ||
| dataStream.getName(), | ||
| state.metadata() | ||
| ); | ||
| Settings templateSettings = MetadataIndexTemplateService.resolveSettings( | ||
| template, | ||
| state.metadata().componentTemplates() | ||
| ); | ||
| final Settings settings = templateSettings.merge(dataStream.getSettings()); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this makes sense. Can we also add something like: assert settings.equals(metadataDataStreamsSettingsService.getEffectiveSettings(state.metadata(), dataStream)) : "these should always match etc etc";after this line, so that if we ever encountered a situation where a provider changed the settings, then we would fail tests? That way we only pay the cost when asserts are enabled.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think that that assertion would work, b/c the providers do change some of the settings. |
||
| ilmPolicyName = settings.get(IndexMetadata.LIFECYCLE_NAME); | ||
| if (indexMode == null && state.metadata().templatesV2().get(indexTemplate) != null) { | ||
| try { | ||
|
|
||
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 don't think that is true;
LogsdbIndexModeSettingsProviderseems to supply an index mode:elasticsearch/x-pack/plugin/logsdb/src/main/java/org/elasticsearch/xpack/logsdb/LogsdbIndexModeSettingsProvider.java
Line 133 in 4c33d20
Or am I misreading something?
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.
Oh good catch. That complicates things.
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'm thinking then that I'll still call getEffectiveSettings, but a new variant that lets you skip merging all the mappings.
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.
Oh, actually that next line that calls
resolveModeactually applies all of the additional settings providers and we get the correct mode anyway. I'll add a test that shows that.