Skip to content
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

[SOR] Remove fields API #153447

Closed
wants to merge 2 commits into from
Closed

Conversation

afharo
Copy link
Member

@afharo afharo commented Mar 22, 2023

Summary

Resolves #152808

Checklist

Risk Matrix

Risk Probability Severity Mitigation/Notes
Performance impact from loading the entirety of the documents High Low On average, the documents are small enough to consider this an issue.
External consumers may be affected by this breaking change. Low Low It's a very specific API that's probably not widely used (by 3rd-party apps). The workaround is fairly simple.

For maintainers

@afharo afharo added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Feature:Saved Objects release_note:skip Skip the PR/issue when compiling release notes backport:skip This commit does not require backporting labels Mar 22, 2023
@afharo afharo self-assigned this Mar 22, 2023
@afharo afharo force-pushed the sor/remove-fields-API branch 10 times, most recently from 3c087d4 to 72b8f87 Compare March 24, 2023 13:43
@@ -43,7 +43,6 @@ async function checkOrigin(
rootSearchFields: ['_id', 'originId'],
page: 1,
perPage: 1, // we only need one result for now
fields: ['title'], // we don't actually need the object's title, we just specify one field so we don't fetch *all* fields
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may want to add an option for retrieving the root fields only

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps an option to return just "meta" fields like ID, createdAt, updatedAt?

Comment on lines -120 to -126
if (req.query.fields) {
usageCounter?.incrementCounter({
counterName: `alertingFieldsUsage`,
counterType: 'alertingFieldsUsage',
incrementBy: 1,
});
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked our telemetry, and this is not used in 8.x versions.

Comment on lines -92 to -98
if (query.fields) {
usageCounter?.incrementCounter({
counterName: `legacyAlertingFieldsUsage`,
counterType: 'alertingFieldsUsage',
incrementBy: 1,
});
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Telemetry tells us that 7.16 was the last version this was used.

@afharo afharo marked this pull request as ready for review March 24, 2023 19:16
@afharo afharo requested review from a team as code owners March 24, 2023 19:16
@afharo afharo requested review from a team as code owners March 24, 2023 19:16
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-core (Team:Core)

@afharo afharo requested review from a team as code owners March 24, 2023 19:16
@afharo afharo requested a review from xcrzx March 24, 2023 19:16
@@ -57,7 +57,6 @@ export async function migrateLegacyAPMIndicesToSpaceAware({
type: 'space',
page: 1,
perPage: 10_000, // max number of spaces as of 8.2
fields: ['name'], // to avoid fetching *all* fields
Copy link
Member

@sorenlouv sorenlouv Mar 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This fee;s like a pretty big change in terms of performance. Is the suggestion to avoid using SOs for documents with many fields (or fields containing big blobs of data) where only few or lightweight fields are needed in the majories of queries?

We are already using custom (system) indices for certain features (agent configs, custom links) where SOs were deemed a bad fit. This seems like yet another reason to avoid SOs.

Edit: Perhaps worth adding to #80912

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm also concerned about the performance impact of this change. Synthetics is using saved objects for monitor configurations, and those documents can quite heavy. This is especially true for our project monitor feature where the script of the monitor is base64 encoded zip file of the script, plus any imports including node_modules.

If the saved object client was only called on the server side, and the fields set to the request were always hardcoded, not part of the HTTP API contract, and transformed to match the HTTP contract before returning the data, would that be enough to satisfy the requirements for the HTTP versioning initiative? This is close to how we use fields currently and matches our original expectations of the work needed to meet the requirements.

@botelastic botelastic bot added Team:APM All issues that need APM UI Team support Team:Fleet Team label for Observability Data Collection Fleet team Team:Uptime - DEPRECATED Synthetics & RUM sub-team of Application Observability labels Mar 24, 2023
@elasticmachine
Copy link
Contributor

Pinging @elastic/fleet (Team:Fleet)

@elasticmachine
Copy link
Contributor

Pinging @elastic/apm-ui (Team:APM)

@elasticmachine
Copy link
Contributor

Pinging @elastic/uptime (Team:uptime)

Copy link
Member

@azasypkin azasypkin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes in SO API integration tests LGTM.

@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
dashboard 387.9KB 387.9KB -34.0B
lens 1.3MB 1.3MB -17.0B
maps 2.7MB 2.7MB -48.0B
ml 3.4MB 3.4MB -17.0B
savedObjectsFinder 5.2KB 5.1KB -118.0B
securitySolution 15.8MB 15.8MB -17.0B
total -251.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
core 351.9KB 351.9KB -16.0B
savedObjects 29.5KB 29.5KB -17.0B
savedSearch 5.4KB 5.4KB -17.0B
visualizations 57.1KB 57.1KB -17.0B
total -67.0B
Unknown metric groups

API count

id before after diff
@kbn/core-saved-objects-api-server 338 336 -2

ESLint disabled line counts

id before after diff
securitySolution 433 436 +3

Total ESLint disabled count

id before after diff
securitySolution 513 516 +3

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @afharo

Copy link
Contributor

@tonyghiani tonyghiani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Infra UI changes LGTM.

Copy link
Contributor

@jloleysens jloleysens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I read through core-only changes and they look good to me. Great job @afharo !

I am glad to see we are reducing API surface area, but I do wonder whether removal of this option has any performance impact on either server or browser? I don't have data to think there is an issue but I can imagine that if we are now returning an array of really large objects there could be an issue.

Otherwise, approving to unblock progress!

@@ -43,7 +43,6 @@ async function checkOrigin(
rootSearchFields: ['_id', 'originId'],
page: 1,
perPage: 1, // we only need one result for now
fields: ['title'], // we don't actually need the object's title, we just specify one field so we don't fetch *all* fields
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps an option to return just "meta" fields like ID, createdAt, updatedAt?

Copy link
Contributor

@juliaElastic juliaElastic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fleet change LGTM, though I have the same concern related to performance. Is there an alternative we could use to avoid returning all fields?

@afharo
Copy link
Member Author

afharo commented Mar 27, 2023

@sqren @juliaElastic @shahzad31, the main reason for this change is that, in the scope of ZDT migrations, Kibana might run when migrations have not been applied yet. In that phase, we might apply the migrations at runtime. Fetching a partial document from ES before being migrated won't ensure the requested fields exist.

Having said that, we are looking at an alternative option: during the transition, internally fetch the entire document from ES, apply the migration, and lodash.pick the fields. I've created #153766 to track this effort. I'll close this PR in the meanwhile 😇

We might need some help from your end, though: given we are using these filters for performance purposes, we'd like to know the performance gain. It'd be great if we had some scalability tests for the tasks you want to optimize.

@afharo afharo closed this Mar 27, 2023
@afharo afharo deleted the sor/remove-fields-API branch October 1, 2024 08:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:Saved Objects release_note:skip Skip the PR/issue when compiling release notes Team:APM All issues that need APM UI Team support Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Team:Fleet Team label for Observability Data Collection Fleet team Team:Uptime - DEPRECATED Synthetics & RUM sub-team of Application Observability
Projects
None yet
Development

Successfully merging this pull request may close these issues.

SOR: remove fields option from the find API