POPS Benchmark Report On Regatta

POPS Benchmark Report
On
Regatta
Integration Services
Software Development Laboratory - Yamato (YSL), SWG
測定概要
3
POPS 測定について ............................................................................................................ 3
Hardware 構成 ...................................................................................................................... 3
データベース構成........................................................................................................... 4
スキーマレイアウト....................................................................................................... 4
Segmentation..................................................................................................................... 4
Data ................................................................................................................................... 4
Query の発行の仕方........................................................................................................ 4
2. データロード測定結果および考察 6
TMU のパラメータ設定 (Non Default) ............................................................................. 6
ロード測定結果................................................................................................................... 6
データローディング並列度をあげての測定................................................................... 8
ローディング性能............................................................................................................... 9
3. Query の測定結果および考察 11
パラメータの設定............................................................................................................. 11
データベースサイズごとの測定結果............................................................................. 11
Query の種類ごとの測定結果.......................................................................................... 13
4-way CPU と 8-way の違い ............................................................................................. 16
Query の範囲の性能に対する影響.................................................................................. 18
4. ｒPerf と POPS 測定結果との比較 20
Appendix............................................................................................................................. 21
Appendix A – ハードウェア構成詳細......................................................................... 21
Appendix B – Query の詳細 .......................................................................................... 23
Appendix C – POPS 測定結果一覧............................................................................... 27
1.
1. 測定概要
POPS 測定について
POPS は Proof Of Performance and Scalability の略でありこの測定により RedBrick の性能の良さを証明
する
Datawarehouse のエリアではＩｎｓｅｒｔ/Ｕｐｄａｔｅが機能/性能に要求されることは少なく
Oracle/DB2 は比較の対象にならず、OLTP 系のベンチマークは不適切である。そこで Red Brick では
実際のお客様の使用シナリオ/データベースに沿った性能測定（性能証明）の方法として、POPS
（Proof of Performance and Scalability）という独自の方法でいかに大量のデータを RedBrick が
処理できるかを示している。
Hardware 構成
P690-681 (Regatta)
z 1.1GHz 8way
z 32GB memory
z 36.4GBx4
SSA Disks
z
18.2GB x 16
データベース構成
スキーマレイアウト
このベンチマーク・テストは、実際の小売業のビジネス・モデルとそのトランザクションを反映した
環境で実施され、具体的には、食料雑貨店 63 店舗、1 万 9 千点以上の商品、1 日当たりおよそ 360 万
件のトランザクション、35 の販促活動項目といった環境を設定し、テストを実行する。このデー
タ・ウェアハウスには、下記の 2 つのファクト・テーブル（日次売上予測と日次売上実績）とディメ
ンション・テーブル（顧客、期間、商品、販促、店舗）が含まれている。
下図のように５個のディメンジョンテーブルと２個のファクトテーブルからなっている。
Customer
Daily_Sales
Product
Store
Daily_Forecast
Promotion
Period
図 1-1 POPS スキー
Segmentation
Data
10 日分、100 日分、300 日分のデータを用意し、それぞれについて測定を行った。
それぞれのデータは以下の表のように、1996/01/01 を基準に作成されている。
表 1-1 – 使用されたデータのサイズ
Data range
Corresponding period
10 days
100 days
300 days
1996/01/01 - 1996/01/10
1996/01/01 - 1996/04/09
1996/01/01 - 1996/10/26
Data size of
Daily_Forecast
0.308 GB
3.08 GB
9.24 GB
Data size of
Dialy_Sales
14.8 GB
148 GB
444 GB
Query の発行の仕方
10 のクエリーが用意されており、各ユーザーは、これら 10 のクエリーを 10 秒のインターバルを置
いて順に実行する。
ユーザー数は、1、5、10、20、50、100、300 について測定を行った。
なお、複数ユーザーの時は、最初のユーザーがクエリーをスタートしてから 5 秒後に次のユーザーが
スタートする。
1st u ser
q u e ry 1
2n d u ser
3 rd u ser
5 sec
q u e ry 2
q u e ry 3
q u e ry 4
q u e ry 5
q u e ry 6
q u e ry 7
q u e ry 8
q u e ry 9
q u e ry 1 0
図 1-2 – Query の発行の仕方
10sec
2. データロード測定結果および考察
TMU のパラメータ設定 (Non Default)
Daily_Forecastは、以下のセッティングでロードを行った。
表 2-1 – Daily_Forecast ロード時のパラメータ設定
Parameters for DAILY_FORECAST
TMU BUFFERS
INDEX TEMPSPACE DIRECTORIES
INDEX TEMPSPACE THRESHOLD
INDEX TEMPSPACE MAXSPILLSIZE
Values
1024
/rbdata/rbs10
256M
5G
Daily_Salesについては、以下のセッティングでロードを行った。
表 2-2 – Daily_Sales ロード時のパラメータ設定
Parameters for DAILY_SALES
TMU BUFFERS
INDEX TEMPSPACE DIRECTORIES
INDEX TEMPSPACE THRESHOLD
INDEX TEMPSPACE MAXSPILLSIZE
Values
1024
/rbdata/rbs10
/rbdata/rbs11
256M
10G
ロード測定結果
Loading time for Daily_Forecast
2000
Elapsed time in seconds
1800
1600
1400
1200
1000
800
600
400
200
0
0
50
100
150
200
Data range in days
図 2-1 –Daily_Forecast のロード時間
250
300
Loading time for Daily_Sales
12
Elapsed time in hours
10
8
6
4
2
0
0
50
100
150
200
Data range in days
250
300
図 2-2 Daily_Sales のロード時間
ロードしたデータ量を横軸に所要時間を縦軸に表した図 2-1、図 2-2 をみればわかるようにそれぞれ
のファクトテーブルにおいてデータ量に比例して、線形に所要時間が増加しているのが分かる。
Loading time for Daily_Forecast and Daily_Sales
45000
Elapsed time in seconds
40000
35000
30000
25000
20000
15000
10000
5000
0
0
50
100
150
200
250
300
Data size in GB
350
400
450
図 2-3 Daily_Forecast と Daily_Sales のロード時間の比較
また、Daily_Forecast と Dialy_Sales をテーブルに格納された時のサイズを横軸にして、一緒にプロットした図
2-3では・ Dialy_ForecastとDialy_Salesが線形につながらない。これはデータロードではインデックスの作成な
どが行われており、テーブルの複雑さが所要時間の違いを引き起こしていると考えられる。従って所要時間
の見積もりは、テーブルごとに少ないサイズのロードを行って、その値から線形に見積もるのがよいと考えら
れる。
10days data load
3000
100
us
sy
2500
wa
avm
60
2000
avm (MB)
Utlization (%)
80
1500
40
1000
20
500
0
0
00:00:00
00:07:12
00:14:24
00:21:36
00:28:48
00:36:00
Time
図 2-4 10days データロード時の vmstat
また、図 2-4 に 10days のデータロード時の vmstat の値を示す。これから使用メモリー量はロード時
には、ほぼ一定で推移してることがわかる。また、今回のハードウェア構成の場合、I/O バウンドと
はなっていないことがわかる。また、８way すべての CPU を使ってもいないことがわかる。これは
ロードの処理すべてが並列化できないこと（Table Management Utlility Reference Guide 図３−１参
照）ためと考えられる。
データローディング並列度をあげての測定
ロード時のConversion Task並列度をあげて、（上記のパラメータに以下のセッティングを追加して）ロードを行
った。本テストではCPUは8wayなので、「TMU CONVERSION TASKS」のデフォルト値はその半分の4である。
表 2-3 並列度を向上するパラメータ
Parameters for parallel load test
TMU CONVERSION TASKS
Values
8
Loading time for Dialy_Forecust (CPU-ways and parallelism)
8-way 4-parallel
8-way 8-parallel
4-way 4-parallel
Elapsed time in second
70
60
50
40
30
20
10
0
10
Data range in days
図 2-5 Conversion タスクの並列度をあげた測定 Daily_Forecast
Elapsed time in minutes
Loading time for Dialy_Sales (CPU-ways and parallelism)
40
8-way 4-parallel
8-way 8-parallel
35
4-way 4-parallel
30
25
20
15
10
5
0
10
Data range in days
図 2-6 Conversion タスクの並列度をあげた測定 Daily_Sales
100
90
80
70
60
50
40
30
20
10
0
00:00:00
3000
2500
us
sy
wa
avm
2000
1500
1000
avm (MB)
Utlization (%)
10 days data load - Conversion Task=8
500
00:07:12
00:14:24
Time
00:21:36
0
00:28:48
図 2-7 Conversion タスクの並列度をあげた測定の vmstat
CPU 数と「TMU CONVERSION TASKS」がロード時間に及ぼす影響を示したもの。
Daily_Forecast については、CPU 数、Parallelism による影響はほとんど見られなかった。Daily_Sales
からは、CPU 数、Parallelism、ともに多いほうがロード時間が少ないことが分かる。また、CPU
Utlization（vmstat の us： user 使用時間）も増加している。
Daily_Forecast に比べて Daily_Sales はロードするデータが格段に多く、インデックスも複雑であるた
め、CPU 数と Parallelism の増加に対してパフォーマンスの改善が顕著に表れたと考えられる。また、
並列処理が有効なのはロード処理シーケンス内の一部のステージ（変換ステージとインデックス・ス
テージ）に限られるため、CPU 数や Parallelism が 2 倍になったからといって処理速度も 2 倍にはらな
い。
ローディング性能
Daily_Sales、Daily_Forecastの１日当たりの行数と、１行当たりのサイズを表にまとめたものが
表2-4であり、これをもとにロード性能をまとめたものが、表2-5である。
Table
Daily_Forecast
Daily_Sales
一日当たりの行数
1223475
11669320
行サイズ（Byte）
24
128
表 2-4 テーブルサイズ
ロード
日数
条件
10
100
300
Average
8-way 4-para
8-way 4-para
8-way 4-para
8-way 4-para
10
10
4-way 2-para
8-way 8-para
Daily_Forecast
ロード時間
速度
速度
(秒)
（GB/時） （行数/秒）
65
15.1
187000
655
15.0
186000
1931
14.8
183000
--15.0
185000
63
65
15.6
14.9
Daily_Sales
ロード時間
速度
速度
（秒）
（GB/時） （行数/秒）
1423
35.2
82200
12008
41.7
97400
40891
35.5
83000
--37.5
87500
193000
185000
1678
1119
29.8
44.7
69700
105000
表 2-5 ローディング性能 （速度のカラムは有効数字３桁で表記）
表 2-5 の Average の行は、8-way 4-paralell の測定結果を平均したものである。
Daily_Forecast と Daily_Sales の間にロード性能に差が見られるが、これは一行当たりの行サイズの違いが
原因と考えられる。Daily_Forecast は DailySales に比べて行サイズが小さいため、一行当たりのロードのデ
ータ数が少なく、速度（行数/秒）の値は高く出ている。反面、速度（GB/時）の値が小さくなる結果となってい
る。
3. Query の測定結果および考察
パラメータの設定
RedBrickに対して行ったでファールと以外に行った設定は以下のとおり。
Parameters
Values
TOTAL QURY PROCS
2000
QUERY PROCS
4
表 3-1 Query 性能測定時のパラメータ設定
データベースサイズごとの測定結果
Total Query Time (sec)
Total Query Time by Size
40000
35000
30000
25000
20000
15000
10000
5000
0
10days
100days
300days
0
50
100
150
200
250
# of concurrent users
300
350
図 3-1． Query 合計時間とユーザ数の増加
Elapsed Time by size
Elaspesed Time
12:00:00
10days
100days
300days
09:36:00
07:12:00
04:48:00
02:24:00
00:00:00
0
100
200
300
# of concurrent users
図 3-2． 測定時間とユーザ数の増加
400
すべての Query が処理されるのにかかった時間（Query1 から Query10 までの合計時間）と
Concurrent Users との関係を示した図 3-1 にしめした。また、１０Query を User 数分だけ流すのに
かかった時間を図 3-2 に示す。
・Concurrent Users に対して線形に Total run time が増加している。
Table size（データ量）に着目すると、10days と 100days では Total run time は変わっているが、100days と
300days では Total run time についてはほとんど変化がない。これは別項で検証するが、Table サイズでは
なく、Query の範囲が処理時間を左右する要因であった。従って、100days と 300days の結果からみられるよ
うに RedBrick においてはデータサイズが増えても応答時間はほとんど変わらないことが示されている。
100
90
80
70
60
50
40
30
20
10
0
8000
7000
6000
us
sy
wa
5000
4000
avm
3000
aｖｍ（MB)
Utilization(%)
10daysの測定時のvmstat
2000
1000
0
11:02:2 12:14:2 13:26:2 14:38:2 15:50:2 17:02:2 18:14:2 19:26:2 20:38:2 21:50:2
4
4
4
4
4
4
4
4
4
4
時刻
図 3-3． 測定時間とユーザ数の増加
また、図3-3は10daysの１ユーザーから順に測定したときのvmstatの値であるが８wayなので８ユーザ以上に
なるまではCPU使用率が高くならないが、１０ユーザー以上ではCPU使用率が１００％近くになりCPUバウン
ドである。
Query の種類ごとの測定結果
Average elapsed time of each queries in 300 days data
Elapsed time in minutes
600
query1
query2
500 query3
query4
query5
400 query6
query7
300 query8
query9
query10
200
100
0
0
50
100
150
200
Concurrent users
250
300
図 3-4． Query ごとの Query 時間とユーザ数の増加
Average elapsed time of each queries in 300 days data
7
Elapsed time in minutes
6
5
4
3
2
1
0
0
50
100
150
200
Concurrent users
250
300
図 3-5． Query ごとの Query 時間とユーザ数の増加（Query4 を除いたもの）
Queryごとに、Queryが終了する平均時間をプロットしたもの。Query4が圧倒的に所要時間が多く、その他の
ものについては、Fig2に拡大してプロットしてある。
・Queryの種類によらず、同時アクセスユーザーが増加すると、平均所要時間は線形に増加している。
・どのQueryも1ユーザー時の方が5ユーザーの時より大きい値になっている。キャッシュにデータが入ってな
いからだろうか？
Average elapsed time of each queries in 20 concurrent users
Elapsed time in second
2500
10 days data
100 days data
300 days data
2000
1500
1000
500
0
1
2
3
4
5
6
7
Query number
8
9
10
図 3-6． Query ごとの Query 時間
Average elapsed time of each queries in 20 concurrent users
Elapsed time in second
20
10 days data
100 days data
300 days data
15
10
5
0
1
2
3
4
5
6
Query number
7
8
9
10
図 3-7． Query ごとの Query 時間（Query4 を除いたもの）
Queryごとに、Queryが終了する平均時間をプロットしたもの。テーブルサイズ(データ量）がどのように影響を
及ぼすかを調べる。
・10daysと100daysを比較すると、処理時間が多くなっているのはQuery1,4,6,8,9,10で、Query2,3,5,7は処理時
間にあまり変化は出ていない。表3-2に各Queryのクエリーされているデータ範囲を示した。この表にあるよう
にQuery3,5はクエリーされているデータの範囲が、10daysの範囲にあるため、100daysでもQueryされるデー
タの領域に変化がないためと思われる。また、Query7については、データの範囲が、10days、100daysのデー
タの外にあるためQuery3,5と同様の理由から処理時間が変わらないと思われる。このことからも、所要時間
は、Tableサイズそのものよりも、Constraintに大きく依存しているのが分かる。
・100daysと300daysでも同様の結果となっている。ここでElapsed Timeが大きく伸びているのはQuery7だけで
ある。
表 3-2． Query 内にある Date の範囲
Query #
1
2
3
4
5
6
7
8
9
10
Constrain about period
1996/01/01 - 1996/01/31
1996/01/01 - 1996/01/27
1996-01-01
1996/01/01 - 1996/01/31
1996/01/01 - 1996/01/09
1996/01/21 - 1996/01/27
1996/07/21 - 1996/07/27
1996/01/01 - 1996/02/14
1996/01/01 - 1996/01/13
1996/01/01 - 1996/01/13
Average memory usage of each queries in 20 users
13000
10 days data
300 days data
12000
Average memory usage
11000
10000
9000
8000
7000
6000
5000
4000
3000
1
2
3
4
5
6
7
Query number
8
図 3-8． Query ごとのメモリー使用量
メモリーの使用量を、Query別に調べたもの。
・10days より 300days の方が若干使用量が多くなっている。
9
10
4-way CPU と 8-way の違い
Total run time to finish all users measurement
1200
300 days data (8-way CPU)
300 days data (4-way CPU)
Run time in minutes
1000
800
600
400
200
0
0
50
100
150
200
Concurrent Users
250
300
図 3-9 4way と 8way の 300days データ時の合計 Qyery 時間の比較
4-wayと8-wayでの処理時間の差を調べたもの。
・8-wayの方が、4-wayに比べておおよそ２倍、処理が早いことが分かる。→ CPU数に比例して処理が早くな
っている。（ただし、この測定においては、Memory、DiskIOのボトルネックは出ていない）
Average elapsed time of each queries in 20 concurrent users
4500
300 days data (8-way CPU)
300 days data (4-way CPU)
Elapsed time in second
4000
3500
3000
2500
2000
1500
1000
500
0
1
2
3
4
5
6
7
Query number
8
9
図 3-9． 4way と 8way の Query ごとの処理時間
10
Average elapsed time of each queries in 20 concurrent users
45
8-way CPU
4-way CPU
Elapsed time in second
40
35
30
25
20
15
10
5
0
1
2
3
4
5
6
Query number
7
8
9
10
図 3-10 4way と 8way の Query ごとの処理時間（除く Query4）
Query別に4-way、8-wayの違いをプロットしたもの。
・どのQueryも概ね4-wayの方が2倍の処理時間を要しているのが分かる。
Average memory usage of each queries in 20 users
13000
300 days data (8-way CPU)
300 days data (4-way CPU)
12000
Average memory usage
11000
10000
9000
8000
7000
6000
5000
4000
3000
1
2
3
4
5
6
7
Query number
8
9
10
図 3-11． 4way と 8way の Query ごとのメモリー使用量
1Queryあたりのメモリ使用量は、CPU数には依存しない。
Query の範囲の性能に対する影響
下記に Query４の内容を記す。これからわかるように Query4 では赤字の範囲のデータを持ってきて
いる。いままで測定結果が示すように処理時間はデータ量よりもこのクエリー範囲に依存していると
考えられた。
/* query4
How much was spent by a given customer over a one month period?
*/
SELECT WEEK_ENDING_DATE,daily_sales.custkey,SUM(EXTENDED_PRICE) As cust_rev
from period join daily_sales on period.perkey = daily_sales.perkey
join customer on customer.custkey = daily_sales.custkey
WHERE CUSTOMER.CUSTKEY in (531150,627294)
AND CALENDAR_DATE BETWEEN DATE('1996-01-01') AND DATE('1996-01-31')
GROUP BY WEEK_ENDING_DATE, daily_sales.custkey
ORDER BY WEEK_ENDING_DATE;
100day のデータにおいて下記の２つの測定を行うことにより検証した。
1.
2.
クエリーの範囲が 1996 年 1 月で固定ものもと、1996 年 1 月 1 日∼1 月 15 日までのもの、
１月、2 月、3 月を満遍なくアクセスするようにしたものの、平均処理時間の違い。
すなわち赤字の部分を下記のように変更した。
表 3-3． Query4 に設定したクエリー範囲
Query range
Original range
1.Half range
2.Various range
Constrained period
1996/01/01 - 1996/01/31
1996/01/01 - 1996/01/15
1996/01/01 - 1996/01/31 or
1996/02/01 - 1996/02/29 or
1996/03/01 - 1996/03/31
測定結果を図 3-12 に示す。この結果より
z
z
クエリー範囲が 2 倍になると、処理時間が約 2 倍になっているのが分かる。クエリー範囲が広
さが性能に影響している。
クエリー範囲を散らしたものは、固定のものと、そんなに差は出なかった。クエリー範囲の場
所は性能に依存しない。
Average elapsed time of query 4 in 100 days data
fixed range
half range
various ranges
Elapsed time in second
2000
1500
1000
500
0
4
Query number
図 3-12． Query4 の処理時間
4. ｒPerf(*1)と POPS 測定結果との比較
表４−１はｒPerf 値と POPS の性能の比較表である。これをグラフにしたのが図 4-1 である。この図
表、および RedBrick の Query については CPU バウンドのアプリケーションであったことこから考え
ると rPerf の値と RedBrick 性能に相関がある可能性が高いと思われる。Load に関しては、CPU、I/O
ともに使い、また、RedBRick の処理フェーズやインデクス構造も考えにいれた慎重な対応が必要と
考えられる。
表 4-1 ｒPerf とロード性能と Query 性能の相関
H70
rPerf
2.2
Load Performance (GB/Hour) 4.97
Total Query time at 10
3000
users (sec)
Regatta 4 way
6.36 (Estimation)
32
1250
Regatta 8way
12.72
40
502
3500
45
40
35
30
25
20
15
10
5
0
3000
2500
Load
Total Query
Time(sec)
Load (GB/hour)
rPerf vs Red Brick Performance
2000
Toatl qyery time
at 10 users
1500
1000
500
0
0
5
rPerf
10
15
図 4-1． ｒPerf と RedBrick 性能の相関
(*1)rPerfについて
rPerfとは、tpc-cやSPECと同様にビジネス系でのマシン性能をあらわすＩＢＭ独自の性能指標です。
ｐ640 B80の性能を1として、それとの比率であらわします。
Appendix
Appendix A – ハードウェア構成詳細
ネットワーク構成図
[Regatta LAN]
regatta(LPAR1)
7040-681
IBM
pvc201
pvc202
HMC No.1
HMC No.2
6E1(NIM)
270(作業用)
HostName
pvc201
IP Address/Mask
192.168.20.1/24
PC接続用
192.168.50.1/24
192.168.20.10/24
192.168.20.11/24
192.168.20.101/24
192.168.20.98/24
hmc1
hmc2
pvc01_regatta
pvc98
100 Mbps Ethernet
pvc01_regatta
IBM
pvc98
RS/6000
HMC No.1
HMC No.2
6E1
270(作業用)
pvc01
100 Mbps Etherneth
図 ネットワーク構成図
7040-681テスト・システム構成図(1)
7040-681
CEC
Processor : 1.1GHz POWER4 16way
Memory : 64GB
電源サブシステム
Media Drawer
CD-ROM,DVD-RAM,4mm tape drive
I/O Drawer
CEC(Central Electronics Complex)
3 x I/O Drawer
Rack
Battery Backup,Acoustic Door
HMC
2 x HMC
メディアドロワー
内蔵バッテリー
内蔵バッテリー
I/Oドロワー No.1
I/Oドロワー No.2
I/Oドロワー No.3
ハードウェア管理コンソール (HMC) No.1
図 7040-681 テスト・システム構成図(1)
ハードウェア管理コンソール (HMC) No.2
7040-681テスト・システム構成図(2)
CEC
L3 x 2
L3 x 2
M
E
M
O
R
Y
Pass
Thru
OSC
Pass
Thru
M
E
M
O
R
Y
L3 x 2
L3 x 2
M
E
M
O
R
Y
8Way POWER4 Processor x 2
32MB L3 Cache x 8
Processor Pass-Thru Module x 2
16GB Memory Card x 4
M
E
M
O
R
Y
8way
CPU
8way
CPU
Media Drawer
メディア・ドロワー：後面
CPU数
SMPモード
16
メモリー
数
64GB
LPAR1
LPAR2
8
4
32GB
16GB
(Full System partition)
1
2
CD-ROM
ﾃﾞｨｽｹｯﾄ
(標準)
空き
DVD-RAM 4mm ﾃｰﾌﾟ 操作ﾊﾟﾈﾙ
(標準)
メディア・ドロワー：前面
図 7040-681 テストシステム構成図(2)
箱崎ベンチマークセンターESSディスク構成図
シリアル番号／LUN容量一覧
ディスク割り当て: 28GB x 32
24GB x 32
最大構成 1.6TB
Bay1
Bay2
Bay3
Bay4
B1H1 B1H2 B1H3 B1H4 B2H1 B2H2 B2H3 B3H4 B3H1 B3H2 B3H3 B3H4 B4H1 B4H2 B4H3 B4H4
cluster2
cluster1
XXX
24GB
XXX-14530
......シリアル頭3桁
......LUN容量
DA1
DA2
DA3
DA4
000
hdisk6
24GB
002
hdisk7
28GB
005
hdisk38
24GB
007
hdisk39
28GB
001
hdisk4
24GB
003
hdisk5
28GB
004
hdisk36
24GB
006
hdisk37
28GB
200
hdisk8
24GB
202
hdisk9
28GB
204
hdisk40
24GB
201
hdisk10
24GB
203
hdisk11
28GB
403
hdisk12
24GB
100
hdisk20
24GB
102
hdisk21
28GB
104
hdisk52
24GB
106
hdisk53
28GB
loop B
101
hdisk22
24GB
103
hdisk23
28GB
105
hdisk54
24GB
107
hdisk55
28GB
206
hdisk41
28GB
loop A
300
hdisk24
24GB
302
hdisk25
28GB
304
hdisk56
24GB
306
hdisk57
28GB
205
hdisk42
24GB
207
hdisk43
28GB
loop B
301
hdisk26
24GB
303
hdisk27
28GB
305
hdisk58
24GB
307
hdisk59
28GB
404
hdisk13
28GB
405
hdisk44
24GB
406
hdisk45
28GB
loop A
500
hdisk28
24GB
502
hdisk29
28GB
504
hdisk60
24GB
506
hdisk61
28GB
400
hdisk14
24GB
401
hdisk15
28GB
402
hdisk46
24GB
407
hdisk47
28GB
loop B
501
hdisk30
24GB
503
hdisk31
28GB
505
hdisk62
24GB
507
hdisk63
28GB
600
hdisk18
24GB
602
hdisk19
28GB
605
hdisk50
24GB
607
hdisk51
28GB
loop A
700
hdisk32
24GB
702
hdisk33
28GB
704
hdisk64
24GB
706
hdisk65
28GB
601
hdisk16
24GB
603
hdisk17
28GB
604
hdisk48
24GB
606
hdisk49
28GB
loop B
701
hdisk34
24GB
703
hdisk35
28GB
705
hdisk66
24GB
707
hdisk67
28GB
図 ESS ディスク構成図
loop A
DA1
DA2
DA3
DA4
Appendix B – Query の詳細
Query 1:
/* Query1
For a given category, list all items including quantity sold,
revenue, and cost. */
SELECT ITEM_DESC,
SUM(QUANTITY_SOLD),
SUM(EXTENDED_PRICE),
SUM(EXTENDED_COST)
FROM PERIOD, DAILY_SALES,PRODUCT, STORE, PROMOTION
WHERE
PERIOD.PERKEY=DAILY_SALES.PERKEY AND
PRODUCT.PRODKEY=DAILY_SALES.PRODKEY AND
STORE.STOREKEY=DAILY_SALES.STOREKEY AND
PROMOTION.PROMOKEY=DAILY_SALES.PROMOKEY AND
CALENDAR_DATE BETWEEN 'Jan 01 1996' AND 'Jan 28 1996' AND
STORE_NUMBER='01' AND
PROMODESC IN ('Advertisement', 'Coupon', 'Manager''s Special',
'Overstocked Items') AND
CATEGORY=42
GROUP BY ITEM_DESC;
Query 2:
/* Query2
*/
What were the weekly sales of a category of items over a four week period?
SELECT PRODUCT.UPC_NUMBER,
SUM(SALES_WEEK1) AS SALES_WEEK1,
SUM(SALES_WEEK2) AS SALES_WEEK2,
SUM(SALES_WEEK3) AS SALES_WEEK3,
SUM(SALES_WEEK4) AS SALES_WEEK4
FROM PRODUCT,
(SELECT UPC_NUMBER,SUM(EXTENDED_PRICE)
FROM PERIOD, PRODUCT, STORE, DAILY_SALES
WHERE
DAILY_SALES.PERKEY=PERIOD.PERKEY AND
DAILY_SALES.PRODKEY=PRODUCT.PRODKEY AND
DAILY_SALES.STOREKEY=STORE.STOREKEY AND
PRODUCT.CATEGORY=1 AND
PRODUCT.SUB_CATEGORY = 50 AND
STORE_NUMBER='01' AND
PERIOD.WEEK_ENDING_DATE = '2/3/1996'
GROUP BY UPC_NUMBER) AS
T1(UPC_NUMBER,SALES_WEEK1),
(SELECT UPC_NUMBER,SUM(EXTENDED_PRICE)
FROM PERIOD, PRODUCT, STORE, DAILY_SALES
WHERE
DAILY_SALES.PERKEY=PERIOD.PERKEY AND
DAILY_SALES.PRODKEY=PRODUCT.PRODKEY AND
DAILY_SALES.STOREKEY=STORE.STOREKEY AND
PRODUCT.CATEGORY=1 AND
PRODUCT.SUB_CATEGORY = 50 AND
STORE_NUMBER='01' AND
PERIOD.WEEK_ENDING_DATE = '2/10/1996'
GROUP BY UPC_NUMBER) AS
T2(UPC_NUMBER,SALES_WEEK2),
(SELECT UPC_NUMBER,SUM(EXTENDED_PRICE)
FROM PERIOD, PRODUCT, STORE, DAILY_SALES
WHERE
DAILY_SALES.PERKEY=PERIOD.PERKEY AND
DAILY_SALES.PRODKEY=PRODUCT.PRODKEY AND
DAILY_SALES.STOREKEY=STORE.STOREKEY AND
PRODUCT.CATEGORY=1 AND
PRODUCT.SUB_CATEGORY = 50 AND
STORE_NUMBER='01' AND
PERIOD.WEEK_ENDING_DATE = '2/17/1996'
GROUP BY UPC_NUMBER) AS
T3(UPC_NUMBER,SALES_WEEK3),
(SELECT UPC_NUMBER,SUM(EXTENDED_PRICE)
FROM PERIOD, PRODUCT, STORE, DAILY_SALES
WHERE
DAILY_SALES.PERKEY=PERIOD.PERKEY AND
DAILY_SALES.PRODKEY=PRODUCT.PRODKEY AND
DAILY_SALES.STOREKEY=STORE.STOREKEY AND
PRODUCT.CATEGORY=1 AND
PRODUCT.SUB_CATEGORY = 50 AND
STORE_NUMBER='01' AND
PERIOD.WEEK_ENDING_DATE = '2/24/1996'
GROUP BY UPC_NUMBER) AS
T4(UPC_NUMBER,SALES_WEEK4)
WHERE
PRODUCT.UPC_NUMBER=T1.UPC_NUMBER and
PRODUCT.UPC_NUMBER=T2.UPC_NUMBER and
PRODUCT.UPC_NUMBER=T3.UPC_NUMBER and
PRODUCT.UPC_NUMBER=T4.UPC_NUMBER
GROUP BY PRODUCT.UPC_NUMBER
ORDER BY PRODUCT.UPC_NUMBER;
Query 3:
/* Query3
What was the profit per store for a given category by store on a
given day? And what was the share per store by district? */
SELECT T1.STORE_NUMBER,T1.CITY,T1.DISTRICT,SUM(AMOUNT) AS SUM_PROFIT,
DEC(100*RATIOTOREPORT(SUM_PROFIT),5,2) AS SHARE_OF_DISTRICT
FROM
(SELECT STORE_NUMBER,STORE.CITY,DISTRICT, EXTENDED_PRICE-EXTENDED_COST
FROM
PERIOD, PRODUCT,STORE, DAILY_SALES WHERE
PERIOD.CALENDAR_DATE='3/1/1996' AND
PERIOD.PERKEY=DAILY_SALES.PERKEY AND
PRODUCT.PRODKEY=DAILY_SALES.PRODKEY AND
STORE.STOREKEY=DAILY_SALES.STOREKEY AND
PRODUCT.CATEGORY=42 ) AS T1(STORE_NUMBER,CITY,DISTRICT,AMOUNT)
GROUP BY DISTRICT,CITY, STORE_NUMBER
ORDER BY DISTRICT,CITY, STORE_NUMBER DESC
RESET BY DISTRICT;
Query 4:
/* Query4
How much was spent by a given customer over a one month period? */
SELECT WEEK_ENDING_DATE,daily_sales.custkey,SUM(EXTENDED_PRICE) As cust_rev
from period join daily_sales on period.perkey = daily_sales.perkey
join customer on customer.custkey = daily_sales.custkey
WHERE CUSTOMER.CUSTKEY in (215311,627294)
AND CALENDAR_DATE BETWEEN '1/1/1996' AND '1/31/1996'
GROUP BY WEEK_ENDING_DATE, daily_sales.custkey
ORDER BY WEEK_ENDING_DATE;
Query 5:
/* Query5
What were the week to day profits for a given category within region? */
SELECT Sub_Category_Desc,
Sum(Case Region When 'North' Then Extended_Price-Extended_Cost Else 0
End) As Northern_Region,
Sum(Case Region When 'South' Then Extended_Price-Extended_Cost Else 0
End) As Southern_Region,
Sum(Case Region When 'East' Then Extended_Price-Extended_Cost Else 0
End) As Eastern_Region,
Sum(Case Region When 'West' Then Extended_Price-Extended_Cost Else 0
End) As Western_Region,
NORTHERN_REGION+SOUTHERN_REGION+EASTERN_REGION+WESTERN_REGION As ALL_REGIONS
FROM PERIOD, PRODUCT, STORE, DAILY_SALES WHERE
PERIOD.PERKEY=DAILY_SALES.PERKEY AND
PRODUCT.PRODKEY=DAILY_SALES.PRODKEY AND
STORE.STOREKEY=DAILY_SALES.STOREKEY AND
PERIOD.CALENDAR_DATE BETWEEN '5/1/1996' AND '5/9/1996'
AND CATEGORY=88
GROUP BY SUB_CATEGORY_DESC
ORDER BY SUB_CATEGORY_DESC;
Query 6:
/* Query6
What were the sales for a given brand at a given store and the total
sales for the brand in all stores? */
SELECT ITEM_DESC,
EXP AS SALES,
SUM(EXTENDED_PRICE) AS TOTAL_SALES
FROM PRODUCT, DAILY_SALES, PERIOD,
(SELECT ITEM_DESC,SUM(EXTENDED_PRICE)
FROM PRODUCT, DAILY_SALES, PERIOD,STORE
WHERE WEEK_ENDING_DATE='Jun 29 1996' AND
PRODUCT.PRODKEY=DAILY_SALES.PRODKEY AND
PERIOD.PERKEY=DAILY_SALES.PERKEY AND
STORE.STOREKEY=DAILY_SALES.STOREKEY AND
STORE_NUMBER='01' AND
ITEM_DESC LIKE 'NESTLE%'
GROUP BY ITEM_DESC
) AS T1(ITEM,EXP)
WHERE ITEM_DESC LIKE 'NESTLE%' AND
PRODUCT.PRODKEY=DAILY_SALES.PRODKEY AND
PERIOD.PERKEY=DAILY_SALES.PERKEY AND
T1.ITEM=ITEM_DESC AND
WEEK_ENDING_DATE='Jun 29 1996'
GROUP BY ITEM_DESC,EXP;
Query 7:
/* Query7
What are the units sold and revenue share of each of the products within
a given category or brand> */
SELECT ITEM_DESC, T1.UNITS AS UNITS, T1.UNITS_RATIO AS UNITS_RATIO,
T1.REVENUE AS REVENUE, T1.REVENUE_RATIO AS REVENUE_RATIO FROM
(SELECT ITEM_DESC
,SUM(QUANTITY_SOLD) AS UNITS
,RATIOTOREPORT(UNITS)*100 AS UNITS_RATIO
,SUM(EXTENDED_PRICE) AS REVENUE
,RATIOTOREPORT(REVENUE)*100 AS REVENUE_RATIO
FROM PRODUCT, PERIOD, DAILY_SALES
WHERE PRODUCT.PRODKEY=DAILY_SALES.PRODKEY AND
PERIOD.PERKEY=DAILY_SALES.PERKEY AND
ITEM_DESC LIKE 'NESTLE%' AND
WEEK_ENDING_DATE='Jul 27 1996'
GROUP BY ITEM_DESC)
AS T1(ITEM_DESC, UNITS,UNITS_RATIO,REVENUE,REVENUE_RATIO)
ORDER BY ITEM_DESC
BREAK BY ITEM_DESC SUMMING 2,3,4,5;
Query 8:
/* Query8
Based on revenue for a given brand, what is the revenue per store?
Products should be grouped by store, current week, prior week, and
prior month totals? */
SELECT STORE_NUMBER,
SUM(CASE WHEN ((CALENDAR_DATE >= '8/8/1996')
AND (CALENDAR_DATE < '8/14/1996'))
THEN EXTENDED_PRICE ELSE 0 END) AS CURR_PERIOD,
SUM(CASE WHEN ((CALENDAR_DATE >= '8/1/1996')
AND (CALENDAR_DATE <= '8/7/1996'))
THEN EXTENDED_PRICE ELSE 0 END) AS PRIOR_WEEK,
SUM(CASE WHEN ((CALENDAR_DATE >= '7/1/1996')
AND (CALENDAR_DATE <= '7/28/1996'))
THEN EXTENDED_PRICE ELSE 0 END) AS PRIOR_MONTH
FROM PERIOD,PRODUCT,DAILY_SALES,STORE
WHERE PRODUCT.PRODKEY=DAILY_SALES.PRODKEY
AND PERIOD.PERKEY=DAILY_SALES.PERKEY
AND STORE.STOREKEY=DAILY_SALES.STOREKEY
AND CALENDAR_DATE BETWEEN '7/1/1996' and '8/14/1996'
AND ITEM_DESC LIKE 'NESTLE%'
GROUP BY STORE_NUMBER
ORDER BY STORE_NUMBER;
Query 9:
/* Query9 What was the actual revenue and forecasted revenue for store
number 11, for the weeks ending on Jan 9, 1993 and Jan 16, 1993? */
SELECT SUM(EXTENDED_PRICE) AS ACTUAL_REVENUE, SUM(EXTENDED_PRICE_FORECAST)
AS FORECASTED_REVENUE
FROM DAILY_SALES, STORE, PERIOD, PRODUCT, DAILY_FORECAST
WHERE
DAILY_SALES.STOREKEY=STORE.STOREKEY AND
DAILY_FORECAST.STOREKEY=STORE.STOREKEY AND
DAILY_FORECAST.STOREKEY=DAILY_SALES.STOREKEY AND
DAILY_SALES.PERKEY=PERIOD.PERKEY AND
DAILY_FORECAST.PERKEY=PERIOD.PERKEY AND
DAILY_SALES.PERKEY=DAILY_FORECAST.PERKEY AND
DAILY_SALES.PRODKEY=PRODUCT.PRODKEY AND
DAILY_FORECAST.PRODKEY=PRODUCT.PRODKEY AND
DAILY_SALES.PRODKEY=DAILY_FORECAST.PRODKEY AND
STORE_NUMBER='11' AND
WEEK_ENDING_DATE IN ('9/07/1996','9/14/1996');
Query 10:
/* Query10
What was the actual revenue and cost and projected revenue and cost
for given categories of advertised products at a store over a two
week period? */
SELECT
SUM(EXTENDED_PRICE) AS ACTUAL_REVENUE,
SUM(EXTENDED_COST) AS ACTUAL_COST,
SUM(EXTENDED_PRICE_FORECAST) AS PROJECTED_REVENUE,
SUM(EXTENDED_COST_FORECAST) AS PROJECTED_COST
FROM STORE, PERIOD, PROMOTION, PRODUCT, DAILY_SALES, DAILY_FORECAST
WHERE
DAILY_SALES.PERKEY=PERIOD.PERKEY AND
DAILY_SALES.STOREKEY=STORE.STOREKEY AND
DAILY_SALES.PRODKEY=PRODUCT.PRODKEY AND
DAILY_SALES.PROMOKEY=PROMOTION.PROMOKEY AND
DAILY_FORECAST.PERKEY=PERIOD.PERKEY AND
DAILY_FORECAST.STOREKEY=STORE.STOREKEY AND
DAILY_FORECAST.PRODKEY=PRODUCT.PRODKEY AND
DAILY_SALES.PRODKEY=DAILY_FORECAST.PRODKEY AND
DAILY_SALES.STOREKEY=DAILY_FORECAST.STOREKEY AND
DAILY_SALES.PERKEY=DAILY_FORECAST.PERKEY AND
STORE.STORE_NUMBER='11' AND
PERIOD.WEEK_ENDING_DATE IN ('Oct 5 1996','Oct 12 1996') AND
PROMOTION.PROMODESC='Advertisement' AND
PRODUCT.CATEGORY IN (12, 13, 22, 42);
Appendix C – POPS 測定結果一覧
ソフ
トウ
ェア
ハー
ドウ
ェア
SUN
RedBrick
5.17
Compaq
RedBrick6. RedBrick
1
6.1
RedBrick6.
1
IBM
RedBrick6.
2 Beta
AIX5.1
H70
Regatta
Sun
E4500
Enterprise
10000
Sun
Fire6800
Sun
Fire6800
32 x
750MHｚｘ
400MHz
８
UltraSPARC
-IIマイク
ロ・プロセ
ッサー
メモ ３２GB
８GB
リー
ディ Sun
A1000ディ
スク StorEdge
スクシステ
A5200 x 12 ム（ストラ
台
イピング）
（ミラー化
した全ディ
スク容量
2.4TB、実
際に使用し
たディスク
容量
1.2TB）
デー ３００GB
３００GB
タ量 （３００日
（フ 分）
ァク
トテ
ーブ
ルの
み）
デー 14GB/Hour 5.76GB/Hou
タの
r
ロー
ド
750MHzx12
750MHzx２
４
４８GB
４８GB
T3ディスク
システム
（ストライ
ピング）
T3ディスク
システム
（ストライ
ピング）
SCSI
ESS
24 HSG80
１８GBｘ６
StorageWORKS
21 18GB/15K RPM
21 36GB/10K RPM
72 18GB/15K RPM
72 36GB/10K RPm
３００GB
３００GB
２TB （７３３日
分）
４TB（１４６６
日分）
８TB（２９３２
日分）
CPU
AlphaServer
GS320 running
Tru64 V5.1A
(Rev 1885)
8 QBBs (Quad
RS64-II
Building
340MHz x 4
Blocks). Each
with 4 1Ghz
CPUs and 16 Gig
RAM
16x8GB=128GB
２GB
３２GB
１０日分
（１０GB）
Daily_Sale
s
Rows/minut
es
Daily_Fore
cast
4.97GB/Hou 40GB/Hour
r
11.1GB/Hou 7.4GB/Hour 196GB/Hour
r
Daily_Sales
13,735,651Rows/
minute
Daily_Forecast
5069571
Rows/minute
１００、２００、 ３０、６
10,25,50,1 10,25,50,1 100,200,500,100 10
０、１００ 00,200,300 00,200,300 0
３００
,400,500
,400,500
ユー 67秒、１３ ５７秒、１ 25,43,85,1 25,26,38,6 3000,
3000秒
ザ数 １秒、２９ ４８秒、１ 72,343,453 7,129,180,
1,5,10,50,
100,300
2065sec at
50users
と
,578,654
196,340
７秒
９６秒
応答
時間
（秒
）
コメ 詳細レポー Query4が違 Query4が違 Query4が違 Query1-10の合計 Query１−
ント トなし
う
う
う
１０の合計
ROLT
57.1
329.4
P値
（8way）
164.7(4way
)
rPer
2.2*1
12.72
f
（8way）