Performance in an Ad-Hoc Environment

I start off my Introduction to Netezza (or Netezza 101) presentations with the question “Would you still use Google if it took 7 days and 3 people o get your answer”, and most people scratch their head at first wondering why I ask this. Let me explain.

In my opinion, Google is a lot like today’s analytic tools/applications. When you use Google, you give it some search terms, and see what it comes up with. If you are lucky, the information you want is on the first page, but maybe it is on page two or three. Or maybe the search results are not what you were looking for, so you change the search terms completely, or add/remove some terms and search again. Eventually you find what you are looking for.

Today’s train of thought analytics is a lot like Google. You never know what someone is going to ask. You don't know where the result of one query will lead, or what the results will ultimately be. Unlike the report that gets the total sales for the past month, there is no “map” to guide train of thought analytics. IBM Netezza provides the unique ability to move beyond just reporting, and allows users to uncover the answers they are looking for.

IBM Netezza is the best solution for train of thought analytics for a number of reasons:

1. IBM Netezza does NOT require indexes to perform optimally 
2. IBM Netezza allows analytics across all of your data, not just a subset (I talked about this in an earlier post[1])

In my opinion a database that relies on indexes (or even worse, 19 different types of indexes) and aggregates to perform well is ill suited for train of though analytics. Now, these databases can run without indexes, as long as you take a very small sample of the data to run against… But then you run into incorrect and/or poor results that will not help drive more value, and may in fact hurt the bottom line.

Let’s use an example to show why a system that needs indexes is not suited for train of thought, or any ad-hoc, analytics. Given the following tables:

create table car_sales(

            delivery_date date,

make  varchar(45),

            model  varchar(45),

            model_year char(4),

            color varchar(20),

            VIN  varchar(45),

            selling_dealer varchar(45))

create table dealer_sales(

            VIN  varchar(45),

            cost decimal (10,2)

sales_price decimal(10,2),

            sales_person varchar(45))

create table sales_people(

            sales_person varchar(45),

dealer varchar(45)

region varchar(10))

If you want the total of all sales then you need only access the dealer_sales table. There are two things that will make this query faster, a materialized view or an index that just contains only the price column in the dealer_sales table. In this case the rows in table dealer_sales are 102 bytes wide. If you created an index on the price column, the index would be roughly 1/8^th of the width of the table, so the query should run roughly 8 times faster.  After seeing this query run a few times, a good DBA will create this index, but it is too late for the people who already ran their analytic queries.

Now, what if the regional sales manager wants to track the total sales by region at any given time. In order to calculate this you need to join the dealer_sales and car_sales tables, and you probably would want to create a join index (or an aggregate depending on which database you are using) to allow that to be done efficiently. The only column in these tables that is common across both tables is the VIN column, and that is not one of the columns that you are even referencing in the query (price and region, and probably date as well so he or she can look at the current day’s sales, as well as the current week, month, year to date, etc.).

If I were a regional manager I would also want to do some optimization of the delivery of new cars to the dealers where they are most likely to sell at the highest profit margin. Now, there are a number of ways to do this, and each has an increasing potential to drive more sales, if the current trends continue:

1)     Compute the average net profit (sales_price – cost) for every region and ship more cars to that region than to other regions

·       This would require at least two join indexes, and likely other secondary indexes on the sales_price and cost columns in dealer_sales.

2)     Compute the average net profit for each make (i.e. Ford, Chevy, Dodge, Acura, etc.), and ship more of that make of car to the dealers for that make in that region than to other regions

·       This would require the same indexes as above, but also an index on the make column in the car_sales table.

3)     Compute the average net profit for each make and model, and ship more of that model of car to the dealers for that make in that region than to other regions

·       This would require the same indexes as above, but also an index on the make and model columns in the car_sales table.

4)     But, maybe different regions also have a preference for color, like in the north eastern US where white does not show the dirt from the sand and salt on the roads in the winter. If we combine the color preference with the make and model preference from above, then we can tailor the inventory of each dealer to their customer set.

