Transcript 2次インデクス

VLDB2000報告
その２：先進DB技術
（完成版）
DBWeb2000 (SigmodJ第16回大会資料）
2000年12月8日
大森 匡＠SIGMOD日本支部書記
（電気通信大学大学院
情報システム学研究科 www.is.uec.ac.jp）
ピラミッド間近で会議
復習： VLDB2000の全体像
• 方向１ -- 新しい情報システムにおける
インフラストラクチャとしての
DB的な要素技術
例： XMLフィルタリング (2)
Webマイニング (4), E-Commerce,
高次元データ, DWH, マイニング
• 方向２ -- DBエンジンの多様化
例： RISC型DB (1)、
SQLエンジンの改修 -XML管理(3)
（復習）1. RISC型データベースエンジン
(Microsoft, vision paper)
• DBシステムを
単純なコンポーネントの多層構造へ。
• 各コンポーネントは単純なAPIでつなぐ。
• APIあたりの性能予測性、性能調整能力
を明確にする。
提案：
RISC的なDBシステム
第１層＝ 表単位のselect,
B+木インデクス、
レコード更新、
トランザクションのみ。 SQLなし。
（ただの永続データストレージ）.
第２層＝ SPJ問い合わせと集約演算、
ストリーム並列まで。（OLAP,DSS)
第３層＝ フルSQL。
 例：OLE-DB API
• 何に適用するか？ （略）
-- OLTP, OLAP, メタデータ管理、
Eメールサーバ処理、
e-市場取引型データサーバ、
ニュースオンデマンドサーバ、
などのDBコアとして使う。
• オープンなRISC型データ管理コンポーネント
の研究。 
従来のDBサーバの枠を出て、IT分野向けの
DB的機能のサーバへ。
DBエンジン系の発表の流れ
• 1. RISC-style DB engine (Microsoft)
• *App.層の主記憶DBキャッシュ. (TimesTen)
• 3. XML作成用のSQLエンジン（IBM)
• 7. PicoDBMS (スマートカード内蔵DB)
• 8. Oracle8i Index-Organized Table （IOT).
• 5. SQLserverにおける実体化ビューの
自動選択 (MS)
• 6. データマイニングとRDBの統合（MS)
7. PicoDBMS:スマートカード向けDBMS
(C.Bobineau, .., P.Valduriez)
• Best paper of VLDB2000.
• 問題：スマートカード内蔵のDB機能とは？
スマートカード＝
ICチップ内蔵のプラスチックカード。
32bit RISC(30mips), ROM 96KB, SRAM 4KB,
EEPROM128KB+security unit.
電源はカードリーダから供給。
対象とする環境
• スマートカード内蔵のDBMS
どんな問題を考えているのか？

1. 利用者がカードに全個人データを格納。
2. 読み出し側は、データの読み取り、更新.
3. 集計ビューを通して統計値を読み出し、
後でセンタ側での集計に用いる。
従来との比較
• DBMSs of small footprint -- PDA用。
• SQLJava Machine DBMS, SCQL (ISO)
– 表１つへの選択演算のみ。
• PicoDBMS （Bull Smart Cards and
Terminals.）
-- 複雑な問い合わせ (join, group-by,
ビュー、 集計データのみの外部提供、な
ど）の実行。 Atomicity, Durability。
応用分野
• 電子マネー：
小データ量、原子性。
• DBからのダウンロード：大データ量、SPJ+group.
• ユーザの環境データ： 中データ量、SP query,
ビュー機能による外部からのアクセス制限、
原子性、 持続性。
• 個人データ全部のフォルダ：SPJ+group query,
アクセス制御、ビュー、原子性、持続性
ストレージモデル
１ 固定長レコード表 （FS) -- 全スキャン。
２ ドメイン型記憶 （DS)
表R
表S
値１
値２
値n
ストレージモデル
（３． リング型記憶 （RS)）
表S S.a
表Sの属性aへのインデクス
（キー属性以外）
ポインタ
ドメイン表
値１
値2
値n
ストレージモデル
（３． リング型記憶）
表Rから表Sへのジョイン用インデクス
表S
表R
R.a （Rのキー属性）
（Rの中にある）
S.b（外部キー）
複合問い合わせの処理 （例）
Q1: ９９年に抗生物質を投与した医者は誰か？
Join
doc
Select.
Right-Deep木で
パイプライン実行。
visit
（RAM使用量０．
EEPROMへのwrite 0)
Join
Join
Select
presc
drug
７のまとめ
• スマートカード内蔵のDBMS
 新しいビジョン
• Bull smartcard project (OverSoft. – iSimplify).
Virtual Campus platform (U.Versailles).
• 課題：
保護つぎロギング、
暗号化データ上の問い合わせ処理
8.
Oracle8i のインデクス編成表IOTと
新ドメインへの適用 （オラクル）
新しい応用ドメイン （Web, DWH, OLAP, etc)

