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

Like this? Share it with your network

Share

PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details

on

  • 3,570 views

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.

Statistics

Views

Total Views
3,570
Views on SlideShare
3,569
Embed Views
1

Actions

Likes
1
Downloads
79
Comments
1

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • The PDF isn't blank, download it if you can.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

PostgreSQL Portland Performance Practice Project - Database Test 2 Workload Details Presentation 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.