Embed Size (px)
DESCRIPTION
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.
Citation preview
PostgreSQL Portland
Performance Practice ProjectDatabase Test 2 (DBT-2)
Details
Mark [email protected]
Portland State University
February 12, 2009
Review
From last time:
◮ Series overview.
◮ DBT-2 background.
__ __
/ \~~~/ \ . o O ( Questions? )
,----( oo )
/ \__ __/
/| (\ |(
^ \ /___\ /\ |
|__| |__|-"
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 allparameters are changeable.
Workload Description
◮ Simulate wholesale supplier processing orders. (Manage, sell,distribute products or services.)
◮ A basic set of operations representing a complex OLTPapplication 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.
DBT-2 Components
Database Schema Diagram
Database Schema Notes
◮ 9 Tables
◮ No foreign key constraints
__ __ / \
/ \~~~/ \ . o O | Is this a good schema |
,----( oo ) | design? |
/ \__ __/ \ /
/| (\ |(
^ \ /___\ /\ |
|__| |__|-"
Scale Factor
◮ Determines database size.
◮ Determines number of users driving the workload.
Scale Factor’s effect on database row counts
Let W be the scale factor, which determines the starting size of thedatabase1:
◮ 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
1TPC-C Benchmark Specification v5.9 Clause 1.2.1
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
2TPC-C Benchmark Specification v5.9 Clause 4.2.2
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
3TPC-C Benchmark Specification v5.9 Clause 4.2.2
DBT-2 Transactions
Now descriptions of the 5 transactions and the SQL statementsexecuted 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
Delivery Transaction Description
The Delivery business transaction consists ofprocessing a batch of 10 new (not yet delivered) orders.Each order is processed (delivered) in full within thescope of a read-write database transaction. The numberof orders delivered as a group (or batched) within thesame database transaction is implementation specific.The business transaction, comprised of one or more (upto 10) database transactions, has a low frequency ofexecution and must complete within a relaxed responsetime requirement.
The Delivery transaction is intended to be executed indeferred mode through a queuing mechanism, ratherthan interactively, with terminal response indicatingtransaction completion. The result of the deferredexecution is recorded into a result file.4
4TPC-C Benchmark Specification v5.9 Clause 2.7
Delivery Table Touches
Delivery SQL Statements
For every district in the table:
SELECT no_o_id
FROM new_order
WHERE no_w_id = %d
AND no_d_id = %d
DELETE FROM new_order
WHERE no_o_id = %s
AND no_w_id = %d
AND no_d_id = %d
SELECT o_c_id
FROM orders
WHERE o_id = %s
AND o_w_id = %d
AND o_d_id = %d
UPDATE orders
SET o_carrier_id = %d
WHERE o_id = %s
AND o_w_id = %d
AND o_d\_id = %d
UPDATE order_line
SET ol_delivery_d = current_timestamp
WHERE ol_o_id = %s
AND ol_w_id = %d
AND ol_d_id = %d
SELECT SUM(ol_amount * ol_quantity)
FROM order_line
WHERE ol_o_id = %s
AND ol_w_id = %d
AND ol_d_id = %d
UPDATE customer
SET c_delivery_cnt = c_delivery_cnt + 1,
c_balance = c_balance + %s
WHERE c_id = %s
AND c_w_id = %d
AND c_d_id = %d
New Order Transaction Description
The New-Order business transaction consists of enteringa complete order through a single database transaction.It represents a mid-weight, read-write transaction with ahigh frequency of execution and stringent response timerequirements to satisfy on-line users. This transaction isthe backbone of the workload. It is designed to place avariable load on the system to reflect on-line databaseactivity as typically found in production environments.5
5TPC-C Benchmark Specification v5.9 Clause 2.4
New Order Table Touches
New Order SQL Statements
SELECT w_tax
FROM warehouse
WHERE w_id = %d
SELECT d_tax, d_next_o_id
FROM district
WHERE d_w_id = %d
AND d_id = %d
FOR UPDATE
UPDATE district
SET d_next_o_id = d_next_o_id + 1
WHERE d_w_id = %d
AND d_id = %d
SELECT c_discount, c_last, c_credit
FROM customer
WHERE c_w_id = %d
AND c_d_id = %d
AND c_id = %d
INSERT INTO new_order (no_o_id, no_w_id, no_d_id)
VALUES (%s, %d, %d)
INSERT INTO orders (o_id, o_d_id, o_w_id, o_c_id,
o_entry_d, o_carrier_id,
o_ol_cnt, o_all_local)
VALUES (%s, %d, %d, %d, current_timestamp, NULL,
%d, %d)
For 10 to 15 items (1% oftransaction fail here causing aROLLBACK):
SELECT i_price, i_name, i_data
FROM item
WHERE i_id = %d
SELECT s_quantity, %s, s_data
FROM stock
WHERE s_i_id = %d
AND s_w_id = %d
UPDATE stock
SET s_quantity = s_quantity - %d
WHERE s_i_id = %d
AND s_w_id = %d
INSERT INTO order_line (l_o_id, ol_d_id, ol_w_id,
ol_number, ol_i_id,
ol_supply_w_id,
ol_delivery_d,
ol_quantity,
ol_amount, ol_dist_info)
VALUES (%s, %d, %d, %d, %d, %d, NULL, %d, %f,
’\%s’)
Order Status Transaction Description
The Order-Status business transaction queries the statusof a customer’s last order. It represents a mid-weightread-only database transaction with a low frequency ofexecution and response time requirement to satisfyon-line users. In addition, this table includes non-primarykey access to the CUSTOMER table.6
6TPC-C Benchmark Specification v5.9 Clause 2.6
Order Status Table Touches
Order Status SQL Statements
Get the customer ID (c id) only if it is not already known.
SELECT c_id
FROM customer
WHERE c_w_id = %d
AND c_d_id = %d
AND c_last = ’%s’
ORDER BY c_first ASC
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
SELECT ol_i_id, ol_supply_w_id, ol_quantity,
ol_amount, ol_delivery_d
FROM order_line
WHERE ol_w_id = %d
AND ol_d_id = %d
AND ol_o_id = %s
Payment Transaction Description
The Payment business transaction updates thecustomer’s balance and reflects the payment on thedistrict and warehouse sales statistics. It represents alight-weight, read-write transaction with a high frequencyof execution and stringent response time requirements tosatisfy on-line users. In addition, this transaction includesnon-primary key access to the CUSTOMER table.7
7TPC-C Benchmark Specification v5.9 Clause 2.5
Payment Table Touches
Payment SQL Statements (part 1/2)
SELECT w_name, w_street_1, w_street_2, w_city,
w_state, w_zip
FROM warehouse
WHERE w_id = %d
UPDATE warehouse
SET w_ytd = w_ytd + %f
WHERE w_id = %d
SELECT d_name, d_street_1, d_street_2, d_city,
d_state, d_zip
FROM district
WHERE d_id = %d
AND d_w_id = %d
UPDATE district
SET d_ytd = d_ytd + %f
WHERE d_id = %d
AND d_w_id = %d
Get the customer ID (c id) if notalready known.
SELECT c_id
FROM customer
WHERE c_w_id = %d
AND c_d_id = %d
AND c_last = ’%s’
ORDER BY c_first ASC
SELECT c_first, c_middle, c_last, c_street_1,
c_street_2, c_city, c_state, c_zip,
c_phone, c_since, c_credit, c_credit_lim,
c_discount, c_balance, c_data,
c_ytd_payment
FROM customer
WHERE c_w_id = %d
AND c_d_id = %d
AND c_id = %d
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’)
Stock Level Transaction Description
The Stock-Level business transaction determines thenumber of recently sold items that have a stock levelbelow a specified threshold. It represents a heavyread-only database transaction with a low frequency ofexecution, a relaxed response time requirement, andrelaxed consistency requirements.8
8TPC-C Benchmark Specification v5.9 Clause 2.8
Stock Level Table Touches
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)
Stressing the database and the Transaction Mix
The system is stressed by a C program that creates a thread perdistrict, per warehouse. In other words, a database built with ascale factor of 10 will have 10 warehouses. Therefore 100 users willbe simulated to represent a distinct person working for each of the10 districts for each of the 10 warehouses. Each user executestransaction to the specified approximate mix:
◮ Delivery - 4%
◮ New Order - 55%
◮ Order Status - 4%
◮ Payment - 43%
◮ Stock Level - 4%
Thinking and Keying Time
Thinking Time (How long it taketo decide what to enter next,negative exponential function.)
◮ Delivery - 5 seconds
◮ New Order - 12 seconds
◮ Order Status - 10 seconds
◮ Payment - 12 seconds
◮ Stock Level - 5 seconds
Keying Time (How long it takesto enter data, fixed.)
◮ Delivery - 5 seconds
◮ New Order - 18 seconds
◮ Order Status - 2 seconds
◮ Payment - 3 seconds
◮ Stock Level - 2 seconds
__ __ / \
/ \~~~/ \ . o O | Can I get a jumbo sized |
,----( oo ) | terminal? |
/ \__ __/ \ /
/| (\ |(
^ \ /___\ /\ |
|__| |__|-"
__ __
/ \~~~/ \ . o O ( Comments? Questions? )
,----( oo )
/ \__ __/
/| (\ |(
^ \ /___\ /\ |
|__| |__|-"
Materials Are Freely Available
◮ http://www.slideshare.net/markwkm
LATEX Beamer (source)◮ http://git.postgresql.org/?p=~markwkm/performance-tuning.git
Time and Location
When: 2nd Thursday of the monthLocation: Portland State UniversityRoom: FAB 86-01 (Fourth Avenue Building)Map: http://www.pdx.edu/map.html
Coming up next time. . .
How to run DBT-2 run the kit.
__ __
/ \~~~/ \ . o O ( Thank you! )
,----( oo )
/ \__ __/
/| (\ |(
^ \ /___\ /\ |
|__| |__|-"
Acknowledgements
Haley Jane Wakenshaw
__ __
/ \~~~/ \
,----( oo )
/ \__ __/
/| (\ |(
^ \ /___\ /\ |
|__| |__|-"
License
This work is licensed under a Creative Commons Attribution 3.0Unported License. To view a copy of this license, (a) visithttp://creativecommons.org/licenses/by/3.0/us/; or, (b)send a letter to Creative Commons, 171 2nd Street, Suite 300, SanFrancisco, California, 94105, USA.
