I have all the information regarding my OLAP database. I know how many dimensions,hierchies, levels, members, and measures I will have. I also will know the datatypes of the measures. Knowing all these parameters, how do I calculate the number of bytes that my OLAP database will use?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
How do you calculate the number of bytes for OLAP DB
- Thread starter RicoCali
- Start date
Rico,
Are you wanting a number for a typical row in the database? or the overall number of bytes for the database?
You can see the size of your olap database in the Data Directory, if that helps. Data directory is a property of the Analysis Server.
Justin
Are you wanting a number for a typical row in the database? or the overall number of bytes for the database?
You can see the size of your olap database in the Data Directory, if that helps. Data directory is a property of the Analysis Server.
Justin
Justins method works for determing current size as it is the total size of the directory where the data files live. However, this doesn't help predict future growth.
one method I was told by a leader in the BI industry is to forecast storage needs is to look at the data types and number of members in your dimensions and facts. If you have a structure such as
Product Dimension
All
Category Key = INT(4 bytes) Name = Varchar(50)
Class = INT(4 bytes) Name = Varchar(50)
Product = INT(4 bytes) Name = Varchar(50)
Dimension counts are 4 Categories, 15 Classes, and 2000 products you would get
(4*4)+(4*50) approx 216 bytes
(15*4)+(15*50) approx 810 bytes
(2000*4)+(2000*50) approx 108000 bytes
Total 109026 Bytes
Facts are a bit easier just take data type size multiply by row count.
Add all your dimensions and fact tables up add the storage requirements for your aggregations per partition with a bit of overhead for metadata and you should be in the ball park.
Shoot Me! Shoot Me NOW!!!
- Daffy Duck
one method I was told by a leader in the BI industry is to forecast storage needs is to look at the data types and number of members in your dimensions and facts. If you have a structure such as
Product Dimension
All
Category Key = INT(4 bytes) Name = Varchar(50)
Class = INT(4 bytes) Name = Varchar(50)
Product = INT(4 bytes) Name = Varchar(50)
Dimension counts are 4 Categories, 15 Classes, and 2000 products you would get
(4*4)+(4*50) approx 216 bytes
(15*4)+(15*50) approx 810 bytes
(2000*4)+(2000*50) approx 108000 bytes
Total 109026 Bytes
Facts are a bit easier just take data type size multiply by row count.
Add all your dimensions and fact tables up add the storage requirements for your aggregations per partition with a bit of overhead for metadata and you should be in the ball park.
Shoot Me! Shoot Me NOW!!!
- Daffy Duck
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
- Locked
- Question