How is caching different and/or improved in MicroStrategy 7.0?
The MicroStrategy 7.0 architecture offers greatly improved caching support with respect to administration, security, prompting and subsetting.
There are three types of requests for which MicroStrategy 7.0 uses caching to improve response times:
- Metadata object requests. Frequently used metadata objects (i.e., templates, filters, reports, metrics, custom groups, consolidations, attributes, etc.) are stored in memory, in addition to the metadata repository, so they can be retrieved more quickly.
- Lookup table element requests. Frequently used lookup table elements are stored in memory, in addition to the warehouse database, so they can be retrieved more quickly.
- Report execution requests. Pre-calculated and pre-processed report results are stored in memory, and on disk, so they can be retrieved more quickly than re-executing the request against the warehouse database.
Space limits for caching are created when a project is initialized. In two-tier mode, an object and element cache exists in memory on the client for each project that the client accesses. In three-tier mode, for each project an object, element and report cache exists on the server (in memory for all and also on disk for report requests), and only an object and element cache exists in memory on the client. MicroStrategy 7.0 also provides strong cache administration functionality, including cache backup, cache loading and/or unloading from memory, cache updating, cache expiration, cache invalidation, and cache status.
Cache retrieval is affected by multidimensional security. Multidimensional security (also knows as the security filter) is the feature set that allows a data filter to be assigned to a project-user combination. Whenever a user runs any report within a given project, the security filter is applied to the underlying query. When a report request hits a report cache, the cache-matching algorithm accounts for the user of security filters.
Caching has also been improved to support prompts. When a report is cached, it is indexed by the answers to the prompts used for the report. In order to retrieve results from the cache, a report request must include the exact same prompt answers as the execution that created the cache. When using server caching, the user is prompted for prompt answers before the cache-matching algorithm checks for a cache match. A common usage scenario is to be able to have a prompted report use the cache, regardless of what the user requests.
What types of flat files does the report cache on the MicroStrategy Intelligence Server 7.0 create? Are they accessible from other tools?
Report caches stored on disk on the MicroStrategy Intelligence Server 7.0 are in a preprocessed, proprietary format. Therefore, they are not accessible by means other than the MicroStrategy COM API. Datamarting is implemented in MicroStrategy Intelligence Server 7.1 to address this requirement. Element and Metadata Object caches only exist in memory and are not stored on disk, unlike Report caches.
Can a SQL generation request be cached?
Yes, a SQL generation request can be cached. The next time the same report is run, the SQL is retrieved from the cache instead of being generate at the runtime.
Is there a setting that can control the client side cache?
There are no exposed settings regarding the client side cache.
Is there an expiration time for the different caches?
For the report cache default, the expiration time is 24 hours, but it is configurable up to 999,999 hours. For element cache and object cache there is no expiration time setting. The only ways of removing them are either purging the caches from the project configuration or restarting the MicroStrategy Intelligence Server.
Will Cache files be created when Caching is turned off at the Project Configuration?
If the History List (Inbox) is enabled, cache files will still be created.
No comments:
Post a Comment