Database Reference
In-Depth Information
How it works...
The Scalable Shared Database (SSD) is an Enterprise and DataCenter edition feature. All the
configuration settings will depend upon the budget within the Enterprise, and at a certain
point, scaling up to move your application to more powerful computers gets you into the price
range of an enterprise-level hardware. Enterprise-level hardware that enables you to scale
to large data volumes is substantially more expensive than lightweight database hardware.
To scale your system, you add additional computers to your application. This process works
behind the scenes, where Analysis Services takes the query processing techniques; a client
application establishes a connection to a virtual IP address. That connection is redirected to
one of the front-end servers. The front-end server parses and resolves the queries from the
client application, and executes all the calculations defined in your cube.
To execute a query, the front-end server first determines if the answer is already available in
its local cache. If not, with the static replication model, it retrieves data from the local storage.
Moving data from a staging server to a production server is a simple process. With a scale-up
approach, it's relatively easy to backup your database. It's easier to restore the application
state from the backup.
For better query optimization techniques, the baselines build the foundation to measure
scale-out efficiency. It is possible to recognize that the formula-engine-heavy environment
does not support 500 concurrent users very well, while the storage-engine-heavy environment
has reached scale-out efficiency. Even though the I/O load is generally low, 100 concurrent
users seem to overwhelm the current storage subsystem and thus, query performance
suffers. If two query servers can support 200 users with query times of eight seconds, then
four servers should be able to support 600 users with about the same performance. Instead,
query times exceed 60 seconds and it is predictable that adding further query servers will not
bring the query time down to 10 seconds. It is necessary to review the scale-out design and
locate the actual bottleneck.
A tabular representation between Scale-out and Scale-up deployment is presented in the
following table:
Scale-Out
Scale-Up
Advantages
More Performance
Less to Manage
More Flexibility
Cheaper per GHz
Disadvantages
More Expensive
System Design Flaws become Critical
More to Manage
More Single Points of Failure
Search WWH ::
Custom Search