2003年 1月16日 トラヴァーサル・テーブル >> 目次 (作成日順)


 
 今回は、セット・アット・ア・タイム 法の実装形 (プロダクト としての RDB) の 「からくり」 を解析にする。

 
 RDB (Relational Data Base) は以下の 2点を特徴としている。

 (1) データ 構造は 「テーブル」 構造である。
 (2) データ に対する アクセス は (view を使った) 「column 単位」 の アクセス である。

 テーブル 構造 (縦列と横列から構成される 2次元の flat-file) において、横列のことを 「row」 といい、縦列のことを 「column」 という。

[ 注意 ]
 セット・アット・ア・タイム 法を基本の アクセス・メソッド としている RDB では、「キー (indexing)」 は internals (内的構造) と無関係である。
 つまり、(RDB は、バージョンアップ のなかで 「CREATE INDEX」 を附加してきたが) 「CREATE INDEX」 は テーブル 構造に対して 「上積み」 された アクセス・メソッド なのであって、セット・アット・ア・タイム 法とは関係のない論点である。
 この点については──indexing については──、後日、記述する。

 以下の テーブル を前提とする。



「服」 テーブル
ROWID サイズ
001 S
002 M
003 M
004 L

 
 以下の SQL を実行する。

 SELECT count (...) FROM "服"
 WHERE サイズ = "M" OR 色 = "黒".

 
1. トラヴァーサル・テーブル

 セット・アット・ア・タイム は、セット を単位として、「カラム (column、縦列) 単位」 に アクセス するので、上述の SQL を実行すれば、以下のような アクセス 経路を辿る。

 (1) サイズ の カラム を走査 (scan) して、値が 「M」 である ROWID (002 と 003の 2つ) を得る。
 (2) さらに、色の カラム を走査して、値が 「黒」 である ROWID (003) を得る。

 複数の選択条件を──ここでは選言 (OR) であるが──、それぞれ単独に、カラム を走査すれば、検索結果として 3件の データ を得ることになるが、以下の 2つは同じ データ である。

 (1) サイズ の カラム を走査して得た ROWID = 003
 (2) 色の カラム を走査して得た ROWID = 003

 セット・アット・ア・タイム 法は カラム 単位の アクセス を原則にしているので、複数の選択条件 (AND/OR) が記述されたなら、同一 ROW であるかどうかの検証をしなければならない。
 同一 ROW の検証をするために、RDB は、一時的な作業域 (work-file) を用意する (生成する)。この作業域のことを 「トラヴァーサル・テーブル (traversal-table)」 という。

 RDB は、(複合選択条件に対して) カラム を走査しながら検索結果を トラヴァーサル・テーブル に書き込んで、すべての検索が終わってから、トラヴァーサル・テーブル のなかに書き込まれた データ に対して同一 ROW の検証をする。
 したがって、(トラヴァーサル・テーブル を生成して、同一 ROW の検証をすれば、) 資源が費消され、パフォーマンス は低下する。

 言い換えれば、多量 データ を対象にして、「CREATE VIEW」 を使って複合検索を実行すれば パフォーマンス が悪いので、なんらかの対応をしなければならないということである (──対応策については、後日、記述する)。

 

警告!
多量 データ と多量 トランザクション を対象にしているのなら、
「CREATE VIEW」 を使わないほうがよい。

 
[ 注意 ]
 対象の データ が少量なら、「CREATE VIEW」 を使って、メモリー のなかで走査しても問題はない。
 ここで論点にしているのは、いわゆる 「基幹系」 と呼ばれている システム のなかで扱われている多量 データ (数百万件、数千万件) と多量 トランザクション である。
 数百万件の データ を join して──あるいは、複数の 「曖昧検索」 を使って──、「瞬きの」 レスポンス を実現することを目的にしている。



2. 実行 プラン (execution-plan)

 SQL を 「最適に」 実行するために、RDB には、SQL を解析して 「最適な」 実行経路を判断する機能が搭載されている。その機能のことを 「オプティマイザ (optimizer)」 という。
 オプティマイザ は、以下のいずれかを基準にして、SQL の 「最短の アクセス 経路」 を判断する。

 (1) (最小の) I/O 回数
 (2) (最小の) CPU 量

 I/O 回数を判断基準にするやりかたを 「ルール・ベース」 といい、CPU 量を判断基準にするやりかたを 「コスト・ベース」 という。市販されている RDB は 「コスト・ベース」 を標準値 (default) にしている。

 SQL を実行したなら、かならず、実行 プラン を調べてほしい
 なぜなら、(多量 データ と多量 トランザクション を前提とするなら) 実行 プラン のなかで以下の メッセージ が記述されていたらまずい (!)

  悪い例: TABLE SCAN ×××(数値)

 つまり、(多量 データ と多量 トランザクション を前提とするなら) 「TABLE SCAN」 は、資源を費消して、パフォーマンス が悪い、ということである。対応策については、後日、記述する。

警告!
かならず、実行 プラン を検証せよ。
以下の メッセージ が出たら、まずい (!)

TABLE SCAN ×××


 
[ 注意 ]
 対象の データ が少量なら、「CREATE VIEW」 を使って、メモリー のなかで走査しても問題はない。
 ここで論点にしているのは、いわゆる 「基幹系」 と呼ばれている システム のなかで扱われている多量 データ (数百万件、数千万件) と多量 トランザクション である。
 数百万件の データ を join して--あるいは、複数の 「曖昧検索」 を使って--、「瞬きの」 レスポンス を実現することを目的にしている。

 
 次回は、複合検索条件を、もう少し詳細に解析してみる。
 (「create view」 以外にも、「order-by」 を使わないほうがよい、という点を検証してみる。)

 

  << もどる HOME すすむ >>
  ベーシックス