Open surapuramakhil opened 2 months ago
I've always conjectured that this would be tied into the Global Async Queries feature. two main reasons: 1) It has a redis caching layer, so that might lighten the load on your DB in general. 2) If we want to do real realtime analytics, the dashboard would need a major overhaul so that (a) charts all subscribe to a websocket for updates, which would be published on query completion OR a push of subscribed streamed data, and (b) all charts should be updated so that they support transitioning/transposing on data uptates rather than just blinking a hard refresh.
Restricting scope of this SIP. Which are necessary and sufficient for this to work.
One dataset populates, the rest of the flow would remain the same. Chart queries will hit in-Memory dataset where underlying data lies.
@surapuramakhil please move forward with a [DISCUSS] thread on the dev mailing list if you wish to execute on it, otherwise this will be closed as discarded fairly soon. Pleae reach out if you'd like any assistance with that process.
@rusackas, I got busy. I will work back on this.
Please make sure you are familiar with the SIP process documented here. The SIP will be numbered by a committer upon acceptance.
[SIP] Proposal for ...
Motivation
Today, real-time dashboards are built on repeated polling of 10 seconds interval. For Every pool, SQL queries are executed, typically the entire data needed for dashboard would be fetched.
This causes a lot of load on warehouse DB - especially when you have the lot of active users on Superset and at the same time you have a lot of real time dashboards. This thing can be skipped entirely if your dashboards have low retention periods.
Proposed Change
Like, How SQL Lab performs SQL queries and generates dataset which are required to power dashboards. An alternate pipeline powered by steams would generate/update the datasets required for dashboards. Like SQL Lab, there will be another module where user can specify how a steam needs to be consumed (functions), and how those dataset needs to be updated.
New or Changed Public Interfaces
Describe any new additions to the model, views or
REST
endpoints. Describe any changes to existing visualizations, dashboards and React components. Describe changes that affect the Superset CLI and how the Superset is deployed.New dependencies
Describe any
npm
/PyPI
packages that are required. Are they actively maintained? What are their licenses?Migration Plan and Compatibility
Describe any database migrations that are necessary, or updates to stored URLs.
Rejected Alternatives
Describe alternative approaches that were considered and rejected.