|
|
Intelligent Enterprise
March 1999
Experience Wins
Richard Winter
Most of us close to information technology have become accustomed to extraordinarily short product cycles and rapid change. Lately I have been feeling that my notebook computer, now 18 months old, is practically an antique.
Are products introduced more than five years ago dead or dying? Not in high-performance online transaction processing. Not even close.
Figure 1, page 70, presents a chart from the 1998 Winter VLDB Survey Industry Report identifying the highest transaction rate reported in the survey for each of eight DBMSs. The chart plots each of the eight data points with respect to both transaction rate and database size.
Figure 1 tells us this: The mainframe systems with the highest
transaction rates in the survey have roughly 20 times the transaction
rate and roughly eight times the data size of the corresponding
Unix systems. And those mainframe systems are all running on
mature database engines. The youngest database engine in the
mainframe crowd here is DB2 for OS/390, which IBM introduced
about 13 years ago. The leader in OLTP transaction rate here
is running on CCA’s Model 204, which entered the database
software market about 25 years ago!
FIGURE 1 Peak TPS of leading DBMSs at transaction processing
sites in 1998.
Products such as DB2, Model 204, and OS/390 have been improved continuously throughout their product lives, of course. They aren’t the same products they were when they came to market a decade or more ago. But in the strange market dynamics of our industry, such established products are often devalued for being “old.”
Yet the picture in large-scale OLTP is triply interesting: first, because of the leadership role of mature (if not “old”) products; second, because the performance gap between old and new appears remarkably large (even if you discount for any potential gaps in the survey data); and third, because this gap is rarely discussed in the industry.
Note that this picture is much different from what we see with large-scale decision-support systems, where Unix has become the dominant platform and more recently introduced architectures are prevalent on the largest databases — even those with large, demanding workloads and large numbers of interactive queries in flight.
Why Mature Products Dominate
Why this conservatism? Mainly, because it really does take a long time for reliable, high-performance, scalable OLTP products to mature. Good design and engineering are absolutely necessary in such products, but they are never enough.
Basically, OLTP products have to be run in large-scale production for a long time at a substantial number of sites before they run reliably. Experienced practitioners know the hard truth here: You cannot come up with enough laboratory test cases to debug these things really well. The final stage of debugging occurs only in the field.
Nobody wants to put an untried product into operation on a big OLTP system. So every product has to work its way up the ladder, pretty much one rung at a time. And that takes time. Time to find the problems. Time to fix the problems. Time to debug the fixes. Time to find the bottlenecks. Time to diagnose the bottlenecks. Time to engineer the solutions. Time to prove the solutions work. Time to identify the sources of downtime. Time to engineer higher availability solutions, and so on. It takes years. And the Internet hasn’t made it happen all that much faster — it’s just put more of a premium on genuinely high-performance, scalable, reliable transaction processing.
The E-Commerce Irony
There is an irony operating here with regard to e-commerce systems. E-commerce systems face scaling requirements the likes of which the world has never seen before. Some systems can go from zero to millions of users in just a few months.
In many respects, of course, the Internet has driven new technologies. We have needed new tools and architectures — especially at the front end and in the middleware — to create these systems at all and make them operate. But at the back end, in the database engine, these extreme pressures have caused many implementers to reach for proven solutions. Why? Because the volume builds so fast that they cannot afford to take a chance on something newer. There is no time to experiment and switch if you encounter difficulties. You have to start on day one with a system that can take you all the way up the volume curve.
In addition, many e-commerce systems have to be up all the time. Many have to deliver high performance, and many involve considerable volumes of data. Thus, they face a formidable combination of requirements. As a result, some companies — where the direction as recently as a year ago was to “get rid of all the mainframes” — are rolling out new e-commerce systems with a proprietary mainframe (such as OS/390 or Tandem’s Himalaya) as the back-end server. On the front end of many of these systems you see only software that’s less than six months old; whereas on the back end you see only software that’s more than 10 years old.
Now, this pattern isn’t universal. I know from anecdotal information that managers of formidable e-commerce systems are implementing them with Oracle, Informix, and other Unix-based products. But the picture in Figure 1 supports what appears to be the larger trend: The most demanding OLTP applications — including some of the trendiest Internet applications — are often hosted at the back end on the more mature architectures.
Notes on the Survey Data
In the interest of being fair to the vendors involved here, note that any product shown in the chart could be in production somewhere supporting a higher transaction rate. Underrepresentation might result from the database owner choosing not to participate in the survey or the system having less than 100GB of data. Also, notice that Figure 1 doesn’t list the largest database size for each product. Rather, it shows the database size for the user implementation exhibiting the highest transaction rate in the VLDB Survey.
Two widely used, high-performance transaction-processing platforms don’t appear in the data: IBM’s IMS and Compaq’s (formerly Tandem’s) NonStop SQL. The survey solicited participation from the users of all VLDB platforms, but users of these two platforms rarely responded.
Finally, keep in mind that transaction rate is only a rough indicator of the workload. The function of the transactions is also important, but that is something we can’t yet compare across systems.
So the VLDB Survey does not present an infallible picture. But, taking all factors into account, the data in Figure 1 still is quite persuasive. There is a major gap between mainframes and Unix-based systems in high-performance transaction processing.
The Winter VLDB Survey Industry Report (see www.wintercorp.com), from which I excerpted Figure 1, explores the VLDB frontier for both decision support and transaction processing. It examines database demographics, platforms and architectures in use, practices, and how the picture changed over the 1997-98 period. The Industry Report is the comprehensive source of the sort of information I explore in this column.
What’s Next?
One thing you can count on is that the picture will change in 1999, partly in response to the experience in recent months with e-commerce systems. No doubt both the mainframe frontier and the Unix frontier will advance. It will be interesting to see if the gap closes. My guess is that our existing survey data overstates the gap somewhat, although better response from users of IMS and NonStop SQL would serve only to dramatize the gap between mainframes and Unix-based systems.
There is no question that Unix systems become more solid each year and capable of meeting tougher requirements with each release. But it’s also true that customer requirements become tougher to meet each year. It wasn’t so long ago that demanding OLTP users thought 99 percent availability was pretty good. But 99 percent availability of your transaction-processing service translates to 3.65 days of downtime per year. The companies setting standards in service today are more frequently looking beyond to “three nines,” “four nines,” or even “five nines” (99.999 percent) availability. This demand, of course, puts a premium on products that have been proven in the cauldron of large-scale use.
What to Do?
If you’re faced with demanding, large-scale OLTP requirements, you need to make a fact-based decision. Do your homework. Make sure you know whether you’re in the mainstream, near the frontier, at the frontier, or beyond it. Be sure to recognize that OLTP solutions normally stay in place for several years; you must consider how your requirements are likely to scale over at least the first two to three years after implementation.
Benchmark if you can; demand proofs of performance, availability, and scalability in a pilot project if you can’t benchmark; and no matter what, investigate what others have done with the platforms you’re considering. Check out industry and vendor sources about what others have implemented. Check carefully for whether reference sites really are in production, what their data volumes (not their installed disk) are, what requirements they’re meeting, how they know they’re meeting requirements, and what their production volumes actually are. If you must race out ahead of the crowd, test early, test often, test to scale, and test thoroughly.
RESOURCES
CCA: www.cca-int.com
IBM: www.ibm.com
Tandem: www.tandem.com
VLDB practice — industry research and
reports: www.wintercorp.com