Relational vs. purexml: Battle of the Titans

Transcription

1 Relational vs. purexml: Battle of the Titans Konstantin Tadenev UPS Session Code: G04 May 3, :30 p.m. 5:30 p.m. Platform: DB2 for z/os and DB2 for Linux, UNIX, and Windows Abstract The author and his colleagues conducted a comparative performance study where they addressed a real-life business problem first with traditional relational database means and then with purexml. The relational solution was an exact replica of a production application. The study was conducted in DB2 9.5 and 9.7 for Linux and DB2 9.1 for z/os. The results illustrate considerable throughput improvements and CPU time savings for the purexml solution. 1

2 Acknowledgements This study was a result of a collaborative effort. Here is the team s composition (by role played): UPS Core team: Konstantin Tadenev, Database Administration, Project Coordination, etc. Mike Smith, Application Design, OS Administration, etc. IBM Advisory Team Susan Malaika, DB2 purexml Advocate Peter Shum, DB2 for LUW Performance Adviser Kevin Xie, DB2 for LUW Performance Adviser Akiko Hoshikawa, DB2 for z/os Performance Adviser Jason A. Cu, DB2 for z/os Performance Adviser Guogen Zhang, DB2 for z/os Performance Adviser Many thanks to all on the team! 2 The UPS team conducted periodic reviews with IBM in an effort to ensure optimal configuration of the test environments and to validate the test results.

3 Agenda Selecting a business problem to be solved by purexml means Configuring purexml environment for best performance Capturing performance measurements Comparative performance study results Z-series specialty engines and purexml workload Conclusions 3 Susan Malaika and Matthias Nicola of IBM outlined some of the common purexml use cases in their DeveloperWorks presentation published in May of 2010*. These use cases primarily exploit the unique functionality of purexml. We were interested to see if we could identify other use cases in which the purexml functionality gains would be augmented by performance, capacity and cost savings over traditional relational design. One of these use cases is being examined in this section of the presentation. * Malaika, Susan and Nicola, Matthias (2010, May 18). XML Use Cases: Customer Strategies and Experiences. Retrieved from

4 Units of Business Data (UBD) and Relational Technologies Often business deals with relatively large consistent sets of data as one unit These Units of Business Data (UBD) need to be persisted in a digital data resource (e.g. a database) Relational technologies solve this problem by taking a UBD apart during write, persisting its components, typically in multiple rows of multiple tables, and re-assembling the UBD on read Taking a UBD apart and putting it back together requires computing resources, and ultimately contributes to higher cost 4 In our case, these relatively large units of business data measured predominantly in single KB with some deviations exceeding 1 MB

5 A UBD in Relational DB Analogy Treatment of UBD in relational databases may be compared to taking a car apart every time it is parked and putting it back together every time it needs to be driven 5 An analogy to taking the data apart on write and putting it back together on read

6 Relational vs. purexml Question: Is there a cost advantage of PureXML over traditional relational solutions in meeting the UBD challenge? If so, what is the scale of potential cost savings? 6 The problem statement of our study Cost is understood here as hardware and software cost driven by capacity requirements such as CPU time, throughput, etc.

7 Agenda Selecting a business problem to be solved by purexml means Configuring purexml environment for best performance Capturing performance measurements Comparative performance study results Z-series specialty engines and purexml workload Conclusions 7 This section discusses our efforts to optimize performance and capacity for both competing solutions: relational and purexml

8 Comparative Performance Study: System Under Test Application Java JMeter for workload and thread control Selected tests were re-run using TPoX to generate mixed workload 7 application servers x86 commodity servers Phase 1 Red Hat Enterprise Linux bit Phase 2 Red Hat Enterprise Linux bit 8 See more on JMeter at See more on TPoX at

9 Comparative Performance Study: System Under Test Database Linux HW: HP ProLiant DL585 G5 (Intel s Dunnington system); 16 cores; 2.411GHz; 32 GB RAM; 2 Gb network; disk SAN (IBM) Phase 1 Red Hat Enterprise Linux bit DB2 9.5 Fixpack 4 Phase 2 Red Hat Enterprise Linux bit DB2 9.7 Fixpack 1 9 DL585 G5 had 4 processors, 4 cores each. See the manufacturer s server specifications at html

10 Comparative Performance Study: System Under Test Database z/os HW: Processor type ; 2,755 MIPS Engines: 2 GPP; 1 ziip; 2 zaap z/os 1.10 DB Please see IBM z10 Enterprise Class 2097 Mainframe reference here:

11 Test Setup Relational: Java app Mockup of an existing production app Running on app servers (separate from the DB server) 12 tables 13 indexes Workload types Inquiry 15 queries are needed to re-assemble one UBD Multi-user OLTP workload simulation INSERT Multi-row INSERT Tuned for optimal performance 500 rows per COMMIT 11 The existing production application was written in COBOL. We extracted most resourceintensive portion of the code, and converted it to Java. All original queries were migrated to the test application without any modifications other than those required by the host language. The multi-user OLTP simulation was accomplished by means of JMeter and TPoX. Tuning for optimal performance included BP thresholds, free space (index and data), locking, APPEND option, etc.

12 Test Setup PureXML: Java app Existing production app redesigned for purexml Running on app servers (separate from the DB server) Data and business cases identical with the relational test cases 1 table designed to support the same UBD 1 index XML doc size varied from 1K to over 1M with average just under 2K Workload types Inquiry Only 1 query is needed to retrieve a UBD do not need to re-assemble Multi-user OLTP workload simulation INSERT Same as relational, but inserting into 1 table rather than Java app the same functionality and the same business logic as the relational counterpart. Inquiry a SQL/XML statement similar to this (non-public metadata is replaced with generic names): SELECT DOC FROM myschema.tdoc WHERE XMLEXISTS ('$DOC/Node1[Node2/myKey = $c]' passing cast(? as varchar(35)) as "c") WITH UR Insert a SQL/XML statement similar to this: INSERT INTO myschema.tdoc(doc) VALUES (? ) with CS

13 Use Case in purexml Study Relational Application purexml Application 13 Each UBD was represented by data stored in one or more than one row in each of the 12 relational tables. The same UBD was represented by one XML document in purexml Each XML document contained one or more than one index key value.

14 Key Design Decisions Linux Kernel parameter settings (see notes for details) Separate buffer pools and table spaces for data, index and temp All 32K PAGESIZE All table spaces MANAGED BY DATABASE In-lining XML: maximum INLINE LENGTH as to fill-in the balance of the 32K page FILE SYSTEM CACHING for TEMPSPACE1 Reliance on AUTOCONFIGURE for Optimizing size and number of logs IO management Checkpoints Buffer pool tuning, etc. 14 We had to adjust the kernel parameter settings manually since we were running DB2 9.7 fixpack 1, where automatic adjustments of kernel parameter settings were not yet available. They became available with fixpack 2. Please refer to the InfoCenter documentation for details:

15 Memory Management for purexml: DB2 9.5 and 9.7 Differences DB2 9.5 FP4 We experienced challenges tuning the environment in a way that would afford optimal performance/capacity conditions for the relational and purexml workloads to co-exist in the same database Remedy: We isolated the equivalent relational and purexml workloads into their own databases and ran each workload type separately Turned off self-tuning memory in the purexml database Tuned sort-related memory manually Sort heap size (SORTHEAP) Sort heap threshold for shared sorts (SHEAPTHRES_SHR) Buffer pool size for 32K TEMP, etc. DB2 9.7 FP1 The self-tuning memory appeared to be making optimal choices there was no need for the remedy described above 15 sortheap - Sort heap size configuration parameter This parameter defines the maximum number of private memory pages to be used for private sorts, or the maximum number of shared memory pages to be used for shared sorts. sheapthres_shr - Sort heap threshold for shared sorts configuration parameter This parameter represents a soft limit on the total amount of database shared memory that can be used by sort memory consumers at any one time.

16 Key Design Decisions z/os tuning Tuned OPT parameters to ensure more accurate capacity planning across GPP and ziip (and/or zaap) engines. These parameters can be found in SYS1.PARMLIB (IEAOPTxx): ZIIPAWMT specifies an Alternate Wait Management (AWM) value for System z Integrated Information Processors (ziips) IBM-recommended value: 500 to 800 µs assuming HiperDispatch is not turned on. See more on HiperDispatch in the notes IIPHONORPRIORITY IBM-recommended value: YES. This ensures that standard processors can help each other as well as ziip processors as to meet WLM goals z/os and DB2 maintenance Be at the most current maintenance level! 16 ZIIPAWMT Specifies an Alternate Wait Management (AWM) value for IBM System z Integrated Information Processors (ziips) to minimize LPAR low utilization effects and overhead. In an LPAR, some n-way environments with little work may appear to have little capacity remaining because of the time spent waking up idle ziips to compete for individual pieces of work. The ZIIPAWMT parameter allows you to reduce this time so that capacity planning is more accurate and CPU overhead is reduced, even though arriving work might wait a longer time before being dispatched. HiperDispatch In system z some CPUs are physically "closer (read faster access) to the cache memory that might hold supporting data for particular tasks. HiperDispatch exploits this fact and steers tasks to the CPUs most likely to have the fastest access to the relevant data already in cache. If that particular CPU is busy, HiperDispatch will first wait for it to finish its other task, even if another, less favorable CPU, is idle. However, there are limitations to how patient HiperDispatch will be, as governed by Workload Manager goals. If z/os Workload Manager senses that there's a risk that the pending task will miss its service level, Workload Manager and HiperDispatch will send the task over to an idle CPU for processing, even if that CPU must fetch data from slower main memory. See more at IIPHONORPRIORITY Specifies that standard processors run both ziip-processor-eligible and non-ziip-processoreligible work in priority order when the ziip processors indicate the need for help from standard processors. The need for help is determined by the alternate wait management (AWM) function. Standard processors help each other, and standard processors can also help ziip processors if YES is in effect. IBM suggests that you specify or default to IIPHONORPRIORITY=YES.

