If you are unable to create a new account, please email support@bspsoftware.com

 

News:

MetaManager - Administrative Tools for IBM Cognos
Pricing starting at $2,100
Download Now    Learn More

Main Menu

Cube limitations

Started by atoz, 09 Aug 2006 11:27:35 PM

Previous topic - Next topic

atoz

Hi All,

What is the max cube size for analyst and for contributor? Does it vary for version-wise?

Thnx.

andrewbho

The maximum cube size in Analyst is 25 million cells.  The maximum model size in Contributor depends on the amount of calcs, dlist, dimensions, etc.  Over the past 7 years, I don't think that I have seen a model larger than 17 million cells per eList slice.

The only difference over versions have been the number of Elist items allowed.  Analyst hasn't changed substantially over the years but Contributor has gone through a number of database upgrades.

Sandip

Wow 17 million !! I wish there was some way I could learn how to make a model so huge

The max limit that we reached here in contributor is 5.5million per elist size.

I hope you can respond back to this one.

Many thanks

Sandip

ykud

#3
Analyst -- the maximum I've seen is 120 mln cells. Could be opened only using some subselections, yet it worked, formulas were calculated etc. Extensive use of Slice Updates is needed when going after 30 mln cells limit.
Contributor -- I've made 9 mln per slice applications. But they were fiercly cut on No Data, with Cut-Downs, and small number of links (just intercompany flows were calculated). No Data, Cut Downs -- main recipe.

Yep, Analyst hadn't moved an inch(not counting new BIFs, cube comments, and overall bugs resolving) since Adaytum 2.3 (my first experience) and Contrbutor was significantly changed only recently, with introduction of Administration Links, executed on Job Clusters. They're really fast.  8)

andrewbho

There's no glory in large models/applications.  The last thing you want to hear is that the model is not Supported by Cognos.  If you want to be a stud, create an application that meets complex business requirements and is 500k cells or less, where jobs never cancel and users never complain about performance.  The application was developed to work in a certain way and people who deviate are only asking for heartache.

ykud

Quote from: CenterStone on 15 Nov 2006 09:11:33 PM
There's no glory in large models/applications.  The last thing you want to hear is that the model is not Supported by Cognos.  If you want to be a stud, create an application that meets complex business requirements and is 500k cells or less, where jobs never cancel and users never complain about performance.  The application was developed to work in a certain way and people who deviate are only asking for heartache.

Totally agree with that. But there's always a choice between size, simplicity (to develop and maintain), speed.
Taking intercompany flow, for example, -- it's a problem. Because you need 2 organization structure list in such cubes (seller/buyer) and the accounts, time,version -- that's a big cube. It's very sparse, in general, so can easily be maintained in Contrbutor, but getting it into Analyst rises a problem. Analyst is rather poor on sparsity handling, so you can either have a big pain-in-the-*ss cube, or a set of smaller cubes (for ex, you break it for months, to have 12 instead of 1) with  big pain-in-the-*ss support of rebuilding a set of links every time smth changes.

I've got no common solution in those cases, but out of "size,simplicity,speed", I choose "speed+simplicity" whereas possible, sometimes breaking the size recommendations (having 1 cube instead of 12). 

andrewbho

Void- check out kcicorp.com.  These guys have taken the same APL code and flipped it on its head. They did something with the calc engine and they can have cubes that are 10000x bigger than Analyst and you can open it all at the same time.  It's not as sexy but it works.  We had a very interesting conversation with product dev/mgmt a few months ago.

What most customers want is this huge grid just to enter and collect data in.  It's funny but most cusotmers could care less about BIFs, macros, etc.  Give them a huge customized grid with breakback that supports data entry and collection and the thing would sell.    Maybe I told you too much about my next project :)

ykud

Quote from: CenterStone on 16 Nov 2006 05:41:10 AM
Void- check out kcicorp.com.  These guys have taken the same APL code and flipped it on its head. They did something with the calc engine and they can have cubes that are 10000x bigger than Analyst and you can open it all at the same time.  It's not as sexy but it works.  We had a very interesting conversation with product dev/mgmt a few months ago.

What most customers want is this huge grid just to enter and collect data in.  It's funny but most cusotmers could care less about BIFs, macros, etc.  Give them a huge customized grid with breakback that supports data entry and collection and the thing would sell.    Maybe I told you too much about my next project :)

Spent some time on that site, found the words ROLAP and normalized data base storage and that was rather strange. Analyst is pure MOLAP, as far as I know, cause handling breack-backs in ROLAP is rather painful. Anyway, site is rather uninformative, so I'll try to schedule a demo or communicate with someone inside.

Customers mostly want excel with more cells and multiuser access, so new Office might be a serious threat to all niche players. Not mentioning coming PerformancePoint.
We're thinking of enlarging our product line (to gain some vendor independence), so I'm really interested in CPM market products. Have you tried Applix? It's reactively fast due to in-memory molap structure.

Sandip

Thats true we all know that a model will be considered good only if its modelled extremly well and consist of the complex portions of the business simplied by the consultant for the client. If making big models was the only criteria then i am sure there would have been a lot more cognos specialist.. Anyways....would yet like to know how the model size was achieved without a crash in GTP in contributor

andrewbho

Since you work for a Cognos partner, you should see the MSFT Competitive Intelligence.  It gives you more information on Office, SQL Server, and Performance Point and how Cognos is competing.  Products like Applix, Outlooksoft, Comshare are tier 2 vendors that are goign to have a limited life because they are tied to MSFT.  There's a strong need for products that are truely data source agnostic and I think that's where's Cognos' niche is.  Granted that there are competitors like Hyperion and BO that are the same.  Excel will always be meant as a personal productivity tool and NOT an Enterprise Solution.  MSFT has spent more money on Performance Management than any of their products.  They are catching up but are still behind the thought leadership of Cognos.