Make dashboards load faster
Are you troubled by the long wait every time you open your dashboard? Have you ever encountered that when you have added many charts and are about to show them to other friends, you have to wait for the query results of the charts? Here are some ways to improve the speed at which your dashboard loads and your charts are displayed faster.
Using "stored queries" with cached query results
If your dashboard does not require high real-time performance of the chart-dependent data (there is a certain interval between data generation and use), you can configure the query statement of the chart as a stored query and set a reasonable execution plan to speed up the display of the dashboard. speed and efficiency.
When the user uses a pre-stored query with cached query results, since there is a cached result set obtained by pre-execution, it can avoid making real-time queries during use, so that the query results can be obtained faster and returned to the dashboard for display.
In the dialog box for creating a new chart or editing a chart query, you can select the desired stored query in the saved query drop-down menu:
For information on how to create and use pre-stored queries, please refer here - Introduction to the pre-stored query function
（https://yanhuang.yuque.com/staff-sbytbc/rb5rur/ugyw16?）。
Use "Materialized Views"
The materialized view stores the SQL precomputed result data set. Because the data is precomputed, querying the materialized view is faster than querying the base table. When queries are run frequently or are complex enough, this performance difference can be significant.
So if your dashboard needs to be opened frequently or the query conditions are complex, try using materialized views to speed up the loading of your dashboard.
For example, create a materialized view CREATE MATERIALIZED VIEW my_view AS ( SELECT item, order_time FROM sales WHERE name = 'Big Data' )
The results of the materialized view can then be used in the query statement of the chart to speed up the query SELECT * FROM my_view
Reference material - Introduction to materialized view functions
（https://yanhuang.yuque.com/staff-sbytbc/rb5rur/ugyw16?）
Using "Basic Query" inside the dashboard
You may consider using basic queries to optimize your dashboard when:
-
Some of the query steps for multiple charts in the dashboard are the same or similar.
-
Multiple charts in the dashboard query the same data, but have different configuration options for the charts. For example, different chart types, different titles, chart colors, etc.
For example, in a dashboard displaying sales data, there are several charts that query sales data for a certain year, but with different filter conditions. The charts respectively display sales data from different regions. In this case, when some charts use the same query results or similar query results, we can prioritize the "basic query" of the dashboard to optimize the dashboard charts. Inquired.
Different charts can reference the result set of the same basic query for display. Since the query tasks are optimized and the number of query tasks in the dashboard is greatly reduced, the effect of accelerating the dashboard is achieved.
You can easily create and manage your dashboard "basic query" through the UI interface in the dashboard, and it is also easy to reference the result set of the basic query in your chart query statement. References - Dashboard Basic Query
（https://yanhuang.yuque.com/staff-sbytbc/rb5rur/hqnyn6hz86g6afic）
For example, create a basic query named base_search_1, and then set the chart query statement in two different charts as
select * from $base_search_1$
select * from $base_search_1$ where _source like '%/opt%'
If the chart type is set to table, you can get the chart as shown below:
The two charts in the example above refer to the basic query base_search_1, which reduces the number of query tasks on the dashboard and optimizes the query speed.
Make dashboard input tags more flexible to use
The platform provides rich dashboard input tag functions: you can use text type input tags in queries, and the tag name syntax is $...$ delimiter. For example, if you define the query field input tag as "field", the query statement is SELECT $field$ FROM mySource.
In addition to text input tags, the platform also provides selector type and time type input tags. For the concepts and basic usage of input tags, you can refer to the documentation and user manual.
The following will expand and introduce some more advanced input tag usage scenarios to make your dashboard simpler and more flexible.
Option to dynamically filter query input tags
When you use "extract from query" to generate your markup options, do you want your query to change dynamically?
Take the following scenario as an example: the selector type input of the dashboard returns the value of the field country through the query statement select distinct country from cities_csv, but some place name options need to be filtered out, which means that the query statement of the input tag needs to be additionally adjusted. At this time, you can use other tags in the marked query statement to control the query return results. For example, add the filter condition where country != '$fieldToken$'.
In this way, by referencing other input tags in the query input tag, the effect of dynamically controlling the return value of the tag and adjusting the tag options is achieved. Next, you can select dynamically adjusted mark options in your dashboard to achieve a richer chart display.
Let’s take a look at the specific steps:
1. Create a selector type input tag fieldToken and add two example options RU and GL
2. Next apply the tag created above to the input tag of the query type, for example, create a selector input that extracts results from the query. select distinct country from cities_csv where country != '$fieldToken$'
3. Then you can control the return value of searchToken through fieldToken. For example, in the figure below, the options 'GL' or 'RU' are filtered out
Control the query time range of input tags
In addition to query statements that filter input tags in the above scenarios, the platform also provides some methods for controlling the query time range:
1. The time type input tag can be used to control the query time range of the chart, for example
2. You can also apply input (text or selector type) tags as query time range variables in query statements with input tags, for example:
Create a selector type tag searchRange
select _time, headers, content from _audit where _time > '$earlierTime$' and _time < '$latestTime$'
Among them, $earlierTime$ and $latestTime$ are two input tags, and the value option can be set to relative time or timestamp, such as 'now-4h', 'now-12h'. Then the query time range of searchRange is applied starting from 'last 12 hours' to 'last 4 hours'.
Use time type input tag directly in tag input of query selector type
The above introduces the method of querying using the time conditions _time > '$earlierTime$' and _time < '$latestTime$' in the query statement. You can also directly use the created time type tag as the query time range in the selection In the query marked by the type of device:
Share dashboards with other roles
After you create and edit a dashboard, do you also want to show your charts to other friends and share your dashboard with other role users in the platform?
If you need to access and continuously edit and improve a dashboard with other roles, you can give other roles higher permissions by editing the dashboard permissions. And when you don't want to expand the resources that the dashboard internally refers to to other users, and only want other role users to view the dashboard in 'read-only' mode, you can control access permissions by sharing the dashboard.
The following will introduce ways to share dashboards to meet your needs in different scenarios.
In the dashboard editing permissions, directly assign the dashboard and dependent resource permissions to the corresponding roles.
Chart queries in dashboards reference and depend on other object resources, such as datasets, views, table functions, etc. A list of resources is available in the dashboard permissions editing dialog, and a role can be given read-only access to all these dependent resources with one click.
Roles/users who have been granted permissions on dependent resources can access the dashboard and view all chart results.
So what needs to be reminded here is that these resources can be accessed not only in the instrument, but also in all functional pages of the Yanhuang Data Platform, such as alarms, queries, stored queries, lookup tables, table functions, etc.
Share dashboard
The above methods and scenarios for dashboard editing permissions are suitable for granting the resources that the dashboard and its internal charts depend on to a role in one go and in batches.
So here is a preview: In addition, we also provide another way to 'share the dashboard' to share the dashboard to the target role without worrying about any additional granting of resource permissions.
References - Share Dashboard
（https://yanhuang.yuque.com/staff-sbytbc/rb5rur/xfed6lyivz24dag2）