InfoCube信息立方體的優化

• 顆粒度儘可能大：儘可能不要在Cube裏放太明細的數據（即維度字段越小越好），這種需求首先考慮R3用ABAP解決，若是非要在BW，能夠考慮在DSO出明細報表，在Cube出彙總報表，經過RRI接口調用明細報表。
• 拆分多個：當Cube的數據量很大時，能夠拆分紅多個Cube,再用MultiProvider拼起來，這樣query會在N個Cube中並行，提升效率。這就是所謂的邏輯分區。常見的分區方式有按年月，按國家，按BU，按類型等。
• 壓縮：給Cube作Compression。Compression 本質上是去掉Data Dimension，這樣fact table就被壓縮了，可是request id也消失了，將沒法經過request id去管理數據（慎用，最好是半年甚至一年以上的數據）。
• 索引：數據庫的索引能夠加快查詢速度
• 分區：對於很大的Cube，能夠作partition,這是物理分區，只支持按時間分區。
• 彙集：使用Aggregation能夠提升性能。可是Aggregation自己是cube的一個子集，提升性能的同時也加大了數據冗餘，因此不要用太多。
• Staitics：按期刷新DB Statistics 能夠提升reporting的效率。
• 使用MP：維度設計上，避免不少數據量很大char.放在一個維度上（多對多的不要放在一個維度裏），由於這樣會讓維度表變得很大。一般，儘量拆分紅更多的維度（不過維度太多會致使 fact table巨大，因此要作好平衡），而後在multiprovider 層面，把相關（指業務意義上的相關）的char都放一個維度裏，而後作好Mapping，這樣便可以讓用戶更容易理解MultiProvider，下層CUBE維度的從技術角度拆分與組合（按1:1或1:N的放在一塊兒的原則）提升了性能，一箭雙鵰。
• Line item Dimension：對於material等很大的主數據，使用Line item Dimension（即將M：N多對多的字段，讓他們一我的一個維度，這樣天然就成了行項目維度了，提升性能）.
• BIA:使用BIA是比Aggregation更有效的方法，就是要花很多錢。