170 likes | 267 Views
Spatial Joins Using R-trees: Breadth-First Traversal with Global Optimizations. Yun-Wu Huang, Ning Jing Proceedings of the 23rd VLDB Conference Athens, Greece, pp.396-405, 1997. 資料作成 2001年10月15日 作成者 長野 英彦. R-tree join の流れ. 全体の流れ ルートノードから順にリーフノードまで MBR の join を行なう 結果は、オブジェクトへの参照の組 の集合.
E N D
Spatial Joins Using R-trees: Breadth-First Traversal with Global Optimizations Yun-Wu Huang, Ning JingProceedings of the 23rd VLDB Conference Athens, Greece, pp.396-405, 1997 資料作成 2001年10月15日 作成者 長野 英彦
R-tree joinの流れ • 全体の流れ • ルートノードから順にリーフノードまでMBRのjoinを行なう • 結果は、オブジェクトへの参照の組 の集合 2つのtreeを使用してMBRでのjoin R-tree Join の関連研究 [1] Brinkhoff, T., Kriegel, H., and Seeger, B., “Efficient Processing of Spatial Joins Using R-trees”, Proc. of the 1993 ACM SIGMOD Int. Conf. on Management of Data, 1993,pp.237-246
DFRJ[1]の基本的なアルゴリズム • DFRJ: Depth-First R-tree Join ①ルートノード同士でMBRが交差するエントリを求める ② ①でエントリが見つかると再帰的に部分木に降ってMBRが交差するエントリを求める SpatialJoin(R, S: R_Node); (*height of R is equal height of S *) FOR (all ES∈S) DO FOR (all ER∈R with ER.rect∩ES.rect≠φ) DO IF (R is a leaf page) THEN (* (S is also a leaf page) *) output (ER, ES) ELSE ReadPage (ER.ref); ReadPage (ES.ref); SpatialJoin1(ER.ref, ES.ref) END END END END SpatialJoin1; DFRJの基本的なアルゴリズム
R S [1]での主な工夫(1) • restricting the search space • 2つのノードのエントリ間での交差判定 R∩Sと交差しないMBRは相手のノードのMBRとは交差しない まずR∩Sと交差するMBRを見つけ、その後、相手のノードのMBRと交差判定を行なう R,Sはノード中の全てのMBR を含むMBR
[1]での主な工夫(2) • spatial sorting and plane sweep • 2つのMBR集合間での交差判定 Y MBRの最小の点を使用し、 それぞれの軸でソート r1 s2 s3 r3 x軸 < r1,s1,r2,s2,r3,s3 > y軸 < r2,s1,r3,r1,s2,s3 > s1 r2 X ソート後の最初のMBRから交差判定を開始 ・ r1とx軸上で交差するsのMBRを求めるs2以降はr1の最大の点よりも右にあるので調べない ・ r1と交差したMBRについては、y軸上でも交差するかを調べる
[1]での主な工夫(3) • local plane-sweep order with pinning • 子ノードの読み込み順の決定 r3 s2 plane sweepの順序では (r1,s2), (r2,s1), (r3,s2), (r4,s2) の順で交差 r1 r4 s1 r2 この順序で子ノードの処理を行なうとs2の子ノード読み込みが複数回になる 交差している回数の多いノードから処理を行なう (r1,s2), (r3,s2), (r4,s2), (r2,s1)
oidS oidR 2 1 2 2 oidS oidR 5 6 6 6 5 4 この論文でのR-tree Joinの手法 • 中間結果を保存しておいてBreadth-FirstでR-treeを探索 node同士で join level 0 (root) level 0 (root) 1 2 1 2 oid 0 oid 0 intermediate Join Index at level 0 node同士で join level 1 (leaf) level 1 (leaf) 3 4 5 6 3 4 5 6 oid 2 oid 1 oid 2 oid 1 高さ2のR-tree R 高さ2のR-tree S candidate set
spatial join indexのデータ構造 R-tree Rのノードを指すitem (oidRとする)と R-tree Sのノードを指すitem (oidSとする)の2つの属性を持つタプル<oidR, oidS>の集合 論文中のjoin indexの例
この論文での主な工夫 ① Ordering of IJIs • intermediate join indexのエントリをソート ② Memory Management of IJIs • IJSをメモリ上に置いておくか、diskに書き込むか ③ Buffer Management of IJIs • buffer managerがどのページが必要か判断 • [1]の論文中での • restricting the search space • spatial sorting and plane sweep も使用
① Ordering of IJIs • intermediate join indexのエントリをソート • 同じページを何度も読み込まないために • 何もしない(OrdNon) • plane sweepの出力のまま • 片方のR-treeのノードの並びのみを最適にする(OrdOne) • ノードoidR,oidSのMBRの中心点の和sorkey=(lxoidR+hxoidR)/2+(lxoidS+hxoidS)/2のx座標でソート(OrdSum) • oidRのMBRとoidSのMBRを囲むMBRの中心点のx座標でソート(OrdCen) • oidRのMBRとoidSのMBRを囲むMBRの中心点をHilbert curveでソート(OrdHil)
② Memory Management of IJIs • IJSをメモリ上に置いておくか、diskに書き込むか • StorDisk: IJIをdiskに書き込む • IJIのエントリをソート後、diskに書き込む • 必要になったときにdiskから読み込む • 利点:メモリを多く使用できる • 欠点:IJIのためにdisk I/Oのコストがかかる • StorMem: IJIはメモリに置いておく • IJIのサイズがメモリより小さくなくてはならない • joinの計算中もずっとIJIはメモリ上にある • 利点:IJIのためのdisk I/Oのコストはかからない • 欠点:IJIがある分 メモリを多く使用する
③ Buffer Management of IJIs • 将来どのページが必要になるかを判断 • 将来再び使用するページはなるべくメモリに置いておく • ページに対して pin, unpin, purgeの処理を行なう • pin: マークpinを付け、ページをbufferに残す • unpin: マークpinを消す • purge: bufferからそのページを取り除く • IJIを作成するときに、各ノードの出現回数をカウントしておく • カウンタが1以上(再び使用する)ならばマークpinをそのページに付ける • カウンタが0になったページはunpin, purgeを行なう
実験 • ページI/Oの数を測定 • buffer sizeを100KB~1200KBまで変化させる 実験1: Ordering of IJIs • buffer size 500KB未満 • OrdOneがページI/Oの数が最小 • buffer size 600KB以上 • OrdSumがページI/Oの数が最小 実験2: Ordering of IJIs + Memory Management of IJI • buffer size が小さいとき(100KB~500KB) • OrdOne+StorDiskがページI/Oの数が最小 • buffer size が中程度のとき(500KB~800KB) • OrdSum+StorDiskがページI/Oの数が最小 • buffer sizeが800KBより大きいとき • OrdSum+StorMemがページI/Oの数が最小
実験 実験3: Buffer Management of IJIを適用する (PinYes)か、適用しない(PinNo)か • buffer size 100KB~500KBまではOrdOne • buffer size 100KB~300KBまで • StorDisk + PinNo がページI/Oの数が最小 • buffer size 400KB~500KBまで • StorMem + PinYes がページI/Oの数が最小 • buffer size 500KB~1200KBまではOrdSum • buffer size 600KB~700KBまで • StorDisk + PinYes がページI/Oの数が最小 • buffe size 700KB以上 • StorMem + PinYes がページI/Oの数が最小
ここまでの実験の結論 • buffer sizeが小さいとき • OrdOne + StorDisk + PinNo • buffer sizeが中程度のとき • OrdOne + StorMem + PinYes • buffer sizeが大きいとき • OrdSum + StrMem + PinYes • StorDiskより、diskとメモリ間のデータ転送のオーバヘッドが無い分よいだろう
実験: DFRJとの比較 • CPUコスト + I/Oコスト(ページI/Oの数×ページアクセスの平均時間)を測定 • buffer size 100KB~1200KBまで • OrdOne + StorDisk + PinNO とDFRJとの比較 • 700KBまではOrdOne+StorDisk+PinNoの方が性能がよい • 800KB以降はDFRJの方が性能がよい • buffer size 200KB~1200KBまで • OrdSum + StorMem + PinYesとDFRJとの比較 • 400KBまではDFRJの方が性能がよい • 500KB以降はOrdSum+StorMem+PinYesの方が性能がよい
結論 • R-tree joinの新しい手法を提案した • BFRJ: Breadth-First R-tree Joins • BFRJの性能向上のための3つの工夫を提案した • ordering • memory management • buffer management • 実験により • システムのリソースに併せたアルゴリズムの最適な組み合わせが分かった • 最適な組み合わせでは、DFRJより最大で50%処理速度が向上するという結果が得られた