17 Key Design Decisions z/os Buffer pools: Separate 16K pools: one for data and one for User and systemcreated indexes 32K pool for sort No workload-manager-adjusted buffer pools (AUTOSIZE(YES))* Assigning table spaces to buffer pools When a table is created with one or more than one XML columns, DB2 creates table spaces under the covers. The names of these table spaces are generated by DB2. Unlike indexes, implicitly-created table spaces do not inherit BP assignments from the DB definition, instead, they inherit the BP assignments from the TBSBPXML ZPARM Remedy: alter the table space (or spaces) to achieve the desired BP assignment *Workload-managed buffer pool adjustments were not yet available at the time of our testing. They were introduced later via DB2 APAR PK75626 (PTF UK53198), z/os APAR OA18461 and OA The 16k and 32k buffer pools had 7,500 pages each. More on WLM buffer pool adjustments: ibm.com/support/docview.wss?mynp=OCSSEPEK&mync=E&uid=swg1PK 75626&myns=swgimgmt

18 A Table Space BP Assignment Result SELECT NAME,BPOOL FROM SYSIBM.SYSTABLESPACE WHERE DBNAME = MYDB' WITH UR ; NAME BPOOL MYTS BP16K1 XTSH0000 BP16K1 DB2-generated table space with the BP value altered to the desired 16K BP 18 Note the DB2-generated table space name XTSH0000 and its new buffer pool assignment the result of ALTER TABLESPACE

19 Key Design Decisions z/os Assigning indexes to buffer pools When a table is created with an XML column, DB2 creates indexes under the covers. The names of those indexes are generated by DB2, and they will pick up their buffer pool specification from the IDXBPOOL ZPARM or INDEXBP value on the CREATE DATABASE statement Good practice: always specify INDEXBP when creating or altering databases with purexml 19 See more on INDEXBP at sqlref/db2z_sql_createdatabase.htm

20 Index-to-buffer-pool Assignment Example CREATE DATABASE MYDB BUFFERPOOL BP16K1 INDEXBP BP16K2 CCSID UNICODE; CREATE TABLE MYSCHEMA.MYTABLE (XML_COLUMN XML) IN MYDB.MYTS; CREATE INDEX MYSCHEMA.MYINDEX ON MYSCHEMA.MYTABLE (XML_COLUMN) GENERATE KEY USING XMLPATTERN '/mynodea/mynodeb/mynodec' AS SQL VARCHAR ( 35 ) ; 20 This slide shows a DDL that would result in assignment of IBM-generated indexes to the buffer pool BP16K2

21 Index-to-buffer-pool Assignment Result IXNAME BPOOL I_DOCIDMYTABLE BP16K2 I_NODEIDXMYTABLE BP16K2 MYINDEX BP16K2 These indexes were created implicitly upon execution of the CREATE TABLE MYSCHEMA.MYTABLE statement 21 Note consistent buffer pool assignments to all indexes in this example.

22 Agenda Selecting a business problem to be solved by purexml means Configuring purexml environment for best performance Capturing performance measurements Comparative performance study results Z-series specialty engines and purexml workload Conclusions 22 This section discusses test execution rules as well as tools and methods for capturing performance results.

23 Running the Test in Linux Continuous consistent workload in each test run The database server was loaded at approximately 70% CPU utilization level with fluctuations not exceeding 1% throughout all test phases Each test run contained two phases Phase 1 a 30-minute warm-up period in the beginning of each test Run full workload for the duration of the warm-up Prime buffer pools Allow self-tuning features adapt to the workload Phase 2 a 60-minute test-proper period. All performance and capacity measurements captured in this phase were saved for further analysis 23 We determined that the 30-minute warm-up period was optimal by graphing the CPU time curve from the start of the test to the stable state.