不定長レコードのインデクス、および、
多属性上の２次インデクスの多用,
オンライン再編成の多用。
従来よりも効果的なインデクスは？
オラクルの従来のインデクス
例： 表[name, age]。nameがキー属性とする場合、
1. インデクス領域
[主キー, RID]上のB木
と
2. ヒープ領域
タプルレコード集合を格納するヒープ領域
の組で関係表を実装。（RIDとは、レコードの物理
的な位置を表すID。）
オラクルの従来のインデクス
主キー
インデクス
領域
RowIDは
物理的な
レコードID
従来方式
DBMS1 RowID1
DBMS2 RowID2
Oracle1 RowID3
Oracle2 RowID4
[主キー, RID]
上のB木
ヒープ領域
DBMS1
DBMS2
例： 表[name, age]。 Oracle1
nameがキー。 Oracle2
17
2
14
31
タプルレコード
集合を格納する
ヒープ領域
IOT とは？
• IOT (Index-Organized Table)とは？
関係表 R[A, B, C, …] （Aがキー属性）に対し、
主インデクス（属性A上のB木）ファイルの葉ノード
に関係表のレコード(A, B, C, ..)を直接格納した
もの。表Rの実装をこのファイル編成のみで与える。

IOTの利点
• ヒープ領域へのアクセスが不要。
• インデクスのscanだけで複数属性上の集計
処理ができる。
IOT の技術的課題
• IOT (Index-Organized Table)＝
関係表 R[A, B, C, …] （Aがキー属性）に対し
主インデクス（属性A上のB木）ファイルの葉ノード
に関係表のレコード(A, B, C, ..)を直接格納したも
の。

