400 likes | 675 Views
打ち合わせ資料 ~ Join の実験結果報告~. 2002/12/11 笹栗 茂. 実験目的. 提案手法が実データでどれくらい有効か調査 Join で制御した場合の影響の調査. 実験内容. 従来手法 vs 提案手法 Control vs Non-Control 多次元( 2 次元)での Join 1 次元 vs 多次元. 実験について. 環境 OS : FreeBSD4.5 CPU : PentiumⅢ 1 GHz メモリ: 512MB. 使用するデータ TPC-H Lineitem テーブル Part テーブル
E N D
打ち合わせ資料 ~Joinの実験結果報告~ 2002/12/11 笹栗 茂
実験目的 • 提案手法が実データでどれくらい有効か調査 • Joinで制御した場合の影響の調査
実験内容 • 従来手法 vs 提案手法 • Control vs Non-Control • 多次元(2次元)でのJoin • 1次元 vs 多次元
実験について 環境 OS :FreeBSD4.5 CPU :PentiumⅢ 1GHz メモリ:512MB • 使用するデータ • TPC-HLineitem テーブル Part テーブル • 次元数 5次元 • データ数 Lineitem×Part 60000×2000 600000×20000 • 使用するクエリ Joinのみ - 1次元(キー属性)でEqui-Join TPC-Hクエリ 14, 17 • 測定項目 ノードアクセス数 10回試行した平均 経過時間: Cold 1回試行 Hot10回試行した平均
インデックスに使用する属性 Part Lineitem
使用するTPC-Hクエリ Query14 select 100.00 * sum(case when p_type like ‘PROMO%’ then l_extendedprice *(1-l_discount) else 0 end) / sum(l_estendedprice*(1-l_discount)) as promo_revenue from lineitem, part where l_partkey = p_partkey and l_shipdate >= date’[DATE]’ and l_shipdate < date’[DATE]’ + interval ‘1’ month; 1%
Query17 select sum(l_extendedprice)/7.0 as avg_yearly from part, lineitem where p_partkey = l_partkey and p_brand = ‘[BRAND]’ and p_container = ‘[CONTAINER]’ and l_quantity < ( select 0.2 * avg(l_quantity) from lineitem where l_partkey = p_partkey ); 4% 2.5% 10% 60000×20005.10516 600000×20000 5.10667
実験1:従来手法 vs 提案手法 • 作成した木: • R*-tree, 正規化R*-tree(NR*-tree) • 木について
実験1:結果 データ数 60000×2000 • ノードアクセス数
実験1:結果 データ数 60000×2000 • 経過時間(Cold)
実験1:結果 データ数 60000×2000 • 経過時間(Hot)
考察 • ノードアクセス数は提案手法で減少 • 非正規化の方が大きく減少 • 経過時間に関して • Cold 提案手法が遅い ノードアクセス数が減っても読み出すノードの種類は同じ (ページフォールト回数は同じ) 同じノードを複数回読み出す。1度読み出すとメモリにのっている • Hot 提案手法の方が速い ノードアクセス数が減ると比較回数も減るのでCPUコストを減らすことができている
実験1:結果 データ数 600000×20000 • ノードアクセス数
実験1:結果 データ数 600000×20000 • 経過時間(Cold)
実験1:結果 データ数 600000×20000 • 経過時間(Hot)
考察 • ノードアクセス数に関して • 非正規化:提案手法で減少 • 正規化:提案手法でわずかに増加 • 提案手法があまり効果がない状況だと1度葉に下りる分のノードアクセスがオーバーヘッドとなる • 経過時間に関して • Cold • 60000×2000と同様 • Hot • ノードアクセス数が減少している非正規化では提案手法の方が速い
実験2:Control vs Non-control • 作成した木 Controlled R*-tree×4 • 制御比 • キーに重要度 • キー以外に重要度 • Query 14 • Query 17
実験2:木について • データ数 60000×2000 • データ数 600000×20000
実験2:結果 データ数 60000×2000 • ノードアクセス数 非正規化を除けば各クエリでBestと考えられる制御が最も効率的 制御2を除いた木で提案手法が効率的 制御2は提案手法が効率的となるクラスタリングとならない
実験2:結果 データ数 60000×2000 • 経過時間(Cold)
実験2:結果 データ数 60000×2000 • 経過時間(Hot)
実験2:結果 データ数 600000×20000 • ノードアクセス数
実験2:結果 データ数 600000×20000 • 経過時間(Cold)
実験2:結果 データ数 600000×20000 • 経過時間(Hot)
実験3について 環境 OS :FreeBSD4.5 CPU :PentiumⅢ 1GHz メモリ:512MB • 使用するデータ • TPC-HLineitem テーブル Partsupp テーブル • 次元数 4次元 • データ数 Lineitem×Partsupp 60000×8000 • 使用するクエリ Joinのみ - 2次元(キー属性)でEqui-Join • 測定項目 ノードアクセス数 10回試行した平均 経過時間: Cold 1回試行 Hot1回試行
インデックスに使用する属性 Partsupp Lineitem
実験3:2次元Joinでの従来手法 vs 提案手法 • 作成した木: • R*-tree, 正規化R*-tree(NR*-tree) • 木について
実験3:結果 データ数 60000×8000 • ノードアクセス数 • 経過時間Cold
実験3:結果 データ数 60000×8000 • 経過時間Hot • NR*-Treeでは提案手法でノードアクセス数が減るがCold、Hotの両方で経過時間増 • 提案手法でしか用いないメソッドがあるのでこの程度のノードアクセス数の減りだとその分の処理などで時間が増えていると考える
実験3:1次元 vs 多次元 • Join+Restrictionで多次元インデックスの有効性を調査するための実験 • 葉ノードと中間ノードの構造が違うR*-tree(葉ノードは点、中間ノードはMBR)にJoinを実装 • 作成した木 • 1次元正規化R*-tree(キー属性のみ)、葉ノードは5次元 • 5次元正規化R*-tree
今後について • 効果のあった場合のクラスタリング状況について調査 • 2次元の場合で制御・Restrictionを入れて実験
提案手法について • 葉の1つ上のノードで探索用のMBRを作成 • 葉の1つ上のノードでエントリの交差判定を行う際、1度葉ノードに下る • 葉の1つ上のノードの交差領域における葉ノード内の最小点と最大点でMBRを作成してエントリの交差判定 C ② D B ⑤ 3 A 2 Join ③ ⑥ 4 1 ④ ① C 主キー キー 探索用のMBR
例 ② D B ⑤ 3 キー属性で Equi-Join A 2 ③ ⑥ 4 1 ④ ① C 主キー キー A B C D A B C D 1 2 3 4 ① ② ③ ④ ⑤ ⑥ 1 2 3 4 ① ② ③ ④ ⑤ ⑥ AとCの交差領域内の MBR1中の点の最小点と最大点で探索用MBRを作成 探索用MBR と交差判定 A B C D A B C D 1 2 3 4 ① ② ③ ④ ⑤ ⑥ 1 2 3 4 ① ② ③ ④ ⑤ ⑥ MBR③は最小点≦ ③ ≦最大点で構成されていないので下位ノードの探索は不要
課題点 • 探索用のMBRを作成する際、最小点が交差領域の最小に近くまた最大点が交差領域の最大に近い場合は効果無し • 葉ノードに1度下り、MBRを作成するので従来に比べ余分な処理を必要 C D B ② ⑤ 3 A 2 Join ⑥ 4 1 ④ ① ③ AとCの交差領域における最小点と最大点で探索用MBRを作成 この領域の探索(Eg. ②)は無駄