·       The color preference query would require the same indexes as above, but also an index on the color column in the car_sales table.

5)     Taking this even further, let’s look at inventory optimization. What if we can eliminate the need to keep cars on the lot for months before they sell. The historical sales might indicate that in Maine there is a three week period at the beginning of May when their sales are three times their normal rate for a two week period. Well, then I would want to make sure I have enough cars on the lot there (optimized by make, model and color of course) to meet this need, but I do not want to keep this much inventory all year long as it ties up a lot of money.

·       This would require more tuning of the data model with an index on the delivery_date column in the car_sales table.

Now, you can say that after all of this, you have all of the indexes and/or aggregates you might ever need. But that is only true for these queries. What about the local dealership manager who wants to see which salesman has sold the most cars in the past month, or sold the car with the highest average profit margin.

This is train of thought analytics, where one answer drives the next question. It is like going for a drive with no destination in mind. You cannot use MapQuest or Google Maps, since you do not know where you are going.

The revolutionary design of the IBM Netezza data warehouse provides exceptional performance without the need for indexes. The IBM Netezza architecture is based on a fundamental computer science principle: when operating on large data sets, do not move data unless absolutely necessary. IBM Netezza data warehouse appliances fully exploit this principle by utilizing commodity components called field programmable gate arrays (FPGAs) to filter out extraneous data as early in the data stream as possible, and as fast as data streams off the disk. This process of data elimination close to the data source removes I/O bottlenecks and frees up downstream components (CPU, memory and network) from processing superfluous data, and is therefore expected to have a significant multiplier effect on system performance.

---

[1] http://dsnowondb2.blogspot.com/2012/05/importance-of-agility-for-analytic.html

IBM Analytics help SUNY MS Research Team Improve Patient Care

http://thinking.netezza.com/press_release/leading-global-multiple-sclerosis-research-center-taps-ibm-analytics-improve-patient

IBM Netezza Delivers the Best TCO for Analytics Applications

More that 150 customers have compared IBM Netezza to Teradata, as well as other competitors, and they chose Netezza for a number of reasons. But the one underlying factor that most of these customers have told us, is how fast the IBM Netezza system paid for itself. This payback or return on investment (ROI) can come form many sources, including:

·       A low up front cost

·       Drastically reduced administration on the IBM Netezza system

·       The ability to run analytics on all of your data (not a sample)

·       The ability to run queries/reports that never finished on your existing system

While many people focus on the upfront cost of an item, in my opinion it is far more important to examine the total cost of ownership for that item. Think of it in the context of buying a new car. If Car-T costs $22,000 and Car-N costs $26,000 then that is a difference of $4,000. But, there is more to the costs of owning a car than just the purchase price. You also have insurance (think of that like upgrade protection/yearly maintenance when comparing it to a data warehouse system), and maintenance (the cost of the DBAs to keep the system running), as well as the cost of gas (the cost of electricity, cooling, etc.). If, for example, Car-T gets 12 mile per gallon (mpg) and Car-N gets 28 mpg, and you usually drive 15,000 mile per year. Then at a cost of $3.95 per gallon, it would cost you $4937 per year for gas for Car-T and only $2116 per year for Car-N. So, in this case Car-N would pay for the price difference in under 2 years, and every year after that you would reap the benefits of that choice.

Now, let’s make this car example match more closely to what data warehouse customers have to consider. In this case Car-T would be a 2-seater, cost $25,000 to buy, get 10 mpg, require premium gas, and have a top speed of 85 miles per hour (mph). Car-N would cost $15,000, have room for a family of 5, get 30 mpg using regular gas, and have a top speed of 300 mph.

If you can get the answers you want 3 times or more faster, at about half the up front cost and at one third of the ongoing costs, why would you choose anything else? Customers like MediaMath examined technologies form a number of different vendors, and chose Netezza because “Netezza’s appliance approach would be less costly than other options.”[1] And analysts (the consumer reports of the IT industry) agree. In their report, The Total Economic Impact Of IBM’s Netezza Data Warehouse Appliance With Advanced Analytics[2], Forrester examined a Netezza customer’s use of the IBM Netezza appliance, and based on their calculations the system paid for itself in under a year.

With the cost of DBAs (and gas) escalating, don't keep feeding your gas guzzler, take a test drive of a new IBM Netezza appliance and see how fast it really is, and how quickly it will pay for itself.

---

[1] http://www.google.com/url?sa=t&rct=j&q=nucleus%20research%20mediamath&source=web&cd=1&ved=0CDEQFjAA&url=http%3A%2F%2Fthinking.netezza.com%2Fsites%2Fdefault%2Ffiles%2Fdocument%2FNucleus_Research_ROI.pdf&ei=USyET4DgLIbV0QGO8sTnBw&usg=AFQjCNGqcbnE5tJxTsiwMB71uTMc5rCXOw&cad=rja

[2] http://thinking.netezza.com/pdf/total-economic-impact-ibms-netezza-data-warehouse-appliance-advanced-analytics-forrester-total

The Importance of Agility for Analytic Applications

In the context of data warehousing, agility means that the system can quickly and easily adapt to and accommodate; changes in data volumes, new data sources, new subject areas, new applications and/or new users. In order for a data warehouse to be able to do this, it needs to be able to run any query against any data model/schema. It must also be able to process all of the data, no mater what the query or what table(s) are being accessed, and do so quickly – without impacting the other users of the system.

You can accomplish this is a number of ways, including:

·       Over-building the original data warehouse to be able to handle some incremental growth

·       Restricting access to data or data sampling

·       Adding more resources for the new users, data and applications as they come on board. 

But normally there are a number of issues with these approaches,

·       Clients do not want to spend 2-3 times as much as they need to up front so they can accommodate some future growth that may or may not occur

·       Data sampling means that there is a good chance that the important data may be missed

·       Adding more resources to an exiting Teradata system can be a long, arduous, and costly process[1]

In our opinion, it is far more effective, from a cost and effort, as well as overall performance of the system perspective, to augment the Teradata system with IBM Netezza data warehouse appliances where you can run the new applications without impacting the current users at all. Rather than wait for weeks for the new system to arrive, the data model to be tweaked for the new application, the data to be moved, and the database to be tuned, why not roll in an IBM Netezza appliance, copy the data model (schema) as is, load the data, and be up and running in hours? 

As my colleague Nancy Kopp-Hensley discussed in her article "Consolidate Smarter with the Data Warehouse Ecosystem", we had a client that became challenged with query performance with their applications, and yet they were anxious to roll out some new applications in their sales and marketing divisions. Over time, they became challenged with query performance on their applications, and yet they were anxious to roll out some new applications in sales and marketing. And to top it off the business needed these new applications on-line right away. Rather than frustrate the business with a long timeline, which would have included first tuning the EDW to fix the existing problems before even starting the expansion, they chose to offload the new applications to a Netezza appliance. The result? Queries ran 24 times faster and they were able to achieve a much lower total cost of ownership (TCO).        

You could also move your deep analytic applications to the IBM Netezza platform, and run against the entire data set, not just the last week’s data, or a sample of the data from the last year like in the EDW. This will provide more accurate results and predictions that will help drive more value to the organization. Consider an example, you are trying to predict what a shopper can be influenced to buy, given a coupon. Let’s say that the shopper has bought the following items in the past month:

1.      Topographical Map of Alaska

2.      The book “Hiking Alaska”

3.      Tent

4.      Back pack

5.      Sleeping bag

6.      Compass

7.      Portable GPS

In their current shopping expedition they are buying a pair of hiking boots. Looking at the list of what they are buying, we might hazard a guess that they are looking to start hiking, but we do not know where, or know what else they might need. So, let’s sample their historical purchases, and see what we can come up with. Even with a 20% sample (which is much larger than normal) we might retrieve the tent and compass. We still do not know where they are going, so we might offer them a coupon for a sleeping bag. But we see that they already have one.

If the sample had included the book and the backpack instead, we now have an idea they might be going to Alaska, so maybe we should offer them a portable GPS for 20% off. This could be bad in a couple of ways… If the offer is for the same GPS they bought, they are likely to return the one they have and re-buy it, which just cut into the profit. If the offer is for a newer, better GPS and a price close to the price of what they just paid, then they may return the old one, or if they bought it just outside of the 30 day return window, you are likely to have an unhappy customer on your hands. This example shows why it is important to have fast analytics on all of your data, not just a “representative sample”, and this is what you can get by augmenting your EDW with an IBM Netezza data warehouse appliance.

---

[1] Teradata Customer Story - Overstock.com retrieved 05/17/2011 from http://tinyurl.com/6mdktgm -Since removed from the site

A number of Teradata customers have moved some or all of their data and analytic applications to IBM Netezza data warehouse appliances. The reasons these customers give for their move invariably include:

·       Time to value

·       Agility and the ability to grow with new workloads

·       Reducing their cost of ongoing maintenance

·       Improving query performance – particularly for complex analytics and ad-hoc environments as data volumes grow.

Over my next few posts I will dig deeper into these reasons and show the value of the IBM Netezza appliance.

One of Teradata’s reference customers, Overstock.com, was growing rapidly, and their warehouse was growing at over 60% per year.  Because they are an e-commerce company, they wanted to monitor and measure the effectiveness of their email campaigns. In order to keep up with these analytic requirements they needed to build a new analytic system to satisfy their current and future needs. In Overstock.com’s own words, “time-to-market”, or time to value, was of upmost importance. Overstock.com chose Teradata because they promised a 5-6 month delivery using a phased implementation project.[1]

In my opinion, Teradata took way too long to deliver a production ready system to Overstock.com. In fact many Netezza customers openly talk about how fast they have been up and running production workloads on their Netezza systems. Con-way Freight is a great example. IBM Netezza's initial set-up took less than 48 hours, and within the next two days, their entire data set was loaded onto the Netezza appliance and users had full access to the system. Four days after signing the purchase order with a Proof of Concept system in place, the new BI project was made available to internal users at Con-way Freight. And three weeks from the purchase date, the IBM Netezza-powered platform was running in full-scale production.[2]  

Now, in my opinion, that is time to value. 

Some of you might be asking, “how can Netezza do this?” Well, it all comes down to the simplicity of the Netezza system. Rather than spending days or weeks trying to decide between 19 different types of indexes like in Teradata, Netezza customers simple create the table and load it – that’s it. Netezza does not need join indexes, primary indexes, or partitioned primary indexes to perform well the way Teradata does. [3]

And with Netezza, you will not have to worry about growth and performance. The Netezza appliance scales linearly as you add data and additional racks to your system, without the need for adding more DBA resources, or doing more tuning of the database. In fact Christine Tilford from T-Mobile talks about growing from 100TB to 500TB to 1PB to 2PB, all with the same team (with only one DBA/engineer) in this video. This video also talks about true time to value, where Christine explains how T-Mobile was able to help the US Coast Guard locate a family whose boat had capsized using the power of the Netezza appliance.

If you want the fastest time to value, choose the proven leader, IBM’s Netezza 1000 appliance.

For More Information:

• White Paper: Break the "Add More Nodes" Cycle
• Video: Node Rage Support Group for Teradata Users: Session 1

---

[1] Teradata Customer Story - Overstock.com retrieved 05/17/2011 from http://tinyurl.com/6mdktgm:  Since removed from the site

[2] Con-way Freight Case Study, retrieved from http://www.google.com/url?sa=t&rct=j&q=con-way netezza&source=web&cd=5&ved=0CD4QFjAE&url=http%3A%2F%2Fwww.netezza.com%2Fdocuments%2Fcon-way-freight-case-study.pdf&ei=Xwy4ToTMDaOo2wWKjL3MDQ&usg=AFQjCNEgDL1PIvwHanu8uGh1Um8NTD6O4Q&cad=rja – Jan 31, 2012

[3] Session 2062, Partners, The Teradata User Group October 24-28, 2010 San Diego - Engineering Techniques to Achieve a Performant PDM – By Mark Miller and Danny Maddox, Teradata

Not All In-Database Analytics Are Created Equal

Leading organizations differentiate themselves by analyzing massive amounts of interrelated data to predict business outcomes. High-volume, complex data analytics requires detailed data (not summaries) because influencing an individual’s actions requires that you track and analyze their unique interactions with your company.  Traditional analytic systems and traditional databases cannot meet today’s need for predictive analytics on massive amounts of data.

It’s easy to overlook data movement when thinking about analytics and analytic performance. However, as data volumes increase, the simple act of moving data to an analytic engine dramatically decreases overall performance. To illustrate, a major credit card company takes two weeks to build its analysis files while an insurance company needs six days to perform this task. For many large-data analyses moving data consumes far more time than all other activities combined. I will compare traditional systems, comprised of physically separate database and compute servers, and various forms of contemporary analytic data warehouses. I will also note the types of analytics typically available to each analytic system.

Recognizing that database servers were not built for complex analytics, vendors paired a compute server with the database server. These traditional two-server analytic systems extract data from the database (either the data warehouse or the transactional database system) and move them onto another server, where they perform model building, model validation, and scoring processes. Moving a big data set from the database server to the analytic server is very inefficient and results in a large lag between the time data are created and their analysis. Beyond performance, this architecture has many challenges, including increased network load, overhead for analyst, demand for redundant infrastructure, data governance and synchronization issues, and data security concerns.

The next generation of analytic servers was driven by the need to minimize data movement. Most data warehouse vendors have built what they call in-database analytics. The main innovation was collocation of the compute and database engine to eliminate the need to copy data to another server for analysis. However, data must still be moved from disk to memory before the real analytics can happen. Moreover, the data transfers are not optimized – these systems must move entire tables even if only a subset of rows and columns is necessary to perform the analysis. And in many cases these data warehouses only offer SQL-based in-database analytics based like MIN, MAX, AVERAGE, and MEDIAN.

In terms of performance, the in-database stream processing architecture rises to the top. This architecture, found in the IBM Netezza data warehouse, eliminates the need to copy data to memory as data are analyzed as they stream off disk - minimizing data movement and data volume prior to scoring. Data minimization is accomplished with three capabilities: zone map technology and two types of filter technology. Zone map acceleration exploits the natural ordering of rows in a data warehouse to avoid scanning rows that are not relevant to the analytic query. Next, project and restrict engines eliminate columns and rows, respectfully. The IBM Netezza data warehouse appliance delivers unbeatable performance because it performs complex analytics as data streams off disk.

Many large-data analytics processes lack performance due to data movement. Traditional two-server solutions must move data within the database server and then over a network to the analytic server. General purpose data warehouses eliminate data movement across a network by collocating database and analytics servers, but are still hampered by copying data from disk to memory before scoring. High performance analytics servers take advantage of a stream processing architecture to eliminate unnecessary data movement. In other words, by using the IBM Netezza stream processing architecture, the credit card and insurance companies would immediately recognize performance gains of two weeks and six days, respectively. I hope this blog post helps you see that not all in-database analytics solutions are optimized for large-scale data. I welcome your feedback and I’m happy to field questions.

If you had to go to the store to buy something important and you had to choose between a store with one cashier or one with 1000, which would you choose?

