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

[8.0 Research] Expression Caching / User-defined Expressions #88790

Closed
clintandrewhall opened this issue Jan 20, 2021 · 4 comments
Closed

[8.0 Research] Expression Caching / User-defined Expressions #88790

clintandrewhall opened this issue Jan 20, 2021 · 4 comments
Assignees
Labels
Breaking Change Feature:Canvas Feature:ExpressionLanguage Interpreter expression language (aka canvas pipeline) R&D Research and development ticket (not meant to produce code, but to make a decision) Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas

Comments

@clintandrewhall
Copy link
Contributor

clintandrewhall commented Jan 20, 2021

Summary of Exploration or Proposed Change

Problems to solve

  1. When loading a workpad, you get a bunch of blank loading elements while waiting for the batched requests to finish (no progressive loading or caching — even in app navigation causes elements to reload)
  2. Lots of elements used similar or the same starting queries. This means there's a lot of repetition across elements and also the same query will get run multiple times on the server. That's a lot of waste. People have asked in the past about using variables for expressions, hoping the result gets cached

Duplicate expressions-- or portions thereof-- are common in Canvas. This project has several parts:

Allowing someone to save any expression as a new, user-defined expression.

For example, given this expression:

filters
| demodata
| pointseries x="time" y="mean(price)"
| plot defaultStyle={seriesStyle lines="2" fill=1 bars="0" points="1"
  palette={palette "#1ea593" "#2b70f7" "#ce0060" "#38007e" "#fca5d3" "#f37020" "#e49e29" "#b0916f" "#7b000b" "#34130c" gradient=false} 
  font={font family="'Open Sans', Helvetica, Arial, sans-serif" size=16 align="left" color="#FFFFFF" weight="normal" underline=false italic=false}
| render containerStyle={containerStyle backgroundColor="rgba(255,255,255,0)"}"

someone could save portions as new expressions:

user:my_palette = palette "#1ea593" "#2b70f7" "#ce0060" "#38007e" "#fca5d3" "#f37020" "#e49e29" "#b0916f" "#7b000b" "#34130c" gradient=false
user:my_series = seriesStyle lines="2" fill=1 bars="0" points="1" palette={user:my_palette} 
user:my_font = font family="'Open Sans', Helvetica, Arial, sans-serif" size=16 align="left" color="#FFFFFF" weight="normal" underline=false italic=false
user:my_container = containerStyle backgroundColor="rgba(255,255,255,0)"

and then revise the original expression:

filters
| demodata
| pointseries x="time" y="mean(price)"
| plot defaultStyle={user:my_series} 
  font={user:my_font}
| render containerStyle={user:my_container}

While we may be able to do this today with variables, providing users or solutions (e.g. Canvas) to manage global expressions would be ideal.

Caching Expressions and Expression Results

We've often discussed caching expressions and expression results. Canvas could find a way to cache duplicate expressions as workpad variables and/or Expressions could provide a means of doing this automatically. We should find the balance of effort and target 8.0 for either or some combination.

Dependencies or Impact

  • Schema updates ([8.0 Research] Workpad Schema Updates #88789): if we go with variables, we need to account for them inline. If we have global expressions, they need to be embedded in the workpad export and linked in the saved object.

Findings

Caching Expressions and Expression Results

After discussion with expressions working group, it sounds like we'll want to handle caching at the search session level. I don't see caching on the search session roadmap so I'll need to follow-up and see if there's an issue for that already.

Moving to the search session service seems to be the right move, however, for a few reasons. First, moving to the search service (even without using a search session) will move us off of the legacy elasticsearch client which is important since it's being removed soon. Second, moving to search sessions could bring us some performance gains by restoring a session when we navigate to a workpad. This would mean we wouldn't necessarily have to reload a workpad every time the page is visited. I think we might have to wait until #85126 is implemented but I'll confirm and update at a later date. Finally, we could likely remove the data source functions (essql, esdocs, etc) from the server in their batched processing route. I'm getting confirmation on how it works exactly but it seems like calling the search service on the front-end applies a similar batching strategy. From what I understand, dashboard is already doing this and I think Canvas is a very similar use case.

There is a long issue on the history of Canvas querying on server vs client here: #29118 After reading through, the tl;dr seems to be that the functions were moved to the server with the batch route because 1. we needed to get off of web sockets and 2. elasticsearch-client was being deprecated. Using the search service, I don't think there will be any problems with running the expressions on the client. The requests are basically going to get batched in a similar way, Canvas just won't have to deal with.

This does NOT appear to be a 8.0 breaking change. (But will likely require enhancements/help from other teams)

Allowing someone to save any expression as a new, user-defined expression

I haven't had as much time as I would like to dive into this.

It seems like that this is something we'd want to move outside of just Canvas since other applications may want to eventually use expressions. Saved objects can already reference other saved objects so workpads could be given a new record in their schema that references used expressions.

This could also be an area of cooperation with the Lens folks since at some point they might be considering using user-defined expressions. We could have a really slick unified/shared experience for editing and/or viewing the expressions you want to use.

I think there are some tricky implementation details to still work out (like, I'd imagine you'd want to refer to the used-saved expression in an element expression but you need to likely keep track of the referenced user-saved expressions separately in the saved object structure so that the workpad could get exported properly with its referenced expressions) but since this would be a schema addition, I don't think this would be a breaking change for users.

This does NOT appear to be a 8.0 breaking change.

NEW: using web worker for searching

I haven't done any research here, personally. I checked search session roadmap but there's nothing about web workers. I'll need to follow up with that team

  • Proposed Priority: High for search session, Medium for user-defined expression, ??? for web worker for searching
  • Level of Effort: It's complicated (Search service could be implemented without search session so that seems like the start)
  • Dependencies (if any):
    • Expressions
    • A few search service improvements/changes noted above
  • Proposed development: [7.x]
@clintandrewhall clintandrewhall added Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas R&D Research and development ticket (not meant to produce code, but to make a decision) Feature:Canvas Breaking Change 8.0.0 labels Jan 20, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-presentation (Team:Presentation)

@poffdeluxe
Copy link
Contributor

After some discussions in the Expression working group meeting, it seems like expression caching won't be adopted and instead app services is working on caching request through the new search session work (TODO: compile the search session examples/docs). We will have to figure out how to make search sessions be compatible with ES SQL but sounds like there are search strategies you can implement.

Discussion around user-defined expressions sounds like ideally we would love for a kibana-wide library of expressions. We'll need to look further into this but it seems like the right direction is a new saved object type for expressions. That way, other saved objects can express dependencies on the saved object expression so they'll get bundled together.

Couple of concerns off the top of my head:

  • Lens specific expressions vs Canvas specific expressions
  • Shared UI for building/exploring expressions in library

@poffdeluxe
Copy link
Contributor

poffdeluxe commented Feb 22, 2021

Also, I'm thinking we might want to break out the "user-defined expressions" and "expression caching" stuff into separate issues as they do not seem to be related any longer

@ThomThomson
Copy link
Contributor

Closing this in favour of the expression-side performance improvements which have been made.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking Change Feature:Canvas Feature:ExpressionLanguage Interpreter expression language (aka canvas pipeline) R&D Research and development ticket (not meant to produce code, but to make a decision) Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas
Projects
None yet
Development

No branches or pull requests

6 participants