InComparison. IBM DB2 with BLU Acceleration on Power Systems: how it compares

Transcription

1 InComparison IBM DB2 with BLU Acceleration on Power Systems: how it compares An InComparison Paper by Bloor Research Author : Philip Howard Publish date : April 2014

2 DB2 provides clients with a choice of running BLU Acceleration on x86 or on POWER and POWER provides advantages that you can t get from x86 offerings Philip Howard

3 Introduction Executive summary In this paper we consider the relative merits of IBM DB2 with BLU Acceleration running on Power Systems as compared to SAP HANA, Oracle Exadata and Microsoft SQL Server running on x86-based platforms. This follows on from a previous paper (published in 2013) in which Bloor Research was asked by IBM to compare the performance capabilities of the leading business analytic platforms. In our earlier paper we found that DB2 with BLU Acceleration out-performed its competition. In this paper we find that Power Systems offer substantial benefits to DB2 with BLU Acceleration users over and above those provided generically. Of course, on the surface it may appear that Power Systems are more expensive than x86-based platforms but, as our research indicates, this can be misleading because you are going to need more x86-based hardware to get the same performance and functionality as you would with Power Systems. So it is important to actually look into the details of the hardware required to support any particular environment. Details Specifically, we were asked to evaluate how the combined capabilities of business analytic tools and the underlying database management system can affect the overall performance of analytic applications, reports and dashboards. We looked at IBM Cognos BI running on DB2 with BLU Acceleration, SAP Business Objects running on SAP HANA, Oracle Business Intelligence Enterprise Edition (OBIEE) running on Oracle Exadata and Microsoft Business Intelligence running on Microsoft SQL Server Note that we were considering purely analytic environments and not combined OLTP/OLAP deployments. From both a theoretical perspective and based on benchmark results, we concluded that IBM offered better performance for the same analytic hardware configurations as its competitors and therefore, all other things (that is, software license fees) being equal, could offer better price/ performance. However, time has elapsed since that report was published and vendors do not stand still. For example, we reported in that paper that SAP HANA needs to decompress data to read it. This was our understanding at the time but it is certainly not the case today, although it is a fact that intermediate results have to be materialised. Nevertheless, we stand by the general conclusions in that report. IBM has now asked Bloor Research to extend this previous work to consider the impact of running DB2 on Power Systems, with the new POWER8 processor-based technology, as opposed to the x86 platforms used by its competitors. Of course, IBM also offers DB2 running on x86 platforms and if this is your preferred platform then you should refer to our previous paper. However, as this paper will make clear, we think that there are good arguments for x86 platforms not being preferred. This is both a general observation and a specific comment with respect to running DB2 with BLU Acceleration on a Power Systems platform. To simplify the discussion, we split this paper into two sections: A discussion of the database technologies under consideration and specifically what DB2 with BLU Acceleration brings to the table as compared to the architectures of Oracle, SAP and Microsoft. A discussion on Power Systems, as opposed to the x86 systems mandated by the likes of SAP and Oracle, and how it complements the DB2 BLU capabilities. A Bloor InComparison Paper Bloor Research

4 Database comparison In this section we will discuss each vendor s particular database capabilities that accelerate analytic performance. There are lots of database technologies that are well-known: massive parallelism, materialised views, indexes, partitions, optimisers and so forth, so we focused on some of the newer capabilities such as in-memory, columnar processing, compression and data skipping techniques used to find data more quickly, as these are the key new frontiers of database performance. Overall, SAP HANA has been designed as an in-memory database while DB2 with BLU Acceleration is best described as offering hybrid in-memory capabilities. By this we mean that if you want to keep all of your data in-memory then you can, in principle, do this; however, this may be cost prohibitive for very large datasets and DB2 with BLU Acceleration has been designed to allow hybrid options where only part of the data is in-memory at any one time. Oracle and Microsoft, on the other hand, despite any claims to the contrary, both use memory in a traditional manner for caching. SAP HANA is more or less completely columnar (in the sense that you will never normally use row storage, although it is an option) while DB2 with BLU Acceleration supports both row and column-based tables (and it is likely that you will use them both). SAP, Oracle and IBM provide improved compression via their columnar support. They are, of course, all databases, but their architectures are quite different. IBM DB2 with BLU Acceleration BLU Acceleration effectively does the following, which was not available in earlier versions of DB2: It introduces the use of actionable compression. The big advantage of this is that for many query processes you do not need to de-compress the data in order to query it. This is because the techniques now used for compression (known as frequencybased dictionary compression) preserve order. This means that predicate evaluation, joins, grouping and count queries can all be performed without de-compressing the data. It should further be noted that the rate of compression achieved by DB2 with BLU Acceleration is significantly improved using these techniques, when compared to previous versions of DB2. Data may be held in columnar format. This is not an all or nothing choice. Where it makes sense to use columns you can use columns and where it makes sense to use rows you can use rows combined with conventional indexes. We do not believe that we need to rehearse the value of using a columnar approach for appropriate query types. Note that column-organised tables do not have secondary structures, such as materialised query tables, thereby eliminating any need for synchronisation. It provides in-memory processing through what the company used to call dynamic in-memory (which has the benefit of being descriptive) and which it now calls next generation in-memory (which doesn t) capabilities that allow columns of data to reside in memory for query purposes. Unlike SAP HANA, which has been designed purely to provide in-memory capability, DB2 with BLU Acceleration has been designed on the premise that your data warehouse will always exceed the size of the memory that is available. Of course, you can always pay a fortune to have perhaps hundreds of terabytes of memory but that is an impractical proposition for most organisations. It advances the ZoneMap technology gained when IBM acquired Netezza. It calls this data skipping and the way that it works is that the database holds metadata about where data is stored and this allows you to skip those areas of the database where the data that the query requires is not stored. This can very significantly speed up relevant queries. It uses what used to be called parallel vector processing and is now described by IBM as CPU Acceleration. This is cross-core parallelism: you can parallelise across the cores within a single CPU as well as across sockets and parallelises Multiple Data elements per Single Instruction cycle in each core (SIMD). IBM claims one of their strengths is the efficiency of the parallelism made possible by some deep engineering to reduce memory access latency, in other words the time it takes to get data from RAM into the CPU where it can be processed. Most systems have a fair bit of memory access latency, but it gets disruptive across sockets. BLU Acceleration is doing something special to keep those latencies low Bloor Research A Bloor InComparison Paper

