Evaluation of Jedox as a reporting system - compared to SSAS/Qlikview

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Evaluation of Jedox as a reporting system - compared to SSAS/Qlikview

    Hello,
    I hope somebody can give me an advice. My company plans to replace the old BI system (Hyperion Interactive Reporting) with an up-to-date BI system.
    The requirements are actually focusing on reporting and NOT planning. However, as I consider it as important to have a tool to collect information and as nobody can tell me that one day integrated planning becomes an option as well, I decided to have a look at solutions like the Jedox Suite as well.

    Currently I'm developing prototypes with different BI demo versions. SSAS is the perfect solution for us from a performance and ad-hoc reporting perspective but standard reporting is cumbersome (and quite limited) and as already mentioned it would not be a disadvantage to have a write back function to collect data from subsidiaries etc..

    The only concern I have with Jedox is the Performance. I know it's now in the BARC survey because of its agility and performance but of course it's difficult to compare it with Qlikview or SSAS.

    The first part of the implemenation would be the "Sales" part which has the following technical key requirements:
    - One dimension with 800,000 elements
    - Another dimension with 500,000 elements
    - Another dimension with 1,000,000 elements (flat hierarchy - only one parent and one attribute)
    - In total 7 dimensions
    - About 2,500,000 facts (you see, the main part of the cube is empty)
    - 100 Users (50 concurrent I assume)
    - It must be possible to navigate to specific bottom level elements in standard and ad-hoc reports (with a search function (without having to drill down along the endless hierarchy))

    So my quesiton(s) is/are:
    Do you consider it as realistic that Jedox can be used as a reporting system for such kind of requirement without handicaps?
    Does anyone have experiences with such big dimensions in Jedox/Palo?

    (I wanted to test it already but no luck --> on our BI test server the ETL manager stopped processing the dimension load process because of a tomcat memory issue ("gc overhead limit exceeded") and adjustments in setenv.bat did not help --> I feared something like this will happen:-().

    I would be happy to receive your feedback.

    Thanks
    Andreas
  • Hi Andreas,

    that are rather high figures for sure...

    Can you post the list of the dimensions that you would have in this case ?

    the question to ask is actually : do you really need such detail or are there dimensions that could be agregated before the load ? You could treat part of the information as Drillthrough and thus not in the dimensions.

    Cheers,
    laloune

    Post hoc, non est propter hoc
  • Hi,

    Thanks for your response.
    Dimensions are:
    1. Time
    2. Article
    3. Customer
    4. Entity
    5. Order
    6. Sales person
    7. Measure

    Theoretically it would be possible to use drillthrough to get to the order details (order numbers) but the article and customer dimensions are that big as well and not having the order details would make some ad hoc queries a bit more cumbersome.

    In the SSAS prototype I created it works perfectly with a fantastic performance (without latency).

    The cube would not have many rule-calculated items and considering this fact I expect that it will work somehow. Unfortunately I could only test it with a "subset" of metadata due to the memory issue I had when trying to load the entire dimension. Consequently I am not sure yet how much memory usage the "finished" cube will have and how fast it will be to get to the information requested. I'm sure the fact data will not be a big issue, the main issue will most probably be the long list of elements within the dimensions. It's very important that in case of low level analysis users are able to navigate to specific elements (articles, customers etc.) and then probably drill through to order details.

    I'm sure for pure reporting there are better solutions than Jedox but I really like the standard reporting including the write back possibilities so I would really like Jedox to be capable of handling that metadata size in a good way. But as mentioned, not sure yet if somebody has made good experiences with that or not.

    Regards
    Andreas
  • Hello Andreas,

    ok that is a rather classical modelling actually. More questions:

    - how much RAM do you have on your server ?
    - how big is the sparsity in the cube ? I mean, would you have the possibility so split the dimensions ? Are there articles that will not be sold to any customers, or article number that only correspond to one entity (as it is rather oftenly in ERP systems that functions with a mandant logic)

    cheers,
    laloune

    Post hoc, non est propter hoc