Multidimensional Index Structures in Relational Databases

1. 知能システム学演習第二（論文紹介）　2002年5月7日知能システム学演習第二（論文紹介）　2002年5月7日 Multidimensional Index Structures in Relational Databases Christian Bőhm, Stefan Berchtold, Hans-Peter Kriegel, Urs Michel, Journal of Intelligent Information Systems(JIIS), Vol.15, pp.51-70,2000 システム情報科学府　知能システム学専攻　 牧之内研究室　修士2年 龍　浩志

2. 背景① • 多くのデータ解析ツールにおける効率的な問い合わせ処理の必要性 • 高次元特徴空間上での効率的な検索 • Data miningツール • OLAP(On-Line Annalytical Processing)ツール ⇒企業の業務系システムにおいて蓄積された大量のデータの解析に活用 特徴空間：データベース内のオブジェクトから重要な特性を抽出した高次元 　　　　　　　ベクトルにより張られる空間 特徴ベクトルは高次元空間上の点データとして表現される 大量の高次元点データを効率的に処理する必要がある

3. 背景② • 多次元インデックス - 多次元空間上の高速な検索をサポート 範囲検索 最近接探索 与えられた点に 近い順にk個の オブジェクトを検索 与えられた範囲と 交差するオブジェクト を検索 • 主に地理情報システムなどで扱われる2次元地形データ • 　の管理を 考慮して設計 次元が増加すると問い合わせ処理性能の悪化

4. 背景③ • 高次元点データの商用データベースへの統合の関心の高まり • リレーショナルデータベース - 解析したいデータは企業の生産、販売、物流などの業務系システム で得られるデータ - リレーショナルデータベース管理システムが多く利用されている - 2次元の「表」の概念を基本としたデータモデルを基礎 としたデータベース - 会計処理などの標準的な処理やレポート、チャート、単純な視覚化 等の機能を備えている 発展した複雑なデータマイニングアルゴリズムなどで 高次元点データを効率的に扱えない

5. 背景④ • データベースの外に解析目的のため多次元インデックスを構築することにより検索の効率化 多次元インデックス データベース内外のデータの管理の欠点 ●両データの整合性の維持 一方の更新処理が失敗すると、他方のデータ も取り消さなければならない Data Table ●データベースシステムとファイルシステムの違い データのセキュリティ、バックアップなどの概念が異なる 両システムの混在により実装やアプリケーションの仕様変更が困難となる

6. 本論文での提案 • 高次元データのための多次元インデックス構造を直接リレーショナルモデルへマップ 基本的な概念 ●多次元インデックスで定義される概念（データページ、 　　データディレクトリ）などをリレーショナルモデル上でモデル化 ●新しいモデル上で定義される問い合わせ処理のアルゴリズム 　を対応するSQL文（問い合わせ言語）を用いて実行 提案手法の有効性を確認するため、高次元データに適した多次元 インデックスX-Tree[Berchitold,et al.1996]を商用データベース Oracle8上に実装

7. 高次元検索（類似検索） • データベースに格納されたN個のオブジェクトの中から、与えられたオブジェクトに似ているオブジェクトを取り出す オブジェクトの類似性はアプリケーションによって定義 カラー画像の場合、色の分散性などにより類似性を決定 Object Distance 2つのオブジェクト間の類似性を判断するための値（距離） 類似検索は与えられたオブジェクトとObject Distanceの近いものを検索 単純なアプローチ 　　データベース内のオブジェクトと与えられたオブジェクトを１つ１つ比較

8. 高次元検索（類似検索） • 特徴変換により効率化 オブジェクトから特徴を抽出し、d次元特徴空間上のベクトルに変換 Feature Distance 特徴空間上のベクトル間の距離 一般にFeature DistanceがObject Distance に対応するように特徴変換が行われる Feature Distance 特徴空間 類似検索は特徴空間上における検索へと変換される

9. リレーショナル上の類似検索 • d次元特徴ベクトルを格納した特徴テーブルを保持 Query d次元インデックス 問い合わせ(Query) Feature Table Data Table ①filtering step 多次元インデックスを走査し、Feature Tableから候補集合を集める 候補集合のうち実際にQueryを満たすものをData Tableを参照して決定 ②refinement step

10. 多次元インデックスの分類 • 多次元インデックス手法 • マッピング手法 d次元に対する問題に対し、d次元インデックス構造を用いる d次元空間の点や領域を1次元の値にマッピングし、既存の１次元 インデックス(B+-Treeなど)を用いる ●多次元インデックス手法の方が性能はしばしば良いが、マッピング手法の 　方が実装が容易 ●アプリケーションにとってどちらの手法が適切かは複雑で、データの分散、 　問い合わせの種類、データベースの次元、サイズに依存する

11. マッピング手法 • d次元の点を１次元にマップする２つの方法 • d次元空間上の点をそれぞれ異なる値の1次元値へマップ • 　　　　（d次元の点　１：１　１次元値） • １つの１次元値を複数のd次元の点で共有 • 　　　　（d次元の点　n:1 1次元値） 実際には両者の違いは存在しない 　　⇒１次元の値はCPUのサポートできる範囲に制限される 1次元値のみを用いたQuery処理はできないが、候補集合をある程度 絞込むことができる

12. マッピング手法の実装 • テーブルの属性に1次元キーのための新たな属性を追加 • 追加した属性上にインデックスをつける Query 問い合わせ処理 　①１次元キーに基づき候補集合を決定 　②Feature Tableを参照し候補集合の絞込み 　③Data Tableを参照し、検索結果を得る １次元インデックス Feature Table 1次元Key Data Table d次元ベクトル

13. トリガ、ストアドプロシージャ • 特徴テーブルへトリガを追加 • ストアドプロシージャ トリガ：　データベースへの更新があったときに、あらかじめ指定しておいた 　　　　　関数を自動的に呼び出すことができる機能 ここでは、挿入（更新）されたデータから1次元値を設定するトリガ SQL文の集合から構成され、トリガ内で呼び出される 挿入、削除の際のトリガを追加することによりインデックスを管理 トリガ、ストアドプロシージャという商用DBで一般に提供される機能をもちいて、容易に実装が行える

14. 階層インデックス構造の実装 • 階層インデックスの実装はマッピング手法より複雑 データを挿入するたびに構造が動的に変化 提案手法による実装が比較的容易に行え、 従来の実装法よりも適していることを示す 多次元インデックスX-Treeを商用DB上へ実装 階層インデックス構造 X-Tree：低次元で適した多次元インデックスR*-Tree を拡張し、高次元データを効率的に扱えるようにしたインデックス構造

15. R*-Tree [Beckmann,et al.1990] • 領域を軸に平行な辺による矩形（MBR）で表す • MBR同士の重なり(overlap)を許す • １ノードがディスク上の１ページに対応 A B B g 4 h A c 1 2 3 4 f b 2 3 1 d e a a b c d e f g h R*-Treeの構造 範囲検索では、与えられた範囲と交差するMBRを選択しながら、 根ノードから下位レベルへ辿る

16. ノード分割 • ノードでオーバーフローが起これば、分割アルゴリズムによりノードを２つに分割 できるだけOverlapが少なくなるように分割することが望ましい Overlapの少ない分割は存在するが、しばしば アンバランスな分割を生む ノードには最小エントリ数が決まっているので、 それを満たさない分割は避けられる Overlapを生み出す分割が行われる 高次元になるとOverlapが増加し、問い合わせ性能の悪化

17. X-Tree • R*-Treeの分割アルゴリズムを改良 • Overlapがある値より大きくなるような分割であれば分割を行わない SuperNodeを作る（ノードサイズを大きくする） R*-Treeよりも高次元において Overlapの少ない分割を実現 SuperNode X-Treeの構造

18. 提案手法による実装 • リレーショナルスキーマでX-Treeを実現 • X-Treeの各レベルに相当するTableを保持 高さKのX-TreeをK個のTableで表現 Directory Table MBRとポインタを格納 Data Table 点データを格納

19. データの挿入 • 挿入するデータページを決定 • オーバーフローが起これば、X-Treeの分割アルゴリズムを用いてノードを分割 • 根ノードの分割が起これば、木が一段増えるので新たなTableを追加 これらの操作は全てストアドプロシージャによって実装される

20. Tableの構成 • DATA　Table • Directory Table X-Treeのデータページに格納される情報を保持 x0 x1 pn tid • d次元データ(x0 ,…,xd-1) • タプル識別子 (tid) • ページ番号(pn) DATA Table lb0 ub0 lb1 ub1 pn child MBRの情報と子ノードへのポインタを格納 • MBR(lb0,ub0,…,lbd-1, ubd-1) • ページ番号(pn) • 子ノードへのポインタ(child) Directory Table

21. リレーショナルスキーマ • 連続するレベルはchildとpnでJoin（結合）が可能(1:n の関係) • 連続するレベルでのJoin操作を効率的に行うことが重要 属性pnにインデックスを設定 データテーブルへのアクセスを効率化するために、点データの圧縮した値のため の属性を追加しその属性(compr)にもインデックスを設定

22. データ圧縮 • d次元空間上の点はd個のfloating pointで定義される 次元dが増加すると1データ格納のための情報量が線形的に増加 高次元空間上の1データの各軸を表すのに必要な情報量を減らす Index ここでは、1軸を表すのに1 Byteを使用し、 d次元の配列(d Byte)として DATA Tableに属性を追加 x0 x1 pn tid Comp DATA Tableに割り当てられた インデックスにこの属性を追加 DATA Table

23. 範囲検索 • k個のリレーションをもつ場合の範囲検索処理のステップ数はk+1 • 根レベルのディレクトリを読み出し、検索範囲と交差する下位のページを • 　　　決定 • (1)のページを読み出し、検索範囲と交差する下位ページを決定 • (k-1)ステップ目終了時点で、検索範囲と交差するDATAページの番号が分かっている • DATAページには圧縮属性をもつので、 • 圧縮値を基に検索範囲と交差するデータを決定 • (k+1) 上で得られるデータを読み出し、d個の値により検索範囲と交差するかを判定

24. 範囲検索のSQL文 • Queryを単一SQL文への変換 リレーションの数が3の場合 クライアント/サーバ間の通信コストを考慮すると、問い合わせを 単一のSQL文に変換することが重要になる

25. Query実行プラン • SQL文を最適なQuery実行プランに変換することで、k+1個のテーブル間の結合操作をシーケンシャルスキャンよりも効率的に Query Optimizerにより 最適なプランが実行 される（gray arrows） DIRECTORY0 に関する操作 DIRECTORY1 に関する操作 DATA に関する操作

26. 性能評価① • インデックス作成時間（データ数100,000） ◆ - X-Treeのリレーショナル実装 ▲ - X-Treeの従来の実装法 ■ - 1つの属性にB-Treeを設定 トリガを使うことによるオーバーヘッド の増加が考えられる ランダムデータ

27. 性能評価② • 範囲検索性能（ランダムデータ） (データ数) (selectivity) （B-Tree） （圧縮手法） （X-Tree） - 圧縮手法、提案手法は シーケンシャルスキャンや B-Treeよりも効率的 - 両手法を組み合わせる ことでさらに性能向上

28. 性能評価③ • 範囲検索性能（ランダムデータ） （次元数） (selectivity) （B-Tree） （圧縮手法） （X-Tree） - 圧縮＋提案手法の性能が良い - データベースサイズの増加に 伴い、他の手法との差が拡大

29. 性能評価④ • 範囲検索性能（実データ） （B-Tree） （圧縮手法） （X-Tree） - 実データにおいても、 提案手法が効率的 - 圧縮手法の効果はほとんど 見られない

30. まとめ • 多次元インデックスのリレーショナルデータベースへの実装に関する新しい手法の提案 • トリガ、ストアドプロシージャを用いて、インデックスの動作をシュミレート • 性能実験により提案手法の有効性を確認