Compressing requests in InfoCube
I recently had a discussion with my teamlead reagarding compression of requests in an infocube.
Currently all our requests are uncompressed, which is not the best for performance as we know
We have data of 2005 and 2006 in this specific cube, but have to do a lot of corrections in 2006. So we decided, just to compress the requests for 2005.
So if we compress just a certain number of requests in one cube, we will have a F-table and an E-Table.
Now we have doubts if this will result in better performance or if our performance will even get worse, because we have to read both tables every time.
Data is loaded daily
Message was edited by: Torsten
Sumana P replied
I assume that you understand the concept behind compression. Each Data load process in an InfoCube is uniquely identified using a request ID.
Using request ID's can have the effect that a data record with the same content (where all characters are the same except for the request ID) appears more than once in the fact table. The result is an unnecessary increase in the data volume, which reduces performance in Reporting, since every time a query is executed, the system accesses data via the request ID.
During compression, the compressed data records are moved from F fact table to E fact Table. And new records are stored in teh F- fact table.
In standard practice, you need to leave some requests uncompressed. Because, once the data is compressed, it can no longer be deleted from the InfoCube using request IDs.
Compared to your previous design of not compressing any request ID's, your present design wuld definitely increase the performance of the system. Once you are sure that the data requests for 2006 have no inconsistent data, you can compress those request id's too. So, don't worry, your performance will not be hampered by compressing some requests and leaving some requests uncompressed. This is the normal practice we have been doing with all our data requests.
Hope this helps.