You might think this analogy is a little crazy when thinking about computers and computer software, but let me explain a little more. 

In today’s global, dynamic environment, agile and pervasive analytics and business intelligence is critical to success. Whether you are a retailer who wants to cut shrinkage by finding employees that are using discarded receipts to do returns without merchandise, an insurance firm who wants to limit liability by not insuring too many properties within flood regions, a financial firm that wants to detect fraudulent charges quickly, or a line of business executive that wants to find all of the open opportunities in your territory, you want access to the information you need, when you need it. You do not want to have to wait in line behind everyone else in your organization just to run your query/report.

But wait is what you will have to do if you buy one of the new HP/Microsoft Data Warehouse Appliances. Over the past couple of months Microsoft and HP announced three new Data Warehouse Appliances and have given them cool names like the “Business Decision Appliance” and “Business Data Warehouse Appliance”. Unless you are the only employee in your business, these appliances are not for you. Microsoft and HP’s own web sites say that these appliances are optimal for “light concurrency”.

Why spend your time loading data into one of these appliances, and then have to wait in line to get the results you need to run your business. If you buy a data warehouse appliance that supports only light concurrency, you're stuck waiting in line to get answers to your questions, which can often take over 24 hours to run.  If you want a high concurrency appliance, where these same queries run in minutes, consider Netezza.

IBM Netezza’s high-performance data warehouse appliances are purpose built to make advanced analytics on data simpler, faster and accessible to everyone. These data warehouse appliances are designed specifically to allow people across the enterprise to run complex analytics on very large data volumes, orders of magnitude faster than competing solutions. Customers are able to easily and cost effectively, scale their business intelligence and analytical infrastructure, to leverage deeper insights from growing data volumes, throughout the organization.

Nielsen gathers information from multiple sources and offers their clients a complete understanding of what consumers watch, listen to, browse and buy. Their analytics infrastructure is based on Netezza, and their end-user clients run close to a million queries a day, 50 times faster than on their previous systems. As The Neilsen Company’s Senior VP of Application Development has said, “when you’re able to get deep insights in 10 seconds instead of 24 hours, you can do remarkable things with the business”.

Oracle Throws Another Jab at HP

If you are running your business on HP Itanium servers and Oracle software, what can you do?  Do you have to move to Oracle/Sun servers and Oracle Exadata?

Oracle drops Itanium support at customers’ expense

In 2008 Larry Ellison announced the new Oracle Database Machine and Exadata Storage Servers based on HP hardware. In January of 2010, after Oracle’s acquisition of Sun, they immediately dropped support for HP hardware and told all customers that they had to move to the Sun/Oracle Exadata System. In March of 2011 Oracle threw another jab at HP with the announcement that Oracle was stopping all future support for their software on Itanium processors, the base on many of HP’s most popular servers.

You decide what software and hardware you want to run (not Oracle)

Because of Oracle’s track record with HP servers and storage, many customers are concerned about the future of the systems and applications that they are using to run their businesses. Oracle would have these customers believe that they need to move the application servers, databases, etc. to Sun hardware so that they can continue to run their applications, but that is absolutely not true, and I’ll tell you why.

Fear Not the Oracle

IBM WebSphere and DB2 software both run on Itanium processors. WebLogic works great with DB2 and WebSphere supports Oracle Database. So you have a number of options, and none of them require you to immediately rip and replace all of your servers. If you are running Oracle WebLogic or the Oracle Database on an Itanium based server, you could:

1. Replace WebLogic with IBM WebSphere which supports Itanium processors and continue to run on the same servers
2. Replace Oracle Database with DB2 which supports Itanium processors and continue to run on the same servers
3. Replace WebLogic with IBM WebSphere and Oracle Database with DB2 and consolidate them onto a single Power7 server,  reducing your data center footprint and increasing performance