5 Database comparison One of the features of DB2 BLU is that you can actually use L3 cache (a form of CPU cache) to hold data in so that it ceases to be a question of RAM to CPU latency but one of L3 cache to CPU latency and the latter offers a better than an order of magnitude performance improvement over using RAM. There are some additional points we should make. Firstly, DB2 with BLU Acceleration is not available for use with the PureData family of products as yet. Secondly, it is not available on large shared nothing platforms although, having said that, we understand that IBM has run proofs of concept using DB2 with BLU Acceleration with warehouses well in excess of 100TB. Microsoft SQL Server The key feature of Microsoft SQL Server 2012 Parallel Data Warehouse is what is known as xvelocity. This provides memory-optimised columnstore indexes. This means that only the columns needed to satisfy a query need to be read. However, while this will improve performance where appropriate it will also worsen the performance of some other queries. You would like to have the optimiser work this out but as Microsoft states on its website, the cost models the optimiser uses are approximate and sometimes the optimiser chooses to use the columnstore index for a table when it would have been better to use a row store (B-tree or heap) to access the table. It then suggests using a work around. xvelocity also enables superior compression rates: either dictionary-based or using runlength encoding, depending on the type of data. However, we do not believe that this will give as good a rate of compression as IBM and data will need to be de-compressed in order to be queried. Oracle Exadata Oracle claims that Exadata is column-based. It is not. It uses columns to enable better rates of compression than it could get otherwise. Moreover, the data needs to be de-compressed when it is queried: the data is compressed in the storage server and, with only one or two exceptions; it needs to be decompressed after it is moved from there for query processing. It also claims to have in-memory capabilities. It does not. Its flash cache is exactly that: a cache (which is also located on the Storage Server and not the Database Server). What Exadata does have is Smart Scans. Further the usage of Exadata Hybrid Columnar Compression (EHCC) is not supported by SAP. Because of that the database can only be compressed with the standard OLTP compression technique. Support for large table scans is what Exadata, as an add-on to the Oracle database, was specifically designed to address. Put simply, it puts processing close to the disk to provide an MPP-like, shared nothing approach. Data is streamed off disk and pre-processed locally before the results are passed to the database itself for final processing. This results in faster table scans and reduced traffic across the network between the Storage Server and the database. The major weakness of this technique is that Smart Scans, which operate at a lower level than the database, are turned off if there is a write to the data page in question. In other words it will be best suited to static environments or situations where it is acceptable to update data on a periodic basis. If you are operating in real-time or near real-time mode then Smart Scans will need to be reserved only for that part of your queries that access historic data. A further issue with Smart Scans is that when they are used the data is decompressed in the Storage Server so that uncompressed rather than compressed data is passed to the database layer. One of the issues raised with respect to Oracle Exadata is workload management. Oracle assigns resources to queries on a first-come, first-served basis but if the load is high then later arriving queries get downgraded, receive fewer resources and therefore run more slowly. Furthermore, you can t increase resources to a query if the load subsequently decreases, meaning that resources are now idle. To avoid inconsistent response times and minimise idle resources, Oracle recommends queuing incoming queries so that it may more smoothly allocate the resources required. Unfortunately, in a high concurrency environment with many incoming queries, such as enterprise data warehousing, query queuing consumes a large amount of redo log space making it difficult or impossible for some workloads to use this technique to improve performance on a given system. Query queuing appears to be useful only in cases of limited concurrency and duration. A Bloor InComparison Paper Bloor Research