24 Capturing Performance Measurements in Linux Database server CPU utilization Linux sar utility* Process CPU time Linux top utility* Throughput Collected by the application as number of concurrent users and number of transactions per second at 70% database server CPU utilization level * See the notes for command line examples 24 The following sar command takes second measurements. The first 30 for the warm-up period, and the next 60 for the test proper. This command was used to measure CPU utilization at the database server #sar -o data.file interval count nohup sar -o $SAR_OUTPUT_FILE > /dev/null 2>&1 & We synchronized the top command measurements with those of sar. Again, we have 90 measurements, each was taken with a 60-second delay. This command helped us capture CPU time for the process. # top -d = delay - n = number nohup top -b -d 60 -n 90 >> $TOP_OUTPUT_FILE &

25 Running and Measuring the Test on z/os The test iterations were run in a dedicated subsystem on a shared LPAR Constant number of concurrent users Constant number of transactions for each test interval Each test interval 15 minutes The first test interval warm-up (prime buffer pools, etc.) Measurements: DB2 Performance Expert Statistics Report 25 The 15-minute increments were chosen to satisfy the request of our capacity and performance group, which helped them with establishing another perspective on testing via a set of UPS-standard performance reports. These reports are summarized every 15 minutes one can never say no to more validation

26 Reporting CPU Time in DB2 PE Statistics Report CPU TIMES TOTAL TIME PREEMPT IIP SRB SYSTEM SERVICES ADDRESS SPACE N/A DATABASE SERVICES ADDRESS SPACE IRLM N/A DDF ADDRESS SPACE TOTAL General Purpose Processor Time ziip Time 26 DB2 can generate parallel tasks for the efficient execution of queries. Parallel tasks are executable units composed of special SRBs (service request block), which are called preemptable SRBs. With preemptable SRBs, the z/os dispatcher can interrupt a task at any time to run other work at the same or higher dispatching priority. For non-distributed parallel work, parallel tasks run under a type of preemptable SRB, which is called a client SRB. The client SRB lets the parallel task inherit the importance of the originating address space. For distributed requests, the parallel tasks run under a preemptable SRB, which is called an enclave SRB. In this example, the client requests came through TCP/IP as distributed threads without using parallelism. DB2 uses enclave SRBs for distributed threads and portions of enclave SRBs running on DRDA are eligible to run on a ziip. Thus the overall CPU time consumed by DB2 and the application processes during the test period is comprised of the General Purpose Processor Time ( TOTAL TIME I know, it seems like a misnomer to me too ) and ziip time (PREEMPT IIP SRB)

27 Agenda Selecting a business problem to be solved by purexml means Configuring purexml environment for best performance Capturing performance measurements Comparative performance study results Z-series specialty engines and purexml workload Conclusions 27 This section contains a representative subset of capacity and performance measurements

28 Comparative Performance Study Results The test results were consistent with low error margins We selected a representative subset of the test cases, large enough to illustrate the key statistics, and yet small enough to fit the format of this presentation 28 We measured the margin of error across the entire population of measurements for each test case.

29 purexml vs. Relational on Linux: CPU Time purexml Relational 0.00 CPU Seconds per 1 K Transactions 59% CPU Time Savings 29 This chart shows mean CPU time per 1,000 transactions at 70% CPU utilization at the database server. The process multi-user OLTP-style inquiry. There was no mixed workload in this test case. On average, the relational process consumed 1.53 CPU seconds per 1,000 transactions, while its purexml counterpart used only 0.63 CPU seconds, which represented 59% CPU time savings.

30 purexml vs. Relational on Linux: Throughput Number of Concurrent Users Number of concurrent users at 70% CPU utilization at the database server 3X improvement purexml Relational 30 This is a graph depicting the number of concurrent users for the test case shown on the previous slide. The relational workload was burning 70% CPU at the database server with 63 concurrent users, while purexml allowed to increase the number of users to 200 at the same CPU utilization level over 3X improvement!

31 purexml vs. Relational on Linux: Throughput TPS 20,000 15,000 10,000 5,000 purexml Relational 0 TPS at 70% CPU utilization at the database server 5X improvement 31 The same test case again. This chart shows differences in the number of transactions per second at 70% CPU utilization level. Again, purexml outperformed the competition with 17,899 transactions per second vs. 3,645 in the relational workload an impressive 5-fold lead!

