Originating Authors: David Floyer and Nick Allen
This research has been significantly extended in two more recent professional alerts (Spring 2014). These are:
- "Duplicating Public Cloud Economics for Oracle Database Infrastructure";
- "Duplicating Public Cloud Economics for Oracle DBAs".
In the Wikibon research professional alert entitled “The Limited Value of Oracle Exadata”, Wikibon concluded that “Oracle Exadata servers are not best of breed, and the storage subsystem is far below the functionality required.” This professional alert looks in greater depth at the comparison in storage functionality, and its implications for IT costs and Oracle’s appliance strategy.
Table 1 shows a comparison of standard Tier 1 storage array features that are not found in Oracle Exadata Storage Servers. Many of these are very common features. For example, thin provisioning and tiered storage together can provide a 40% reduction in storage requirements and much lower initial and ongoing storage costs. The lack of any basic snapshot technology makes it far more difficult for systems and database administrators to troubleshoot performance or functionality problems and provide support for development. Major constraints are imposed by the forced choice between performance disks (FC disks) or capacity disks (SATA). These constraints on storage expansion and sharing dictate that the best practice on all Exadata systems is to use the same type of disks. Although Exadata includes high performance PCIe flash cards, it provides poor support for flash other than as read-only cache - impacting the ability to provide specific performance help to (say) key tables in high performance systems.
Table 2 shows a comparison of storage features that are found in standard Tier 1 storage arrays as well as Exadata. The first 12 features have equivalent support. However the Exadata implementation provides only limited support for the last nine.
Table 3 shows the two features, Smartscan and Hybrid Columnar Compression, that provide additional functionality on the Oracle storage server. Both are of use only in batch workloads or in a modest number of data warehousing applications. Both help to improve the elapsed time for full table scans on tables without indexes. The second feature (Hybrid Columnar Compression) is available without Exadata on Sun ZFS storage. Absent these Exadata features, most situations can be addressed by simple indexing, with a small increase in developer cost. At the high end, traditional Oracle full table scans do not compete on cost or performance with shared nothing systems such as EMC Greenplum, HP Vertica and IBM Netezza solutions.
Exadata marketing has focused on the development manager, touting the advantages of the two additional features, with allusions to additional features in the future. When all is said and done, the actual advantage is the benefit of a single SKU, including the database itself. This simplifies the management of installing and maintaining the appliance.
The true comparison for Exadata is with other converged appliances that are provided as a single SKU. In the Wikibon professional alert “The Limited Value of Oracle Exadata”, Wikibon shows that the Oracle Exadata appliance does have two specific savings areas over appliances without Oracle database support:
- The additional costs of installing and maintaining Oracle databases;
- The additional costs of indexing databases to perform full table scans.
However, the inflexibility of the Exadata configuration, the lack of the storage functionality described above and the isolation of resources from effective management by operations, far outweigh the potential savings of integrating Oracle. A Wikibon Return-on-Assets analysis (ROA) showed that Exadata has 86% higher costs, even after taking these two cost advantages into account.
The overall conclusion is that Exadata is a complete computing island, using components and integration that are far from best-of-breed. Being closer to Oracle may be initially attractive to the database group, which can use a DBA to control the development and operational databases. However, this is at the expense of higher costs for operational functions and greater difficulty and cost in accessing the data for other applications development and deployment groups. One of the key business benefits of databases is to ensure that data is available across the enterprise, not locked into an environment only accessible by a privileged few.
In general, appliances need to be able to fit in with normal data center standards and allow themselves to be managed as part of an application or application suite to meet the performance and availability SLAs agreed to between IT and the business.
Wikibon believes that Oracle needs to change its appliance philosophy completely or risk becoming irrelevant to the enterprise. Oracle should use much higher quality storage, server, and networking components with fewer constraints on configuration. The database appliance should be able to share resources with the rest of the data center and be managed as a component by the data center as a whole (e.g., managed by RESTful APIs).
Action Item: While early Exadata hype was exciting and alluring, research indicates that its value proposition is very narrow. When compared to traditional high performance storage systems (e.g. 3PAR, EMC, IBM and HDS), Exadata falls short because it lacks critical functions that both reduce storage capacity consumption and increase flexibility. In addition, Exadata is not well-suited for supporting general purpose applications across the portfolio. Customers considering Exadata should understand its use case and ensure that it can be justified based on its limited application breadth. In these cases, the integrated nature of Exadata will deliver value in the form of simplifying IT infrastructure, however that convenience will come at a steep price in the form of ongoing lock-in to Oracle's "Red Stack."
Footnotes: