The bottom line in comparing these three architectures is that there are some common-alities in the ways that each vendor approaches Big Data analytics – but there are also some very distinct differences. These differences manifest themselves in database query process-ing speed; number of concurrent users that can be supported; the affect that query complexity can have on system performance; system efficiency/optimization; and manageability.
The key take-aways from this report should be as follows:
- IBM’s DB2 BLU Accelerator and SAP’s HANA use a columnar approach to set up data for processing (IBM can also use rows). Columnar processing can be much faster than row processing (Oracle uses a row-only processing approach);
- IBM’s DB2 BLU Accelerator has a distinct advantage over SAP’s HANA and Oracle’s Exadata in that it can analyze compressed data in memory. This means that more data can be read more quickly;
- SAP’s HANA can be excellent at processing large volumes of data in-memory for combined OLAP/OLTP environments where real-time results are required. We suspect, however, that as query complexity or volume (concurrent users) increases, performance will slow down significantly as each query contends for resources;
- Oracle’s Exadata Database Machine has been well received by the Oracle commun-ity because it offers good out-of-the-box performance and scales well. We see this appliance, however, as a general purpose analytics processor – not tuned for specific analytics workloads. Other shortcomings are its row-based orientation as well as its inability to read compressed data in memory. We think that given IBM’s system design advantages (faster processors, more threads, SIMD, balanced I/O handling, solid memory management), IBM POWER-based Power Systems should be able to easily outperform Exadata systems when processing complex and intermediate workloads respectively.