32 purexml vs. Relational on z/os: CPU Time purexml Relational CPU Seconds per 1K Transactions 51% CPU Time Savings 32 This is a similar test case in DB2 9 for z/os. Still very impressive CPU time savings, 51%, albeit somewhat lower than those on the Linux platform (compare with 59% savings shown on slide 29). In our opinion, DB2 shows better results on Linux due to the XML in-lining feature available in DB2 9.7 for LUW, but not yet available in DB2 9.1 for z/os. Please note that the CPU time posted in this chart is a sum of ziip and General Purpose Processor (GPP) time.

33 Advantages of purexml vs. Relational: General Observations In purexml the same business case causes different behavior: Substantially fewer database calls Substantially fewer GETPAGES Substantially less work for the application: the data does not need to be taken apart on write or re-assembled on read 33 As we anticipated, DB2 does less work when handling relatively large consistent units of business data in purexml than it does in the traditional relational scenario

34 Advantages of purexml vs. Relational: General Observations Results Sizeable capacity savings and performance gains purexml CPU time savings over relational: Generally higher in DB2 9.7 for LUW compared to DB2 9.1 for z/os likely due to the efficiencies introduced with XML in-lining, which is available in DB2 9.7 for LUW, but not in DB2 9.1 for z/os Generally higher for read than for write due to some savings being offset by the XML parsing overhead with the latter 34 The observations captured on this slide pertain to all test cases run, whether or not shown here as graphs.

35 Agenda Selecting a business problem to be solved by purexml means Configuring purexml environment for best performance Capturing performance measurements Comparative performance study results Z-series specialty engines and purexml workload Conclusions 35 This section focuses on the effects of purexml workloads on utilization of z-series specialty engines

36 CPU Time Distribution by Engine Type in purexml Database Reads on z/os 55% 45% General Purpose ziip 36 As we illustrated on the previous slides, we were able to save more than 50% of CPU time running the target workload in purexml rather than traditional relational design. Let us further examine some savings by means of off-loading to the z-series specialty engines. You may recall that our test application was connecting to DB2 via JDBC and DRDA, which made the entire workload (purexml and relational) ziip-eligible. This chart shows that the purexml ziip off-load on the database read requests reached the maximum allowable level 55%. Please note that since the time of this experiment IBM has increased the portion of DRDA workloads authorized to run on a ziip from 55% to 60% via APAR PM12256.

37 CPU Time Distribution by Engine Type in purexml Database Writes on z/os 58% 42% General Purpose ziip 37 It is quite interesting to see that ziip off-load exceeds the 55% ceiling in the test cases involving purexml writes. The additional ziip off-load comes from XML parsing. Each document or document snippet arriving from the application to the database with an INSERT or UPDATE statement needs to be parsed before it is persisted in DB2. Up to 55% of conventional DRDA workload could be off-loaded to ziip (this number has increased to 60% since the time of this study as per APAR PM12256). In contrast, purexml parsing is 100% off-loadable. Please note that in local workloads XML parsing would go to zaap rather than ziip.

38 Specialty Engines Behavior with purexml In our case, the entire workload arrived across DRDA, which made it ziip-eligible We reached maximum allowable ziip offload with our read tasks 55%* ziip offload with writes 58%. Higher than maximumallowed? XML parsing is 100% ziip or zaap eligible and off-loadable In this case, the additional 3% of ziip off-load must be attributed to XML parsing * Since the time of this experiment IBM has increased the portion of DRDA workloads authorized to run on a ziip from 55% to 60% via APAR PM A summary of ziip off-load trends

39 Agenda Selecting a business problem to be solved by purexml means Configuring purexml environment for best performance Capturing performance measurements Comparative performance study results Z-series specialty engines and purexml workload Conclusions 39 And in conclusion

40 Study Conclusions PureXML exhibits substantial capacity and performance advantages over relational DB when dealing with relatively large consistent sets of data Our tests captured measurements of these advantages in CPU savings CPU offload to z-series specialty engines Throughput 40 One size does not fit all. Our study illustrates purexml advantages over relational for relatively large consistent units of business data, which is just one use case out of many. Obviously, there are other use cases, for which relational design is the best choice in terms of flexibility, performance and capacity. Keep an open mind!

41 Konstantin Tadenev UPS Session: G04 Relational vs. purexml: Battle of the Titans Konstantin Tadenev is a data architect at UPS responsible in part for analysis and proof of new and emerging data management technologies as they pertain to present and anticipated future use cases. Konstantin has extensive DB2 experience as a hands-on practitioner, IT manager and published author. Konstantin has spoken many times at IDUG conferences, being named among the 10 best user speakers. 41