Shulou(Shulou.com)06/01 Report--

What is the controllable cache of report data? in order to solve this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and easy way.

It is a consensus that caching can improve report performance. Generally, high-end report tools provide report caching to cache the entire report calculation results in the file system, so that users can quickly read and display the cached results the next time they visit a report with the same parameters. Moisturizing report, as the leading brand of reporting tools, certainly has this conventional caching function.

However, in some cases, report developers also want to further control the cached content, for example, for cached content, they may only want to cache part of the report results rather than the entire report results, or be able to have other reports or programs reuse the cached content. for example, for timeout settings, you may want to set different timeouts for different cached results. These requirements come from the actual business needs to deal with the amount of data and real-time aspects of the different situations, but also the general report tool caching function can not meet.

The dry report has a built-in programmable data calculation engine (implemented in combination with the aggregator), which allows developers to flexibly control the content of the cache, which is called controllable cache. Controllable caching can bring more flexibility, so let's introduce the three points mentioned above.

1. Cache some of the results

In report development, it is sometimes not desirable to cache all report results to avoid excessive cache costs (disk space and application server resource overhead). In addition, when part of the data in the report requires high real-time performance and needs to interact with the database for data query in real time, then it is not suitable for caching. In this case, intermediate results that change less frequently can be cached by drying the controllable cache of the report. When the report is requested again, the data with high real-time requirements is still read from the database, and the report is calculated with the non-real-time data in the cache to get the final report result set. The conventional caching scheme does not have the function of caching part of the results, so we can only set whether the whole report is cached or not, so that the report must balance the contradiction between the two when it comes to the different timeliness of the data, and drying the report is obviously more flexible and efficient in this respect.

2. Reuse of cache results

The controllable cache in a dry report can be reused, and the cached results of a report (some or all) can be read and used by other reports or programs, without having to cache the same results repeatedly as a regular report caching scheme. this will obviously greatly improve the overall efficiency of caching. When other reports or programs use the cached results of a report, you only need to read from the cache (usually a disk file) and mix with other data sources in the report (which may be DB, files, or the cache of another report) to get the result set that the report needs, similar to the way you cache some of the results. Conventional report caches are cached in terms of report templates, which can not be reused, which will result in considerable waste of resources and increase a lot of performance overhead, while drying reports also reflects flexibility and efficiency in this respect.

3. Set different timeout

There must be a timeout in the caching mechanism, the outdated cache will be cleared, and the report will be re-cached when the report is reaccessed. The cache timeout of general report tools is set in configuration files, such as 3600s or 7200s, which often works on all parameters of a single report, and sometimes even on all reports. In other words, the entire report and even the entire system must use the same settings.

This approach obviously does not perform well, and it will be more effective if you can set different timeouts for different report scenarios. For example, for reports that query a large number of historical data, because the historical data generally do not change, we hope that the cached results of the report can be preserved for a long time and set a longer timeout period accordingly; while for the data changes frequently, reports with higher real-time requirements set a shorter timeout period in order to meet the real-time requirements of the data.

The result cache that dries up the report allows developers to set different timeouts for different reports to cope with different report scenarios. This approach also provides greater flexibility, making report caching truly controllable.

Give an example

For the specific implementation of the controllable cache, please refer to the relevant documentation of the drying report. Here is a simple example to illustrate the use of the result cache:

First, use the built-in aggregator to generate and read the cache file, which is in the calculation stage of the report data source.

ABC1E:\ work\ esProc\ / cache directory

2 = "sales_" + string (d_date) / cache file name, report name + parameter (dfxName_ParamName)

3=file (A1+A2)

4if A3.exists () & interval@s (A3.date (), now ()) A5.close ()

8=A3.export@b (A7) / generate cache file

9return A7 / returns the result set for the report

The above script first specifies the cache directory, sets the cache file name according to the parameter, and then looks up whether the cache file exists based on the file name (A4). If it exists and does not time out, the cache is read directly, otherwise, the database fetch operation is directly connected, and the calculation result is generated into a cache file.

By contrast, if caching is not used in the report, the script only needs to be written like this:

AB1=connect ("demo")

2=A1.cursor ("SELECT customer ID,sum (unit price * quantity) total order FROM order, order detail WHERE order. Order ID= order detail. Order ID and year (order date) >? group by customer ID order by order Total desc", d_date)

3=A2.fetch (5) > A1.close () 4return A3

Then, you only need to call the above aggregate script in the dry report and edit the report expression to complete the report.

It should be noted that the controllable cache for drying reports also has its own scenarios and can not completely replace the regular cache. The conventional caching method will be saved together with the report calculation results and rendering properties, but the controllable cache here only caches the data and has to perform appearance calculation again during presentation, so it is more suitable for scenarios with high data calculation intensity and low appearance calculation intensity. In practical application, the two can be used together.

The answer to the question about the controllable cache of report data is shared here. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.