Will Oracle OLAP handle our case(s).

Question

We are about to build a cube to roughly handle following dimensions and facts:
15 dimensions ranging from a couple of members to 40,000+ members.
A fact table holding 200,000,000+ rows
So my question is: Does anybody has a sense of whether OLAP has a chance of handling this data? We are pretty certain that the data will be sparse.
A second item relates to whether Oracle OLAP cubes give us the ability to compute what we refer to as "Industry" data. We serve a number of companies and we compute metrics that applies to their data. In order to allow these companies to see what they are doing against the other companies we provide the metrics for every other company; this metrics are considered Industry. So my question is: Do OLAP cubes have any structure or mechanism that allows to compute these metrics within the same cube or do we have to create a cube to hold Industry metrics?
Thanks,
Thomas

Answer 1

Thomas,
I cannot advise you for or against based on the small amount of information I have. I will not deny that at 15 dimensions you are at the upper limit of what you can achieve using the current (11.1) OLAP technology, but I have seen cubes of this size built and queried, so I know it is possible.
The answer would depend on many things: hardware, query tools, expectations for query and build performance, and whether you have a viable alternative technology (which will determine how hard you will work to get past problems). It even depends on your project time frames, since release 11.2 is currently in beta and will, we hope, handle greater volumes of data than 11.1 or 10g.
One important factor is how you partition your cube. At what level do you load the data (e.g. DAY or WEEK)? What is your partition level (e.g. MONTH or QUARTER)? A partition that loads, say, 10 million rows, is going to be much easier to build than a partition with 50 million rows. To decide this you need to know where your users will typically issue queries, since queries that cross partitions (e.g. ask for data at the YEAR level but are partitioned by WEEK) are significantly slower than those that do not cross partitions (e.g. ask for data at WEEK when you are partitioned by MONTH).
Cube-based MVs can offer advantages for cubes of this size even if you define a single, 15-dimensional, cube. One nice trick is to only aggregate the cube up to the partition level. Suppose, for example, that you load data at the DAY level and partition by QUARTER. Then you would make QUARTER be the top level in you dimension instead of YEAR or ALL_YEARS. The trick is to make YEAR be an ordinary attribute of QUARTER so that it appears in the GROUP BY clause of the cube MV. Queries that ask for YEAR will still rewrite against the cube, but the QUARTERS will be summed up to YEAR using standard SQL. The result will generally be faster than asking the cube to do the same calculation. This technique allows you to lower your partition level (so that there are fewer rows per partition) without sacrificing on query performance.
Cube-based MVs also allow you to raise the lowest level of any dimension (to PRODUCT_TYPE instead of PRODUCT_SKU say). Queries that go against the upper levels (PRODUCT_TYPE and above) will rewrite against the cube, and those that go against the detail level (PRODUCT_SKU) will go direct to the base tables. This compromise is worth making if your users only rarely query against the detail level and are willing to accept slower response times when they do. It can reduce the size of the cube considerably and is definitely worth considering.
David