6 Database comparison In cases of workload management of mixed workloads, such as running OLTP and BI simultaneously on the same system, beware of workload isolation issues. For example, analytic queries have a tendency to overrun the system, with large amounts of Storage Server CPU being consumed to de-compress analytic query data, thereby slowing performance for OLTP operations. If this results in OLTP performance falling below SLA requirements then query performance will need to be throttled back. Ultimately, although Oracle offers controls to govern I/O consumed by a workload, there is no ability to control the Storage Server CPU consumed by a workload, making it difficult to isolate and maintain SLAs in a mixed workload environment. The other major thing that Exadata brings to the table is hardware. While extra hardware may improve performance you have to pay for this: literally. SAP HANA SAP HANA is an in-memory, columnar database system that runs only on x86 platforms. Unlike the other vendors discussed in this paper, the whole database has been designed to be held in memory. Standard SAP HANA configurations are up to a maximum of 1TB per server although the company has demonstrated (for example, recently in conjunction with Intel) that up to 4TB per server are practical. Beyond that you need to scale out rather than scale up. This purely in-memory approach has some advantages, such as the ability to support analytic views that do not require views to be materialised. In addition, it makes the environment suitable for hybrid OTLP/OLAP environments, but those are outside the scope of this paper. Column-stores enable a better compression rate, which, in theory at least, reduces storage requirements. You do not have to decompress data in order to query it. However, with SAP HANA, multiple copies of the in-memory data are stored for redundancy purposes and you also need a further copy for log space. In other words, most of what you gain on the swings you lose on the roundabouts: you would need a compression rate of approaching 90% to gain significant storage savings. In addition, as part of our research, we reviewed a report of free memory usage by SAP HANA during query evaluation. Data is loaded, in columns, into memory, but memory usage then repeatedly spiked, presumably because of the materialisation of intermediate objects during processing (so it is best practice to minimise the use of these). These are flushed from memory as soon as relevant joins are completed but performance will nevertheless suffer, though it is worth noting that this phenomenon may well apply to other database products as well. If you run out of memory then your query will fail though there is a facility to remove data from memory. In theory, memory usage should be ameliorated by the fact that HANA only loads relevant column data, although the extent to which this will help will vary depending on how many columns need to be read Bloor Research A Bloor InComparison Paper

7 Power Systems with POWER8 versus x86 processor-based servers IBM recently announced their first generation of systems built on POWER8 processor-based technology. There are a number of differences between x86 and POWER8 architectures. The POWER8 processor-based technology was designed for big data to run more concurrent queries in parallel faster, across multiple cores with more threads per core. They also have increased memory bandwidth and faster IO to ingest, move and access data faster. This allows companies to run these data-hungry analytics queries faster. In the context of this paper there are some features of Power Systems that complement BLU Acceleration and vice versa, and there are some that are independent of one another. In terms of the database, for example, the performance gains you get from data skipping and the storage savings resulting from actionable compression are specifically software gains that are not necessarily related to the hardware. On the other hand, if we consider the vector processing that BLU Acceleration provides (as does SAP HANA) then both x86 and Power platforms support this. However, the more cores and threads you have, the better this will work: and Power Systems just added 50% more cores: 8 per socket with POWER7+ and up to 12 with POWER8. Moreover, IBM doubled the threads per core: 4 with POWER7+ and 8 with POWER8. This substantially increases the per socket parallelism from 32 threads per socket for POWER7+ to 96 with POWER8. IBM has designed DB2 to automatically exploit the POWER8 processors hardware parallelism without requiring applications to be rewritten. That saves you time and money. DB2 also automatically exploits the larger page sizes available with POWER8 and aligns resource objects with the system architecture. This synergy of DB2 and Power Systems with POWER8 helps customers simplify deployment of database applications, achieve cost-effective largescale processing and consolidate workloads. Another point that is relevant, though it is not specific to DB2, with or without BLU Acceleration, is that virtualisation is built into Power Systems through microcode. Virtualising Power servers does not typically have a significant impact on performance (provided workloads are balanced) so, in a sense, can be ignored. However, that is not the case with x86 systems as virtualisation is not built-in. Now you have to install something such as VMware, which will take a significant chunk of the system s resources (as much as 20%) and thereby reduce performance. With Power Systems virtualisation, you can run the data warehouse and the analytics applications on the same server. That helps reduce the number of servers you need on the floor. Most companies will not do this with x86 due to performance limitations in virtualisation technologies. There are other factors: for example, Power Systems supports larger memory sizes, IBM offers capacity on demand for larger systems, and resiliency and security are more efficient in Power Systems. x86 processor-based solutions simply use redundancy, which is fine per se but means more servers, higher costs and higher levels of complexity to manage. The bottom line is that you could scale both x86 and POWER8 platforms to get the same levels of performance for a given workload, however you will have to use a lot more hardware to do so with x86 based solutions. Power Systems I/O bandwidth, parallel processing, large memory sizes, and trusted resiliency enable you to run more workloads on fewer physical servers. This helps you reduce hardware and energy costs while creating a more flexible IT infrastructure that is easier to manage. A Bloor InComparison Paper Bloor Research

