Packed R*-tree の性能評価実験の結果と今後の予定

Packed R*-treeの性能評価実験の結果と今後の予定金子研究室　M1 峯肇史

本研究の背景 • 多次元空間の空間問い合わせ • 最も一般的に用いられているインデックスはR*-tree • R*-tree生成法 • オリジナル • 動的にインデックスを作成 • Packing • 静的にインデックスを作成 • スペース効率（ディスク使用領域)が良い

本研究の目的 • SunOSのメモリ管理の特徴 • SunOSでは,一度メモリ上に載せたデータはプログラムが終了してもOSがメモリ上に保持して,再利用する • 同じプログラムを数回実行しても,最初の1回しかディスクにアクセスしてない • 本研究の目的 • SunOSのメモリ管理の特徴を考慮した上でオリジナルとpackingのR*-treeの性能評価を行う • メモリ中のデータをプログラムごとにクリアするメモリプログラムが終了してもOSがメモリ上のデータを保持ディスク

測定プログラム struct timeval tp1, tp2; gettimeofday(&tp1, (struct timezone *)NULL); // 現在時刻をtp1にセット totalResult = count_intersect(); // 測定したい関数 gettimeofday(&tp2, (struct timezone *)NULL); // 現在時刻をtp2にセット printf(stderr, "time = %f\n", (double)(tp2.tv_sec - tp1.tv_sec) +(double)(tp2.tv_usec - tp1.tv_usec)/1000000.0); // tp2からtp1の値を引くことにより測定したい関数の処理にかかった実時間を計算（ディスクアクセス時間も含む）

Solaris の性能測定用関数 • gettimeofday()　標準Cライブラリ関数 • 現在時刻を計測 • 測定したい項目の開始前と終了後の時刻を測定することにより,実行にかっかった実時間を測定可能 • getrusage() 標準Cライブラリ関数 • プロセスが使用した,CPU時間を測定 • vmstat Solaris systemコマンド • Memory,ディスク,CPUの使用状態の統計をレポートするコマンド • ディスクI/Oの統計を表示 • CPU時間の統計を表示 • メモリ使用の統計を表示

MBR(minimum bounding rectangle) Y X R*-tree • R*-treeの構造中間ノード中間ノードのエントリ (子ノードへの参照、MBR) 葉ノード葉ノードのエントリ (オブジェクトへの参照、MBR) MBR 生成法 R*-tree

MBR Packed R*-tree Packed R*-treeの生成法 • 空間中のオブジェクトの集合をグループに分割 (各グループの要素数はノードに格納できるオブジェクトの最大数) • Nearest-X : MBRの最小点のX軸でオブジェクトをソートして分割 *1 • Hilbert Sort : Hilbert Curveを引いてオブジェクトをソートして分割 *2 • Sort Tile Recursive : 各軸でソートしてオブジェクトを分割 *3 • グループ中のオブジェクトを1つのノードに詰め込むことによりR*-treeを生成 • スペース効率が向上のよりノード数が減り木の高さが減少するので検索性能も向上 *2 *1 N.Roussopoulosand D.Leifker. “Direct spatial search on pictorial database using packed r-trees” Proc. ACM SIGMOD May 1985. *2 Kamel I,Faloutsos C. “On Packing R-trees”,Proc 2nd International Conference on Information Knowledge Management (CKIM-93), p.490-499, Arlington,VA, November 1993 *3 S. Leutenegger, M. A. Lopez, and J. Edington. STR: A simple and efficient algorithm for R-tree packing. In Proc. 13th IEEE International Conference on Data Engineering, pages 497--506, 1997.

Hilbert Sort(1) • データ空間のサイズはあらかじめ決定している • MBRの場合MBRの中点をHilbert Curveでソート • Hilbert Curve（2次元）(右図） • 空間を分割してその空間をすべて通る線を引ける • 線の順に空間に番号を付けることにより空間をソート可能 • 空間分割数を増やしていく方法 • まず(a)を基本とする.空間の順番は左下から線を引く順 • (b)は空間を4分割して上の二つには(a)をそのまま当てはめる • 左下の空間には（a)を時計周りに90°回転させたものを当てはめる • 右下の空間には（a)を反時計周りに90°回転させたものを当てはめる • 上の空間の空間の順番は(a)と同じ順番 • 下の空間の空間の順番は(a)と逆の順番この操作を再帰的に繰り返すことにより空間分割数を増やしていくことが出来る (a) (b) (c)

(x,y) Hilbert Sort(2) • 2次元空間中の点（X,Y）がHilbert Curveでソートした場合に何番目の空間に入るかは以下のように再帰的に計算できる • 空間サイズ,空間分割数はあらかじめ指定しておく • 空間を4分割する • (X,Y)がどの空間に入るかを調べる • (X,Y)が入っている空間が何番目の空間から始まるか計算できる • (X,Y)の入っている空間が回転が必要か,順番をつける向きが逆かがわかる • (X,Y)が入っている空間を再び4分割する. • (X,Y)の入っている空間の順番を先ほどの入っていた空間から計算できる. • このような操作を再帰的に繰り返していくことにより2次元空間中の点(X,Y)の空間番号を計算できる. • Hilbert Curveを用いてPacking R*-treeを生成する場合に空間をいくつに分割するかは,論文中*2には明記されていない. *2 Kamel I,Faloutsos C. “On Packing R-trees”,Proc 2nd International Conference on Information Knowledge Management (CKIM-93), p.490-499, Arlington,VA, November 1993

実験ｰ実験環境 • Machine • Sun Ultra-10 Workstation • CPU – 440MHz UltraSPARC • Memory – 768MB • Disk - 32GB • OS • SunOS 5.8 • DBMS • 出世魚

実験ｰインデックス生成 • インデックスを構築するデータ • 3次元空間中の3自由度のMBR(直方体) • MBRの最小点の座標値はランダムに発生させた値 • MBRの生成方 • [0,1]の間でランダムな値を生成してMBRの最小点(minx)とする • [0,1]の間でランダムに発生させた値に0.1をかけたものをminxに加えてMBRの最大点(maxx)とする • 以下ｙ,ｚ軸についても同様の操作を繰り返す • 各軸での１つのMBRの広がりは10%以内 • １つのMBRの占める体積は全データ空間の0.1%以内 • MBRは一様分布している • データ数 : 1000,10000,100000,1000000 • パッキング時のグループ化はSort TileRecursiveを使用 • Sort Tile Recursiveを提案している論文*1で検索性能が一番良いとされていたため *1 S. Leutenegger, M. A. Lopez, and J. Edington. STR: A simple and efficient algorithm for R-tree packing. In Proc. 13th IEEE International Conference on Data Engineering, pages 497--506, 1997.

実験ｰインデックス生成 • 生成にかかるレスポンスタイムを測定 • DBオープン • 出世魚のメモリ空間にインデックスの領域を確保 • 確保したページすべてに管理情報の書き込み • インデックスを作成するデータの読み込み • インデックス生成 • DBクローズメモリディスク出世魚のメモリ空間

実験結果ｰインデックス生成 insert time 10000 original packing 1000 Originalを100とした場合の生成時間 response time [s] 100 10 1 1000 10000 100000 1000000 number of data インデックス生成後の総ノード数（）内はOriginalを100とした場合の相対値

データの挿入順序 • Original • Packing Indexを構築するデータ先頭から順順に挿入 Tree Indexを構築するデータ STRでソートソード済みデータグループ化したデータをノードにpack node node node node

Sort Tile Recursive のソートアルゴリズム template< class T > void RSTree<T>::tmp_sort( vector< LeafCell<T> > & vec, long top, long last, int axis ){ if( top < last ){ int somewhere = top+((last-top)/2); LeafCell<T> tmp_data = vec[somewhere]; vec[somewhere] = vec[top]; long p = top; for( long i = top+1; i < last; i++ ){ if( comp_mbr_axis( vec[i], tmp_data, axis) ){ p++; LeafCell<T> swap_tmp = vec[p]; vec[p] = vec[i]; vec[i] = swap_tmp; } } vec[top] = vec[p]; vec[p] = tmp_data; tmp_sort( vec, top, p, axis ); tmp_sort( vec, p+1, last, axis ); } } // x軸でソート sort_by_x( vec, 0, vec.size() ); #if DIM == 2 // 2次元の場合 // x軸でソートしたものをpartitionごとにy軸でソート long entryParPartition_y = vec.size()/partition; long j = 0; while( j < (long)vec.size() - entryParPartition_y ){ sort_by_y( vec, j, j+entryParPartition_y ); j += entryParPartition_y; } sort_by_y( vec, j, vec.size() ); sort_by_x,sort_by_yからtmp_sortを呼び出してソートする tmp_sort : quick sort

実験考察ｰインデックス生成 MBR • Packingの方がOriginalよりも速い理由 • 挿入コストの違いによる • Packing • データを各軸でソート • Original • 挿入するノードの選択 • MBRのAreaの拡大やOverlapの拡大の計算 • ノードがあふれたときの再挿入処理 • ノードがあふれたときの分割処理 • Packingのほうが総ノード数がオリジナルより2割ほど減少 • Packingではノードにエントリを入るだけ詰め込むため Overlap Areaの拡大

実験 –検索 • インデックスは先ほど生成したものを使用 • 検索 • 検索領域としてMBRを与える • 検索領域と交差するオブジェクト数を求める • 測定項目 • レスポンスタイム • 検索時にディスクから読み込んだ総ノード数(ページ数) オブジェクト検索領域

実験 –検索1 • 検索1 • 検索領域 • データ空間中のランダムな3自由度のMBR(直方体) • 1つのMBRの体積は全空間の0.1%以内 • 検索領域を毎回変えて,検索を連続して100回実行 • 検索1 (Warm) • 検索1を1回行う • 検索1 (Hot) • 検索1を行い,続けて再び検索1を行う検索するノードメモリ全空間ディスクから読み込み検索領域ディスク

実験結果 –検索1 検索1 1 original warm packing warm original hot 0.1 packing hot 0.01 Originalを100とした場合の1回あたりの検索時間 response time [s/query] 0.001 0.0001 1e-005 1000 10000 100000 1e+006 number of data ※グラフは検索1回あたりの反応時間検索時に読み込んだの総ノード数(Warm)

実験 –検索2 • 検索2 • 検索領域 • MBRを1つ用意 • MBRの体積は全空間の1% • 1度だけ検索を行う • 検索2(Cold) • 検索2を1回行う • 検索2 (Hot) • 検索2を行い,続けて再び検索2を行う検索するノードメモリ全空間ディスクから読み込み検索領域ディスク

実験結果 –検索2 検索2 10 original cold packing cold 1 original hot packing hot response time [s] 0.1 Originalを100とした場合の1回あたりの検索時間 0.01 0.001 0.0001 1000 10000 100000 1000000 number of data 検索時に読み込んだの総ノード数(cold)

実験考察 –検索（1） • ColdやWarmの場合の検索 • データ数が1000,10000のとき検索結果にほとんど差はない • アクセスページ数が少ないのでI/Oコストの差が出ない • データ数が増えるとpackingのほうが検索が速い • Packingの方が総ノード数が少ないために検索時にアクセスするノード数(ページ数)が少なくなる • 結果的にPackingの方がI/Oコストを抑えることが出来ている

実験考察 –検索（1） • Hotの場合の検索 • すべてのデータにおいてoriginalの方が検索が速い • Hotの場合の検索コスト • ノードのエントリと検索領域の交差判定 • Originalの場合ノードにエントリがぎっしり詰まっていないのでノードでの交差判定コストが少ない • Originalのノードの使用率は約8割ほど（生成実験より） • Originalの検索時に辿るノードをNO • Packingの検索時に辿るノードをNP NO×0.8 < NP であればHOTの検索はOriginalが速いノード内のエントリ検索するノード検索領域メモリ検索時に辿ったノード内のすべてのエントリは検索領域との交差判定を行う

結論 • 挿入 • Packingの方がOriginalより高速 • 検索 • Coldでは,Packingが高速 • Hotでは,Originalが高速 • 一般的に用いる場合 • インデックス構築を高速に行いたい • Packingの方が有利 • 検索効率を上げたい • Coldでの使用が多い • Packingが有利 • Hotでの使用が多い • Original有利 • データ数が少ない場合はどちらでも差はほとんど無い

今後の予定 • （Hawks）の実装 • 長野さんの概念設計を基に詳細設計を行い実装 • KUAROデータベース

今後の予定 • データの収集 • 工学研究院環境都市部門の梶田生成からデータをいただく • 梶田先生がお持ちのデータの形式であるShape形式についての説明を梶田先生にしていただく

Packed R*-tree の性能評価実験の結果と今後の予定