IBM's DB2 BLU Acceleration and Netezza technologies have upended the cozy database architectures of the mainframe...
and offer extremely attractive performance for the price. So when should you use each mainframe option?
Netezza's value proposition is simple. It is primarily used underneath a DB2 relational database management system veneer to run tasks requiring ultra-high performance -- typically big data analytics and reporting. "Just plop it in and it runs like a bat out of hell," said Rick van der Lans, a European consultant with no obvious IBM bias, when describing Netezza's very simple deployment and administration.
DB2 BLU Acceleration is more complicated, but its value proposition is just as compelling. It presently runs "underneath" DB2, with the potential to spread to other IBM data management products. It is a full columnar database in the vein of Oracle's Exadata, SAP's Sybase IQ and Hewlett-Packard's Vertica. These typically provide superior performance for queries involving two or fewer columns of a row. DB2 BLU Acceleration extends columnar technology in many complicated ways, with the net result that you should get at least an order-of-magnitude speedup on most queries, even compared to DB2 pre-BLU. It also piggybacks on DB2's admin functions like backup/recovery, and advertises that it doesn't use indexing, hence most implementations will not need administration at all.
Although IBM is touting both Netezza and DB2 BLU Acceleration mainly for data warehousing, analytics and reporting, a close examination of their technologies suggests they are potentially of higher performance, even in mixed query-plus-update, enterprise-app environments. Currently, operational (heavy update) use may be premature.
This is one of those rare occasions in my 30+ years of dealing with databases when the case for adopting a pair of technologies that offer once-in-a-decade speedups plus ease of administration and deployment is extremely strong.
Limitations on IBM BLU Acceleration, Netezza
DB2 BLU Acceleration only offers a Linux implementation on the mainframe, while Netezza is often done via a fork on the mainframe. This means a scheduler decides whether to feed data to a traditional DB2 relational database or to the Netezza box.
In practical terms, DB2 BLU Acceleration slips into DB2 underneath all your present and future Linux-DB2-based apps, while Netezza almost self-deploys once you define a high-performance project for it.
Three simple rules for mainframe database decisions
Overall, there are a few relatively simple rules for deciding when to use DB2 BLU Acceleration, when to use Netezza, and when not to use either:
- If the present app is not DB2 (or perhaps Informix), if it is operational, or is on z/OS, then your present setup is probably going to stay as is. Likewise, if you haven't upgraded DB2 to 10.1 or 10.5, then you may not get much bang for your buck, failing to take advantage of the major performance/scalability and price-performance enhancements that these DB2 versions offer on their own.
- In all high-end, non-operational cases where you can use either DB2 BLU Acceleration or Netezza, you should consider doing so. According to user testimonials, the performance improvements are great and the ease of deployment and administration are significant.
- In choosing between DB2 BLU Acceleration and Netezza, I suggest the following: When you have a one-off new project, choose Netezza. When you have a bundle of apps, including existing ones, that could all use a boost, choose DB2 BLU Acceleration.
About the author:
Wayne Kernochan is president of Infostructure Associates, an affiliate of Valley View Ventures, with more than 20 years of experience in IT industry analysis. This document is the result of Infostructure Associates-sponsored research. Infostructure Associates believes that its findings are objective and represent the best analysis available at the time of publication.