8 Conclusion In our previous paper we concluded by saying that DB2 with BLU Acceleration should not only provide better performance in the first place but also provide consistent performance, with a corresponding requirement for less hardware and less cost when compared to Oracle Exadata, SAP HANA or Microsoft SQL Server all running in conjunction with the respective vendor s business intelligence suit. We stand by that conclusion, albeit that companies are always introducing new capabilities. However, even if that result was close (which it was not) it assumed a level playing field: that is, that the various vendor products were running on comparable hardware, in other words all on an x86 platform. DB2 provides clients with a choice of running BLU Acceleration on x86 or on POWER and, as even the short discussion presented here demonstrates, POWER provides advantages that you can t get from x86 offerings. IBM has optimised DB2 and Power Systems, with the new POWER8 processor-based technology, to enhance the performance of big data and analytics workloads. The combination of these integrated, workload optimised solutions helps reduce complexity and simplify management (with less hardware), and has the ability to deliver higher levels of performance while controlling costs. Further Information Further information is available from Bloor Research A Bloor InComparison Paper

9 Bloor Research overview Bloor Research is one of Europe s leading IT research, analysis and consultancy organisations. We explain how to bring greater Agility to corporate IT systems through the effective governance, management and leverage of Information. We have built a reputation for telling the right story with independent, intelligent, well-articulated communications content and publications on all aspects of the ICT industry. We believe the objective of telling the right story is to: Describe the technology in context to its business value and the other systems and processes it interacts with. Understand how new and innovative technologies fit in with existing ICT investments. Look at the whole market and explain all the solutions available and how they can be more effectively evaluated. Filter noise and make it easier to find the additional information or news that supports both investment and implementation. Ensure all our content is available through the most appropriate channel. Founded in 1989, we have spent over two decades distributing research and analysis to IT user and vendor organisations throughout the world via online subscriptions, tailored research services, events and consultancy projects. We are committed to turning our knowledge into business value for you. About the author Philip Howard Research Director - Data Management Philip started in the computer industry way back in 1973 and has variously worked as a systems analyst, programmer and salesperson, as well as in marketing and product management, for a variety of companies including GEC Marconi, GPT, Philips Data Systems, Raytheon and NCR. After a quarter of a century of not being his own boss Philip set up his own company in 1992 and his first client was Bloor Research (then ButlerBloor), with Philip working for the company as an associate analyst. His relationship with Bloor Research has continued since that time and he is now Research Director focused on Data Management. Data management refers to the management, movement, governance and storage of data and involves diverse technologies that include (but are not limited to) databases and data warehousing, data integration (including ETL, data migration and data federation), data quality, master data management, metadata management and log and event management. Philip also tracks spreadsheet management and complex event processing. In addition to the numerous reports Philip has written on behalf of Bloor Research, Philip also contributes regularly to IT-Director.com and IT-Analysis.com and was previously editor of both Application Development News and Operating System News on behalf of Cambridge Market Intelligence (CMI). He has also contributed to various magazines and written a number of reports published by companies such as CMI and The Financial Times. Philip speaks regularly at conferences and other events throughout Europe and North America. Away from work, Philip s primary leisure activities are canal boats, skiing, playing Bridge (at which he is a Life Master), dining out and walking Benji the dog.

10 Copyright & disclaimer This document is copyright 2014 Bloor Research. No part of this publication may be reproduced by any method whatsoever without the prior consent of Bloor Research. Due to the nature of this material, numerous hardware and software products have been mentioned by name. In the majority, if not all, of the cases, these product names are claimed as trademarks by the companies that manufacture the products. It is not Bloor Research s intent to claim these names or trademarks as our own. Likewise, company logos, graphics or screen shots have been reproduced with the consent of the owner and are subject to that owner s copyright. Whilst every care has been taken in the preparation of this document to ensure that the information is correct, the publishers cannot accept responsibility for any errors or omissions. POL03194-USEN-00

11 2nd Floor, St John Street LONDON, EC1V 4PY, United Kingdom Tel: +44 (0) Fax: +44 (0) Web: