This Essbase discussion board is provided as a free service and dedicated to all the Essbase professionals out there!
 Return to Index  

Re: Pros and Cons of 1 cube vs. many

January 27 2016 at 4:57 PM
No score for this post
Anonymous 
from IP address 180.94.112.70


Response to Pros and Cons of 1 cube vs. many

Multiple cubes versus a single master cube

Multiple cubes
Main advantages:
- Reduce cluster and dimensional irrelavance
- Faster (though with a bigger impact in BSO cubes)
- Generally easier to build reports from

Main Disadvantages
- Increased maintenance
- Bringing data inbetween cubes has a performance hit (and is required to keep all the data up to date)
- Training and change impact to teach users what they all do


Single cube
Main advantages:
- Data is all in one spot
- Users have a single cube to report from, easier to train
- One spot to maintain metadata (particularly scenarios etc)
- Decreased maintenance

Main Disadvantages
- Lots of dimensional irrelavance can make it 'tricky' to find data
- This generally requires the developers to be very careful with consolidation operators to make sure users aren't seeing weird things like KPIs consolidating into the balance sheet
- Performance impacts (even in ASO, defining aggregate views is generally less efficient)
- Can be confusing for ad hoc reporting


Because I live in the BSO world most of the time I'm much more of the 'split cubes up for functionality'. Once you've got a layer of complexity in business function, writing the code can be tricky enough without having multiple dimensions to play in. And in BSO, adding dimensions generally starts creating a performance overhead that is problematic.

However, with the big push of the cloud (and aa requirement to effectively squeeze a lot of functionality into 3 BSO cubes) we're seeeing a lot more consolidation. Fortuantly the advent of Hybrid has made a lot of those performance downsides significantly easier to manage. Obviously in an ASO layer you're going to get away with much more in the way of dimensional depth and pure dimension count.

So yeah. It's really a case by case basis. Important things to consider:
- Complexity of business requirements
- knowledge and availability of the business to support a more complex implementation
- Performance requirements

 
Scoring disabled. You must be logged in to score posts.Respond to this message   
Responses

  1. Don't know why my name is disappearing - Pete on Jan 27, 2016, 4:58 PM
  2.  
  3. +1 to Pete - er@essbase.ru on Jan 28, 2016, 2:34 AM
    1. Re: There is only one thread which writes to page index files per given ESSBASE process - Network54newbie on Feb 5, 2016, 3:43 PM
     
  4. Read Martin Neuliep's chapter on Essbase design - Cameron Lackpour on Jan 28, 2016, 9:04 AM
    1. Typo - Jeff McAhren on Jan 28, 2016, 9:12 AM
      1. Nope, not a typo - Cameron Lackpour on Jan 28, 2016, 9:24 AM
        1. It can be worse: make it unicode - Mike Henderson on Feb 5, 2016, 5:58 PM
          1. That must be...impossible? - Pete on Feb 5, 2016, 10:43 PM
            1. Unpossible, surely - Cameron Lackpour on Feb 6, 2016, 1:34 AM
              1. It's a killer feature - Pete on Feb 6, 2016, 4:05 PM
          2. Unicode makes it case sensitive? Are you sure about that? - Cameron Lackpour on Feb 6, 2016, 1:15 AM
            1. Correction: Unicode != Case Sensitive - Mike Henderson on Feb 6, 2016, 5:24 PM
     

RSS feed for this forum - http://www.network54.com/Forum/58296?xml=rss. Please email hypess (at) gmail.com, if you have any questions/feedback/issues.