Your SlideShare is downloading. ×
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details

1,513

Published on

Third presentation in a speaker series sponsored by the Portland State University Computer Science Department. The series covers PostgreSQL performance with an OLTP (on-line transaction processing) …

Third presentation in a speaker series sponsored by the Portland State University Computer Science Department. The series covers PostgreSQL performance with an OLTP (on-line transaction processing) workload called Database Test 2 (DBT-2). This presentation go into detail about what the workload does.

Published in: Technology
1 Comment
1 Like
Statistics
Notes
  • The PDF isn't blank, download it if you can.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
1,513
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
81
Comments
1
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. PostgreSQL Portland Performance Practice Project Database Test 2 (DBT-2) Details Mark Wong markwkm@postgresql.org Portland State University February 12, 2009
  • 2. Review From last time: Series overview. ◮ DBT-2 background. ◮ __ __ / ~~~/ . o O ( Questions? ) ,----( oo ) / __ __/ /| ( |( ^ /___ / | |__| |__|-quot;
  • 3. Contents Diving into the DBT-2 test kit. Workload description ◮ Architecture ◮ Database Schema and Sizing ◮ Transactions ◮ Description ◮ SQL ◮ Note: Default kit behavior will be covered, but almost all parameters are changeable.
  • 4. Workload Description Simulate wholesale supplier processing orders. (Manage, sell, ◮ distribute products or services.) A basic set of operations representing a complex OLTP ◮ application environment. For example, someone at a terminal (in no particular order): checks the stock levels in the warehouse. ◮ enters a new order for items the supplier sells. ◮ searches for the status of an order. ◮ enters payment for an order. ◮ processes an order for delivery. ◮
  • 5. DBT-2 Components
  • 6. Database Schema Diagram
  • 7. Database Schema Notes 9 Tables ◮ No foreign key constraints ◮ __ __ / / ~~~/ . o O | Is this a good schema | ,----( oo ) | design? | / __ __/ / /| ( |( ^ /___ / | |__| |__|-quot;
  • 8. Scale Factor Determines database size. ◮ Determines number of users driving the workload. ◮
  • 9. Scale Factor’s effect on database row counts Let W be the scale factor, which determines the starting size of the database1 : warehouse has W warehouses ◮ district has 10 districts per warehouse ◮ customer has 3,000 customers per district ◮ history has about a row per customer ◮ orders has about a row per customer ◮ order line has 5-15 items per order ◮ About 30% of the orders are new in new order ◮ item is fixed with 100,000 items in the company ◮ stock stocks 100,000 items per warehouse ◮ 1 TPC-C Benchmark Specification v5.9 Clause 1.2.1
  • 10. Scale Factor’s effect on database table size Numbers are in 1,000 bytes per Warehouse in the database 2 : warehouse - 0.089 ◮ district - 0.950 ◮ customer - 19,650 ◮ history - 1,380 ◮ orders - 720 ◮ order line - 16,200 ◮ new order - 72 ◮ item - 8,200 ◮ stock - 30.600 ◮ 2 TPC-C Benchmark Specification v5.9 Clause 4.2.2
  • 11. Scale Factor’s effect on table row size Numbers are in bytes per Warehouse in the database 3 : warehouse - 89 ◮ district - 95 ◮ customer - 655 ◮ history - 146 ◮ orders - 24 ◮ order line - 54 ◮ new order - 8 ◮ item - 82 ◮ stock - 306 ◮ 3 TPC-C Benchmark Specification v5.9 Clause 4.2.2
  • 12. DBT-2 Transactions Now descriptions of the 5 transactions and the SQL statements executed in each transaction. Delivery - Read/Write ◮ New Order - Read/Write ◮ Order Status - Read Only ◮ Payment - Read/Write ◮ Stock Level - Read Only ◮ Note: Color coded in an attempted to match upcoming charts. Read ◮ Write ◮ Read/Write ◮
  • 13. Delivery Transaction Description The Delivery business transaction consists of processing a batch of 10 new (not yet delivered) orders. Each order is processed (delivered) in full within the scope of a read-write database transaction. The number of orders delivered as a group (or batched) within the same database transaction is implementation specific. The business transaction, comprised of one or more (up to 10) database transactions, has a low frequency of execution and must complete within a relaxed response time requirement. The Delivery transaction is intended to be executed in deferred mode through a queuing mechanism, rather than interactively, with terminal response indicating transaction completion. The result of the deferred execution is recorded into a result file.4 4 TPC-C Benchmark Specification v5.9 Clause 2.7
  • 14. Delivery Table Touches
  • 15. Delivery SQL Statements For every district in the table: SELECT no_o_id UPDATE order_line FROM new_order SET ol_delivery_d = current_timestamp WHERE no_w_id = %d WHERE ol_o_id = %s AND no_d_id = %d AND ol_w_id = %d AND ol_d_id = %d DELETE FROM new_order WHERE no_o_id = %s SELECT SUM(ol_amount * ol_quantity) AND no_w_id = %d FROM order_line AND no_d_id = %d WHERE ol_o_id = %s AND ol_w_id = %d SELECT o_c_id AND ol_d_id = %d FROM orders WHERE o_id = %s UPDATE customer AND o_w_id = %d SET c_delivery_cnt = c_delivery_cnt + 1, AND o_d_id = %d c_balance = c_balance + %s WHERE c_id = %s UPDATE orders AND c_w_id = %d SET o_carrier_id = %d AND c_d_id = %d WHERE o_id = %s AND o_w_id = %d AND o_d_id = %d
  • 16. New Order Transaction Description The New-Order business transaction consists of entering a complete order through a single database transaction. It represents a mid-weight, read-write transaction with a high frequency of execution and stringent response time requirements to satisfy on-line users. This transaction is the backbone of the workload. It is designed to place a variable load on the system to reflect on-line database activity as typically found in production environments.5 5 TPC-C Benchmark Specification v5.9 Clause 2.4
  • 17. New Order Table Touches
  • 18. New Order SQL Statements For 10 to 15 items (1% of transaction fail here causing a SELECT w_tax ROLLBACK): FROM warehouse WHERE w_id = %d SELECT i_price, i_name, i_data SELECT d_tax, d_next_o_id FROM item FROM district WHERE i_id = %d WHERE d_w_id = %d AND d_id = %d SELECT s_quantity, %s, s_data FOR UPDATE FROM stock WHERE s_i_id = %d UPDATE district AND s_w_id = %d SET d_next_o_id = d_next_o_id + 1 WHERE d_w_id = %d UPDATE stock AND d_id = %d SET s_quantity = s_quantity - %d WHERE s_i_id = %d SELECT c_discount, c_last, c_credit AND s_w_id = %d FROM customer WHERE c_w_id = %d INSERT INTO order_line (l_o_id, ol_d_id, ol_w_id, AND c_d_id = %d ol_number, ol_i_id, AND c_id = %d ol_supply_w_id, ol_delivery_d, INSERT INTO new_order (no_o_id, no_w_id, no_d_id) ol_quantity, VALUES (%s, %d, %d) ol_amount, ol_dist_info) VALUES (%s, %d, %d, %d, %d, %d, NULL, %d, %f, INSERT INTO orders (o_id, o_d_id, o_w_id, o_c_id, ’%s’) o_entry_d, o_carrier_id, o_ol_cnt, o_all_local) VALUES (%s, %d, %d, %d, current_timestamp, NULL, %d, %d)
  • 19. Order Status Transaction Description The Order-Status business transaction queries the status of a customer’s last order. It represents a mid-weight read-only database transaction with a low frequency of execution and response time requirement to satisfy on-line users. In addition, this table includes non-primary key access to the CUSTOMER table.6 6 TPC-C Benchmark Specification v5.9 Clause 2.6
  • 20. Order Status Table Touches
  • 21. Order Status SQL Statements Get the customer ID (c id) only if it is not already known. SELECT c_id SELECT ol_i_id, ol_supply_w_id, ol_quantity, FROM customer ol_amount, ol_delivery_d WHERE c_w_id = %d FROM order_line AND c_d_id = %d WHERE ol_w_id = %d AND c_last = ’%s’ AND ol_d_id = %d ORDER BY c_first ASC AND ol_o_id = %s SELECT c_first, c_middle, c_last, c_balance FROM customer WHERE c_w_id = %d AND c_d_id = %d AND c_id = %d SELECT o_id, o_carrier_id, o_entry_d, o_ol_cnt FROM orders WHERE o_w_id = %d AND o_d_id = %d AND o_c_id = %d ORDER BY o_id DESC
  • 22. Payment Transaction Description The Payment business transaction updates the customer’s balance and reflects the payment on the district and warehouse sales statistics. It represents a light-weight, read-write transaction with a high frequency of execution and stringent response time requirements to satisfy on-line users. In addition, this transaction includes non-primary key access to the CUSTOMER table.7 7 TPC-C Benchmark Specification v5.9 Clause 2.5
  • 23. Payment Table Touches
  • 24. Payment SQL Statements (part 1/2) Get the customer ID (c id) if not already known. SELECT w_name, w_street_1, w_street_2, w_city, w_state, w_zip SELECT c_id FROM warehouse FROM customer WHERE w_id = %d WHERE c_w_id = %d AND c_d_id = %d UPDATE warehouse AND c_last = ’%s’ SET w_ytd = w_ytd + %f ORDER BY c_first ASC WHERE w_id = %d SELECT c_first, c_middle, c_last, c_street_1, SELECT d_name, d_street_1, d_street_2, d_city, c_street_2, c_city, c_state, c_zip, d_state, d_zip c_phone, c_since, c_credit, c_credit_lim, FROM district c_discount, c_balance, c_data, WHERE d_id = %d c_ytd_payment AND d_w_id = %d FROM customer WHERE c_w_id = %d UPDATE district AND c_d_id = %d SET d_ytd = d_ytd + %f AND c_id = %d WHERE d_id = %d AND d_w_id = %d
  • 25. Payment SQL Statements (part 2/2) If the customer has good credit: UPDATE customer SET c_balance = c_balance - %f, c_ytd_payment = c_ytd_payment + 1 WHERE c_id = %d AND c_w_id = %d AND c_d_id = %d Otherwise if the customer has bad credit: UPDATE customer SET c_balance = c_balance - %f, c_ytd_payment = c_ytd_payment + 1, c_data = E’%s’ WHERE c_id = %d AND c_w_id = %d AND c_d_id = %d INSERT INTO history (h_c_id, h_c_d_id, h_c_w_id, h_d_id, h_w_id, h_date, h_amount, h_data) VALUES (%d, %d, %d, %d, %d, current_timestamp, %f, E’%s %s’)
  • 26. Stock Level Transaction Description The Stock-Level business transaction determines the number of recently sold items that have a stock level below a specified threshold. It represents a heavy read-only database transaction with a low frequency of execution, a relaxed response time requirement, and relaxed consistency requirements.8 8 TPC-C Benchmark Specification v5.9 Clause 2.8
  • 27. Stock Level Table Touches
  • 28. Stock Level SQL Statements SELECT d_next_o_id FROM district WHERE d_w_id = %d AND d_id = %d SELECT count(*) FROM order_line, stock, district WHERE d_id = %d AND d_w_id = %d AND d_id = ol_d_id AND d_w_id = ol_w_id AND ol_i_id = s_i_id AND ol_w_id = s_w_id AND s_quantity < %d AND ol_o_id BETWEEN (%d) AND (%d)
  • 29. Stressing the database and the Transaction Mix The system is stressed by a C program that creates a thread per district, per warehouse. In other words, a database built with a scale factor of 10 will have 10 warehouses. Therefore 100 users will be simulated to represent a distinct person working for each of the 10 districts for each of the 10 warehouses. Each user executes transaction to the specified approximate mix: Delivery - 4% ◮ New Order - 55% ◮ Order Status - 4% ◮ Payment - 43% ◮ Stock Level - 4% ◮
  • 30. Thinking and Keying Time Thinking Time (How long it take Keying Time (How long it takes to decide what to enter next, to enter data, fixed.) negative exponential function.) Delivery - 5 seconds ◮ Delivery - 5 seconds ◮ New Order - 18 seconds ◮ New Order - 12 seconds ◮ Order Status - 2 seconds ◮ Order Status - 10 seconds ◮ Payment - 3 seconds ◮ Payment - 12 seconds ◮ Stock Level - 2 seconds ◮ Stock Level - 5 seconds ◮ __ __ / / ~~~/ . o O | Can I get a jumbo sized | ,----( oo ) | terminal? | / __ __/ / /| ( |( ^ /___ / | |__| |__|-quot;
  • 31. __ __ / ~~~/ . o O ( Comments? Questions? ) ,----( oo ) / __ __/ /| ( |( ^ /___ / | |__| |__|-quot;
  • 32. Materials Are Freely Available PDF http://www.slideshare.net/markwkm ◮ LTEX Beamer (source) A ◮ http://git.postgresql.org/?p=~ markwkm/performance-tuning.git
  • 33. Time and Location When: 2nd Thursday of the month Location: Portland State University Room: FAB 86-01 (Fourth Avenue Building) Map: http://www.pdx.edu/map.html
  • 34. Coming up next time. . . How to run DBT-2 run the kit. __ __ / ~~~/ . o O ( Thank you! ) ,----( oo ) / __ __/ /| ( |( ^ /___ / | |__| |__|-quot;
  • 35. Acknowledgements Haley Jane Wakenshaw __ __ / ~~~/ ,----( oo ) / __ __/ /| ( |( ^ /___ / | |__| |__|-quot;
  • 36. License This work is licensed under a Creative Commons Attribution 3.0 Unported License. To view a copy of this license, (a) visit http://creativecommons.org/licenses/by/3.0/us/; or, (b) send a letter to Creative Commons, 171 2nd Street, Suite 300, San Francisco, California, 94105, USA.

×