Database Reference
In-Depth Information
Most frequently encountered enterprise business intelligence system goals include
quick provision of relevant data to the business users and assuring excellent query
performance. If your cubes serve a large, global community of users, you will quickly
learn that SSAS is optimized to run a single query as fast as possible. Once users
send a multitude of heavy queries in parallel, you can expect to see memory, CPU,
and disk-related performance counters quickly rise, with a corresponding increase
in query execution duration which, in turn, worsens user experience. Although you
could build aggregations to improve query performance, doing so will lengthen
cube processing time, and, thereby, delay the delivery of essential data to decision
makers. It might also be tempting to consider using ROLAP storage mode in lieu of
MOLAP so that processing times are shorter, but MOLAP queries usually outperform
ROLAP due to heavy compression rates. Hence, figuring out the right storage mode
and appropriate level of aggregations is a great balancing act. If you cannot afford
to use ROLAP, and query performance is paramount to successful cube implement-
ation, you should consider scaling your solution. You have two options for scaling,
given as follows:
Scaling up : This option means purchasing servers with more memory, more
CPU cores, and faster disk drives
Scaling out : This option means purchasing several servers of approximately
the same capacity and distributing the querying workload across multiple
servers using a load balancing tool
SSAS lends itself best to the second option—scaling out. Later in this chapter you
will learn how to separate processing and querying activities and how to ensure that
all servers in the querying pool have the same data.
Search WWH ::




Custom Search