技術的な課題
1. 不定長レコードをどう扱うか
2. ２次インデクスを通した元レコードへのアクセ
ス処理の高速化
IOT： インデクス編成型テーブル
インデクスのみで
関係表を実装。
B+木
インデクスの葉
ノードにレコードを DBMS1
直接格納する。 DBMS2
今までよりも
速い！
Oracle1
Oracle2
17
2
14
31
ヒープ領域はなし
キー属性
name上の
B +木
IOT： インデクス編成型テーブル
不定長データ、
2次インデクス、
再編成は？
インデクスのみで
関係表を実装。
B+木
インデクスの葉
ノードにレコードを DBMS1
直接格納する。 DBMS2
今までよりも
速い！
Oracle1
Oracle2
17
2
14
31
ヒープ領域はなし
キー属性
name上の
B +木
IOT： 溢れがある場合
関係表のスキーマ= [name, age, att3, att4, …, att n]
1.
[name, age]と残りの属性[att3, att4, …, att n]
に関係表を垂直分割して、後者をヒープ
領域に置く。
2. キー属性 name上のB＋木を作る。ただし、
葉ノードに [name, age, 残りの属性へのrid]を
格納する。
IOTの例 （溢れがある場合）
キー属性name上のB木で
作ったIOT。葉ノードに
[name, age, 他へのRid]を
格納。
主インデクス
DBMS1
DBMS2
Oracle1
Oracle2
17
2
14
31
Rowid1
Rowid2
Rowid3
Rowid4
キー圧縮が効く。
ヒープ領域
Xxxxx
Yyyyyy777
Zzzzzzzzzz
Wwwwww
関係表のスキーマ= [name, age, att3, att4, …, att n]
IOTにおける２次インデクス
関係表 [name, age, attX] (nameがキー属性）の場合、
主インデクスと２次インデクスをIOTで作るには：
IOT1 (name上の主インデクス）=
キー属性nameについてB+木を作り、
その葉ノードに関係表のレコードを格納.
IOT2 (age上の２次インデクス）=
属性ageについてB+木を作り、葉ノードに
[ age, 当該レコードのキーの値、Guess-DBA]を
格納.
とする。
IOTにおける２次インデクス （続）
主インデクス。
葉ノードにデー
タを置く。
DBMS1
DBMS2
Oracle1
Oracle2
17
2
14
31
２次インデクス
(属性age上のindex)
論理ID
として使う。
T1.key1, age1
T2.key2, age2
T3.key3, age3
T4.key4, age4
Guess-DBA1
Guess-DBA2
Guess-DBA3
Guess-DBA4
Guess-DBA: 主インデクス中で当該レコードを格納する
葉ノードの物理ID。
IOTの特徴 （略）
• 2次インデクスによる元レコードの検索方法
-- 2次インデクスによりGuess-DBAを求め、そ
れにより元レコードを検索。この検索が失敗した
ら、論理キーを使って主インデクスを検索。
• Guess-DBAの更新は行わない。モニタがGuessDBAの的中率を監視し、一定値を下回ったらオ
ンラインで２次インデクスを再編成。
• 主インデクス再編成が簡単でオンラインにより実
行可能。（２次IXと独立にできる。）
• インデクスのscanだけで集計ができる。
• 溢れ域に出すコラムを指定できる。
他方式との違い （略）
• Non-Stop SQLのキー順編成ファイル
-- レコードの大きさが制約される。
-- ２次インデクスが論理レコードIDのみ
を格納するため、検索のI/Oが多い。
• Microsoft SQLserver7.0のインデクスの１
つ （Merged Index.  ICDE99)
-- レコードを主キーの中に置ける。任意長
のレコードがだめ。２次インデクスが物理
レコードidを使う。
IOTを適用したい分野
• 電子商取引の発注処理
• サーチエンジンの逆引きインデクス
• ポータルサイトにおけるユーザのアクセス
履歴
• データウェアハウスのOLAP。 -- Oracleの
サマリ表と実体化ビューはIOTで実装中。
ex. --(場所id, 商品id, 売上）表をIOTにする
と index scanのみで速い。
＊他 – 時系列データ。
6.データマイニング（DM)とRDBの統合
（Microsoft, S.Chaundhuri)
問題：
• DMモデルをRDBでどう表現するか。
• DMの操作をどんな言語で書くか。
• DMとRDBの間のデータ操作をどう書くか。
（DMモデル：
決定木、回帰モデル、セグメンテーション）
• 方針： OLE-DBをRDBサーバが提供する。
DM処理系はOLE-DB APIの上に作る。
5. SQLserver2000における実体化
ビューとインデクスの自動選択方式
• 問題： ワークロード（選択、更新）の下で、
実体化ビューとインデクスの選択を
1つの枠組みで自動設定したい。
• 課題： DWH管理負荷の削減
• 提案： インデクスもビューの1つ。
 ビューのマージを使う。
ビューマージの方法
• V1: select a, sum(b) from R where p1(x)
and p3(z) group by a.
• V2: select a, c, sum(d) from R where p2(y)
and p3(z) group by a, c.
V1とV2をマージすると：
• V12: select a, c, x,y, sum(b), sum(d)
from R where p3(z) group by a, c, x, y.
その他のエンジン系の発表


High Performance and Scalability thru App.-tier InMemory Data Mgt. (TimesTen)
Cheetah: a light weight trans server for plug-and-play
internet data management
--
Global transaction idの発行を分散WWWノードで独自
に行い、分散TX処理環境でWWWノー ドのPlug&Playを実
現する話。
• Offering a precision-performance tradeoff for
aggregation queries over replicated data. (Stanford
U.)
-- レプリカのキャッシュの話。x=5をx=[4,7]とい
う誤差を入れてキャッシュする。OLAPの即時更新用。
新しいインデクスの発表
• Local dimensional reduction (イリノイ大.
S4)
空間内の局所的な粗クラスタごとに主成分軸を求め、
ReconDist() < thetaの条件で正確なクラスタへ分割。
Y
ReconDist(Q,S)
第２
主成分 Cs
Q
クラスタS
第１
主成分軸
Ｘ
• What is the NN in high-dimensional space?
(A.Hinneburg, C.Aggarwal,D.Keim) – 高次空間の最近
傍検索は無意味。意味のある射影空間を問い合わせ点
ごとに決めて、そこでNN探索をする。3-4次までgreedy, そ
の後をGAにより、Qに応じた射影空間を決めてNN点を
求める。(S16)
• Novel Approaches to the Indexing of Moving
Objects trajectories. （ECの時空間DB. S13）
• Managing intervals efficiently in O-R DB.
(H.P.Kriegel, S13) RDB上のInterval木の変形。
• Integrating UB-tree into a DB system kernel.
(R.Bayer他) -- 多次元データをZ-orderでB木に変換し
てTransBaseというDB製品に組み込んだ話。
• Decision Tables: Scalable Classification exploring
RDBMS Capability (H.Lu,NUS)
-- 分類木をSQLだけでつくる話。
パネル4: Future direction of DB research
• VLDB98から01のchairによるVLDBの
方針の解説。
2001 chair: S.Ceri (Politec.di Mirano)
-- 来年の論文募集は DB コア技術、ISイン
フラのためのDB技術、の２つに分ける。
-- SPF (Specificity Factor)でPCメンバが1か
ら9で評価し、 ISインフラ向けDBを重視。
まとめ：VLDBの感想
• VLDB = Echo, sometimes close to Source.
• DBと無関係なIT応用分野の強さ
= XML, Web analysis, E-commerce
middleware, ERP, DWH.
• DB engine vendor の積極性が目立つ。
DBエンジンのライブラリ化による新IT
middlewareへのDB coreの浸透の波。
まとめ （続）
• ディスク、ストレージサーバ、ネットワーク、
テープアーカイバの話がない。
• セキュリティの話がない。
• メタデータ、LDAPの話が出てきた。
• BioInformatics は？ -- 多数の聴衆を得ず。
 VLDB2000のEcho
= DBソフトウェアの流れを映す。
論文集のアクセス
• VLDB2000の概要、プログラム
-- www.vldb.org(VLDBの公式サイト）
• 論文の概要
-- www.informatik.uni-trier.de/ley/db
(DBLP)からPDFのロード可能。(vldb側から
はfree access).
-- 論文集： Proc.26th Int.Conf.VLDB2000.
Morgan Kaufmann Pub.
-- メモ、ppt  www.sigmodj.is.uec.ac.jp
(SigmodJ)
完
• 注意書き
この資料は12月8日に行われたDBWeb2000(ACM
SIGMOD 日本支部第16回大会)において行われた発表
において使用されたものに加筆･修正を加えたものです。
DBWeb2000については www.sigmodj.is.uec.ac.jpをご覧
ください。
Copyright ： 大森 匡