You don’t even need to do this in a big bang approach. You choose which part of your application landscape to leave on HP Itanium and which part you might consider moving to another platform. You choose which application server and database to use and what platforms you want to run them on. Most importantly, you can make the right moves and not disrupt your entire business.  (Read the executive take on these options here). 

And if you must change server platform, consider IBM

If you are being forced to change server platform, then consider IBM one of your options.  IBM offers the industry’s leading server platforms (Sun comes in a distant and dwindling third place in market share).  When you combine IBM’s commitment to meetings its client needs, with its pace-setting performance and reliability, you provide your organization with the best option for future stability and growth.  Running IBM software on IBM servers is the best option of all!

IBM can help take the pain away

Migration to IBM WebSphere and DB2 is painless and very low risk.  Even if you were to move to an x86 based HP or Sun server and not change any of the software, you would need to recompile and rebuild your application.  Take a look at your options, the cost and risk associated with each, and then look at the track record of the companies involved.   Why not assess the predicament that you are in and ask why you are here. It looks to me like Oracle unilaterally put your company into this situation.  It’s time to distance yourself from the culprit.

When IBM Innovates, Everyone Benefits - Oracle Make Everyone Pay

When Oracle beta customers were testing Oracle Database 11gR2 many were praising the new fangled columnar compression that helped reduce their databases to a more manageable level. Many of these customers used the beta code on their existing test systems and their test data to see what benefits they would get when they upgraded to the latest release.

Imagine their surprise when Oracle thanked them all for their loyalty and testing, and restricted the use of hybrid columnar compression to "Exadata Only" systems, when the beta showed that this capability is built into the Oracle Database software, and has no reliance on Exadata at all.

Oracle will even let you backup a table space on Exadata that has data that is columnar compressed and restore it to a non-Exadata server. You cannot query or access this data after the restore, but if you alter the table and "un-compress" it you can. This also shows that the Oracle Database can read and understand the columnar compressed data.

IBM on the other hand makes enhancements available to existing customers, on their existing platforms. When index, XML, and temporary table compression were introduced in DB2 9.7, all existing DB2 customers could immediately take advantage of these enhancements when they upgraded to this release.

Who would you rather do business with?  The company that innovates and makes these enhancements available to all customers, or the one that adds features, but restricts access to only those that buy new hardware and specialized software licenses that are not even needed for the feature? 

IBM benchmarks against today's latest and greatest. Oracle benchmarks too - against yesterday's best

Be careful what you believe – Google is your friend

Before you take what you read to heart, check the facts. In the past month or so, Oracle has been making a lot of noise about Linkshare’s migration from a DB2 data warehouse to Oracle Exadata.  While Linkshare did not explicitly mention that they had been running on an older DB2 system (with older hardware), the articles do say that “A Google search of past LinkShare coverage turned up several article references to a conventional DB2 database deployment in a clustered Linux environment.” 

If you read Oracle’s press releases when they discuss the performance of Exadata, you would be led to believe that “Exadata met that benchmark out of the gate”. But, if we dig a little deeper into this, Google shows us that Linkshare employed the services of the Pythian Group to help the migration. And the Pythian group provided “LinkShare with consulting and technical expertise for the planning, configuration, deployment, management, administration and ongoing operational support of their migration project. This includes re-engineering the database, adjusting the data model, redefining table structures, creating new indexing schemes and re-writing and tuning SQL queries, among other tasks.”

I might be in the minority here, but out of the gate does not mean after paying a highly skilled consulting team for months to re-engineer the whole database schema to work on Oracle RAC / Exadata, and re-writing / tuning queries that would not run fast enough.

At IBM we know that our workload optimized systems are the easiest to use, and the fastest in the industry. We compare ourselves to the latest and greatest competitive offerings all the time, not to 5 year old systems running software that is 3 or more releases behind the times. Check out this link for an interview with Steve Mills where he discusses one of these tests.

In my opinion the proof is in the pudding. Do not trust press releases,  do not let vendors run benchmarks on their site…  Always