|
|
Intelligent Enterprise
February
1999
Lexicology
of Scale
Richard Winter
What is scalability, really? A subscriber recently asked me this question because, although he sees the term all the time, he hasn’t been able to find a solid definition. And, he explained, its meaning seems to vary considerably with the context. Reflecting on his inquiry, I realized that market confusion about scalability continues to grow, even though we’re more than five years into the age of commercial parallel architectures. The only real point of agreement about scalability is that everyone touts it: All vendors claim their products are scalable, and all users want them to be.
This great consumer demand and vendors’ promises in response create a danger to users, who may make long-term commitments before working out stringently enough which specific forms of scalability they need. This column will provide you with definitions of terms and with techniques that you can use to methodically decide how to plan for and respond to your system expansion needs.
Definition of Terms
Let’s lay the groundwork for further discussion by first defining some terms very specifically.
Scalability: The ability to grow your system smoothly and economically as your requirements increase.
System: Any platform, architecture, application, network, or database — virtually any information technology entity.
Requirements: Specifically, volume-related requirements (transaction volume, input data volume, output data volume, stored data volume, user population, and so on).
The ability to grow your system smoothly and economically: Being able to increase the capacity of your system at an acceptable incremental cost per capacity unit without encountering limits that would force you either to implement a disruptive system upgrade or replacement, or to compromise on your requirements.
Classic Dimensions of Scalability
Now let’s get one step more specific about scalability. Taking databases as an example, there are four classic dimensions of scalability: data size, speed, workload, and transaction cost. In analyzing each of these dimensions, you need to judge your system growth by the ideal of linear scaling. In other words, dimensions related to result (such as total response time and cost) ought to increase — at most — in direct proportion with dimensions related to requirements (such as transaction and data volume).
Data size. Data size, sometimes also called “size up,” refers to the following principle (see Figure 1, page 72):
Assuming a constant hardware configuration, if your database size increases by a factor of x, then in a scalable system, your query response time will increase by at most a factor of x.
Suppose you increase your stored data volume from 100GB to 500GB and make no hardware changes. In a system with linear scaling, the transactions (both query and update) that used to take one second will now take at most five seconds.
Speed. Speed, sometimes also called “speed up,” refers to the following principle (see Figure 2, page 72):
If you increase the capacity of your hardware configuration by a factor of x, then in a scalable system, your query response time will decrease by no less than a factor of x.
Suppose you upgrade from one node to 64. Assuming a node configuration balanced for the task at hand, in a system with linear scaling, transactions that used to take 64 seconds would now take no more than one.
Workload. Workload scaling, sometimes simply called “scale up,” refers to the following principle (see Figure 3, page 72):
If you increase the workload on your system by a factor of x, then in a scalable system, you can maintain response time, throughput, or both by increasing your capacity by a factor of no more than x.
Suppose your transaction volume increased from 3.6 per hour to 3,600 — an increase of 1,000 percent. The system is linearly scalable if it can continue to deliver the same response time with a capacity increase of no more than 1,000 times. By increasing the number of processors to 1,000, you accomplish linear scaling.
Transaction cost. Two principles relate to transaction cost. First, in a scalable system, increases in workload do not increase transaction cost (see Figure 4, page 72). If it costs five cents to process an order when you have one processor, it should still cost no more than five cents to process an order with 1,000 processors. You should not be forced to increase capacity faster than demand.
Second, in a scalable system, if data size increases by a
factor of x, transaction cost increases by no more than
a factor of x (see Figure 5). So, if a query consumes
15 cents of system resources when run against a 100GB database,
then on a scalable system, it will consume
FIGURE 1 Linear size up.
FIGURE 2 Linear speed up.
FIGURE 3 Linear scale up.
no more than 75 cents of system resources on a 500GB database.
In summary, a database implementation that exhibits linear scaling in the classic dimensions — data size, speed, workload and transaction cost — is in principle what is discussed when people say they want, or they provide, scalability.
Users Are from Earth; Vendors Are from the Asteroid Belt
Here’s what it all comes down to: When a user demands scalability, it simply means, I want a system I won’t outgrow — no matter how my requirements change — period.
Business executives don’t much want to hear about the different dimensions of scalability or how complicated it is to define needs. All they want is a promise (a guarantee, really) that the capacity will always be available, the performance will always be good, and the incremental cost will always be declining. This is entirely reasonable from the executive point of view: Part of the executive’s job is to realize an appropriate return on business investments.
But vendors can’t really deliver what users want. What they can deliver are specific dimensions of scalability in specific situations within defined limits and time periods — and with some discontinuities.
Vendors talk as though scalability were all one thing — but it is several different things. Some products serve many concurrent users well. Some serve large databases well. Few serve both well. And all products have their scaling limits, generally closer than you at first suspect.
Like pop psychology’s miscommunicating Martian men and Venusian women, users and vendors often talk about scalability while meaning different things. The user walks away from the conversation thinking that the business won’t outgrow the solution. The vendor thinks the same thing, assuming that the user’s requirements will never exceed the product’s limitations. The insidious aspect of this, of course, is that everything is fine at the beginning. If you come to rely on a system that can perform with an initially small workload, you will be in dire straits if workload increases bring the system to its knees. If increased workload is due to increased sales, the good news that sales are up becomes the bad news that you can’t take orders.
In other words, just when you should be recouping your costs, you’re giving up potential revenue. But, if you anticipate your specific scalability issues before deciding on technology investments, and well before those issues become reality, your chances of smooth and economical growth greatly improve.
How to Talk about Scalability
So, what’s the solution? It’s being concrete about
the critical factors. If volumes are going to increase substantially
during the life of your system, then you have a scalability issue.
The question is not whether you will confront the issue, but
when. With enough workload, data,
FIGURE 4 Linear scaling: cost vs. workload.
FIGURE 5 Linear scaling: cost vs. data size.
or users, every product will either reach its limits or become
inefficient. To frame the scalability question effectively, it’s
critical to define three factors: the target system life, the
key scalability dimensions, and the required range of scaling.
You can’t have infinite scalability, so you need to decide how much scalability to buy. Understand what you need, specifically, and take steps to see that it is demonstrated to you.