Documents

Cl Abby Analytics Db 2

Description
Comparison between oracle Exadata and IBM DB2
Categories
Published
of 4
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
     Research Report    IBM DB2 BLU Acceleration vs. SAP HANA vs. Oracle Exadata   Executive Summary Your organization has volumes upon volumes of structured and unstructured data. There is  business value in that data: information that can enable your enterprise to capitalize on new opportunities or respond more quickly to competitive threats; information that can lead to  better customer service, or better risk management, or the ability to spot new trends; information that can enable your enterprise to gain new insights. But the big question is how to best glean this wisdom from your Big Data database? To find the pearls of wisdom within a Big Data database, enterprises need to: 1.   find ways to shrink the database to a manageable size; 2.   use effective analytics tools; and, 3.   select a computing environment designed to process large databases. Oracle, SAP, and IBM make analytics software designed to process Big Data databases. Oracle and IBM also make systems and integrate their software on these systems. SAP deploys o n commodity hardware. There are some similarities in each vendor’s approach,  but there are also several distinct differences:    Oracle’s approach involves using an Oracle real application cluster (RAC) specially tuned to process vast amounts of data. Accord ing to Oracle’s web site, this system (Oracle’s Exadata Database Machine) combines massive memory and low -cost disks to deliver the highest performance and petabyte scalability at the lowest cost.    SAP’s HANA places large amounts of columnar data in main me mory where the whole database can be analyzed in real time. HANA also compresses data by as much as 20X prior to analysis. According to SAP HANA’s Website, HANA con -verges database and application platform capabilities in-memory to transform transactions, analytics, text analysis, predictive and spatial processing so businesses can operate in real-time. This in-memory real time approach is distinctly different from the memory and disk-based caching approaches used by both Oracle and IBM.    IBM offers several different systems designed and tuned to run specific types of analytics workloads, including IBM PureData System for Analytics, PureData System for Operation-al Analytics, PureData System for Hadoop, and PureData System for Transactions. This approach is distinctly different from the one-size-fits-all approaches used by both Oracle and SAP.    IBM also offers an accelerator environment known as BLU Acceleration that shrinks the size of a given Big Data database, speed reads compressed files, and delivers results exponentially faster than its competitors when running various analytics workloads.  IBM DB2 BLU Acceleration vs. SAP HANA vs. Oracle Exadata   September, 2013 © 2013 Clabby Analytics Page 2 Each approach enables enterprises to analyze large volumes of Big Data. But each approach is distinctly different  –   yielding different performance results depending on the type of workload being executed. Oracle’s Exadata –   An Out-of-the-Box Performance Rocket Enterprises that are strategically committed to running Oracle love the Exadata Database Machine. This environment has been tuned and optimized by Oracle experts to run Oracle databases at speeds that most customers, despite their best efforts, can’t achieve.  On the downside, this design uses a row-based approach to database processing (as com-  pared to SAP columnar approach and IBM’s row/column approach). As for sh rinking the size of the database, Oracle’s compression algorithms do not appear to be as efficient as IBM’s, meaning that Oracle requires more (costly) disk space to hold data. Oracle’s Exadata is not an in- memory database environment such as SAP’s HANA, s o some of the infor-mation that Exadata processes needs to be moved on and off of mechanical and/or solid state storage (the input/output to cached storage is slower than reading and writing data to main memory). Finally, Oracle did not design its Exadata server to exploit SIMD (single instruction, multiple data) processing, a processor extension that enables parallel work- loads to execute quickly. In contrast, IBM’s BLU Acceleration approach exploits SIMD and achieves higher performance for several workloads. The end result when using Exadata is that it can process large amounts of Big Data  –   but its design differs from SAP’s in - memory HANA or IBM’s compress -and-speed-read-the-compressed-files-in-memory BLU Acceleration approaches  –   and may not yield equivalent  performance results on similar workloads. For enterprises that are strategically committed to Oracle’s database, however, Exadata has been optimized to process Oracle Big Data da -tabases and achieves good results.  SAP’s HANA: In -memory Real-time Big Data Processing The design point for SAP’s HANA environment is based around placing all the data to be analyzed in fast main memory where it can be analyzed in real time. The emphasis in the HANA design is to converge online analytical processing (OLAP) and online transaction  processing (OLTP) into one columnar store in order to eliminate latency (reads/writes to disk) and thus speed real-time decision making. The design advantage in using an in-memory data store is that cache/disk latency is eliminated, and OLAP and OLTP activities can take place in parallel in real time. In contrast, IBM’s DB2 Acceleration would need to access row-based tables stored on disk to perform certain operational queries  –   while trend and historical data would probably reside in an in-memory data mart (having to go to two different places in order to gather data could make BLU less suitable for real-time analysis as com-pared with using main memory exclusively). As noted earlier, HANA runs on ―commodity hardware (meaning x86 -based servers). All three vendors tune their software for underlying platforms  –   but it is noteworthy that HANA performance varies depending on the system on which it is deployed. For example, IBM’s System x X5 solutions deliver the best HANA performance results –   which may be why SAP uses X5 systems as the HANA reference architecture.  IBM DB2 BLU Acceleration vs. SAP HANA vs. Oracle Exadata   September, 2013 © 2013 Clabby Analytics Page 3 The big questions to be answered with respect to how HANA handles large in-memory databases are “how many concurrent users can be supported” and “how does the system  perform as queries complexity increases?” SAP’s own HANA Memory Usage guide indirectly raises these questions when it states that “ the amount of extra memory will depend on the size of the tables (larger tables will create larger intermediate result-tables in operations like joins), but even more on the expected work load in terms of the concurrency and complexity of the analytical queries (each concurrent query needs its own work-space) ” . This could mean that as query complexity increases, performance will slow down  –   and, because each query needs its own workspace, the number of concurrent workloads may need to be decreased when handling complex queries or many users. Still, enterprises that need to converge OLAP and OLTP into one common environment for real time decision making would likely be well served by adopting the HANA approach.  IBM’s BLU Acceleration: Optimized DB2 Database and Balanced System Performance   IBM’s DB2 with BLU Acceleration is designed to use in-memory columnar processing coupled with the dynamic movement of unused data to/from storage as needed. DB2 has long had a compression advantage over other major database competitors  –   but in addition to compression efficiency, BLU Acceleration is able to read compressed data (no decompression necessary), while also employing data-skipping algorithms to speed read compressed databases. Finally, BLU Acceleration takes advantage of processor level  parallel vector processing to exploit multi-core and SIMD (single instruction, multiple data) parallelism (SIMD instructions help improve parallel performance, which in turn helps to produce query results faster than systems that do not exploit SIMD). In short, IBM’s DB2 with BLU Acceleration can  be used with row or column-based data. In column mode, it has been reported to be 8 to 25x faster than traditional row-based rela tional databases (such as Oracle’s database). DB2 with BLU Acceleration is also NOT an in-memory database processing environme nt (like SAP’s HANA). Instead, it uses dynamic memory management caching techniques to off-load some data to near proximity fast storage. DB2 compression can reduce the size of Big Data databases more efficiently than Oracle or SAP. BLU Acceleration can read compressed data in memory without having to de- compress it (IBM’s BLU Acceleration uses advanced data -skipping techniques  –     both SAP’s HANA and Oracle’s Exadata do not use this in -memory compression approach). BLU Accel eration’s ability to read data in memory is a big advantage for BLU users when it comes to the speed of query completion. Also noteworthy, from a systems design perspective, IBM’s DB2 BLU Accelerator can be deployed on IBM POWER-based Power Systems as well as x86-based System x servers. Be-cause POWER processors can execute twice as many threads as their Intel counterparts, it is reasonable to expect that Power Systems are able to significantly outperform x86- based SAP and Oracle counterparts when running the same query.  IBM DB2 BLU Acceleration vs. SAP HANA vs. Oracle Exadata   Clabby Analytics http://www.clabbyanalytics.com Telephone: 001 (207) 846-6662 © 2013 Clabby Analytics ll rights reserved September, 2013 Clabby Analytics is an independent technology research and analysis organization. Unlike many other research firms, we advocate certain positions —  and encourage our readers to find counter opinions — then balance both points-of-view in order to decide on a course of action. Other research and analysis conducted by Clabby Analytics can be found at: www.ClabbyAnalytics.com. Summary Observations The bottom line in comparing these three Big Data architectures is that there are some commonalities in the ways that each vendor approaches Big Data analytics  –   but there are also some very distinct differences. These manifest themselves in database query pro-cessing speed; the number of concurrent users that can be supported; the affect that query complexity can have on system performance; system efficiency and optimization; and over-all manageability.  All three vendors (Oracle, SAP, and IBM) offer solid system designs capable of reading Big Data databases. Each approach has its merits  –   as well as its limitations. IBM’s DB2 BLU Acceleration, however, has several design advantages, including the ability to read compressed data and the use of SIMD processor calls to speed parallel processing performance. In our opinion, these differences should lead to IBM’s DB2 BLU  Acceleration delivering consistently higher performance at a lesser cost. For a more in depth technical overview of these technologies, see an expanded version of this report here. 
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks