How to measure performance in HourGlass Model and Modified HourGlass Model

Question

Hello All,
I'm trying to understand as to how the HourGlass Model (which says that the outline should be designed as Dimension tagged as Account, Dimension tagged as Time, Dense Dimensions from most dense to least dense, Sparse Dimensions from least sparse to most sparse) exactly works in terms of optimizing performance and aggregation.
Also I want to understand the working of the new Modified HourGlass Model on Stick (which says that the outline should be designed as Dimension tagged as Account, Dimension tagged as Time, Dense Dimensions from most dense to least dense, Aggregating Sparse Dimensions from least sparse to most sparse, Non Aggregating Sparse Dimensions).
Why are these approaches better and how do they work internally in the system?
How exactly does it pick up combinations during calculations and aggregations?
In some documents I learned that we should keep the Time dimension as the first dimension in the outline since it is dense and there are more chances of having similar kind of data values across the same fiscal year, due to which compression takes place efficiently. So if this is the case doesn’t it conflict with the HourGlass model and at such times which model to go with?
Thank You,
MM

Answer 1

Hi Damian,
Here are a few more general tips for query performance:
1) Always gather statistics for the query optimizer. In addition, we usually see better performance with column group statistics for PS and PC column groups.
exec sem_apis.analyze_model('my_model',METHOD_OPT =>'FOR COLUMNS (P_VALUE_ID, CANON_END_NODE_ID) SIZE AUTO',DEGREE=>4);
exec sem_apis.analyze_model('my_model',METHOD_OPT =>'FOR COLUMNS (P_VALUE_ID, START_NODE_ID) SIZE AUTO',DEGREE=>4);
exec sem_perf.gather_stats(just_on_values_table=>true,degree=>4);
Note: the DEGREE argument is for degree of parallelism
Usually, you would load data, then gather statistics, and then periodically re-gather them as updates are done (maybe when 20% of the data is new).
2) Create appropriate semantic network indexes. We generally recommend PCSM and PSCM indexes. PCSM is always there, and PSCM is created by default in the latest patch but not in 11.2.0.1.0 release (11.2.0.1.0 has a PSCF index that should be dropped and replaced with PSCM).
Both of these items are covered in the documentation.
You may also find the following presentation from SemTech 2010 helpful. It covers many best practices for load, query and inference.
http://download.oracle.com/otndocs/tech/semantic_web/pdf/2010_ora_semtech_wkshp.pdf
Thanks,
Matt