• In the retail industry, monitoring daily reports for each store may be accessed by thousands of users, with different row-level permissions, and there may be high concurrency around 8 a.m.
• In e-commerce event scenarios, a large number of users may access the same dashboard simultaneously within a specified period, and each user has different data permissions.

2.1 Data preparation #

(1) Since this is a relatively fixed monitoring scenario and requires high concurrency, it is recommended to aggregate metrics in advance. You can preprocess the ads layer tables in the data warehouse and then extract them into the BI platform, or use the product's Visual Modeling to build the result data, so that the dashboard/visual query function directly queries the result data. Try to avoid aggregating from detailed data directly through visual queries, as performance will be significantly affected under high concurrency.
(2) Configure primary keys for the fields used in filter conditions to improve query performance.

(3) The business may require viewing a large amount of data, and it may also be necessary to analyze and break down problems based on abnormal metrics. Since human attention is limited, a better approach is a summary-detail structure. The core is a monitoring daily report that presents the most critical data. When data in certain business domains appears abnormal, users can navigate to a detailed page to view more dimensions and more detailed data. Instead of dumping all the data on users at once.

(4) It is recommended to control the number of charts in the core report. More data is not always better; instead, focus on essential data that users need to see.
(5) If there are tables, please add pagination, as users cannot view many rows at once.
(6) It is recommended to limit the number of data items displayed on each chart to ensure readability.
(7) Try to keep the query time for charts in the core report within 1 second.