2003年 2月 1日 CBS と order-by >> 目次 (作成日順)


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

 
 セット・アット・ア・タイム 法では、複合選択条件は 「同一 row の検証」 をするために トラヴァーサル・テーブル を生成することを、前回、述べた。複合選択条件のことを専門用語では 「CBS (Compound Boolean Selection)」 という。

 
1. order-by と トラヴァーサル・テーブル

 単一選択条件 (連言や選言を使わない 1つの条件文) はどうかと言えば、単一選択条件であっても、トラヴァーサル・テーブル を生成することがある。以下の例を使って説明する。

 

「従業員」 テーブル
従業員番号 従業員名称 従業員住所
001 佐藤正美 A
002 稲森いずみ B
003 佐藤恵美子 A
004 佐藤 敦 C


 
 従業員の データ は従業員番号順に並べられている。
 さて、これらの データ を名称順に並べて一覧表示する (「従業員名称→従業員番号→住所」 の順に並べる)。

 物理的な配列 (native-sequence) は従業員番号順に並んでいるので、並び直さなければならない。
 そのときに使う SQL 句が 「order-by」 である (「group-by」もこれに準ずる)。

 並び直すためには作業域 (work-area) を用意しなければならない。
 すなわち、sort-work 域と sort-out 域を用意しなければならない。
 そのために、RDB は (作業域として) トラヴァーサル・テーブル を生成する。

 つまり、「order-by」 を使えば、トラヴァーサル・テーブル が生成される。
 となれば、資源を費消して パフォーマンス は低下する。

 したがって、「order-by」 を使わないで並び直すことを考えなければならない。

 
2. まとめ

 以上に述べてきた点をまとめれば、以下のようになる。

 (1) セット・アット・ア・タイム 法は 「MAX-Start I/O」 を制限できない。
   つまり、セット・アット・ア・タイム 法は テーブル の全体を走査する。

 (2) 「order-by」 を使えば、(sort 域を用意するために) トラヴァーサル・テーブル を生成する。

 (3) 複合選択条件を使えば、(「同一 row 上の検証」 をするために) トラヴァーサル・テーブル を生成する。

 
 基幹系の多量 データ・多量 トランザクション を対象として、RDB の高 パフォーマンス を実現するためには、以上の諸点を回避しなければならない。
 RDB は、バージョンアップ の過程のなかで、(セット・アット・ア・タイム 法の上述した弱点を回避するために) レコード・アット・ア・タイム 法 (indexing を使って row 単位に データ を アクセス する やりかた) を導入してきた。しかし、導入された レコード・アット・ア・タイム 法は 「B ツリー 構造 (Balance-Tree 構造)」 を基礎とした I-SAM (あるいは、VSAM) 式であった。「B ツリー 構造」 を使った レコード・アット・ア・タイム 法は、基幹系の多量 データ・多量 トランザクション を対象としたら、かならずしも、高 パフォーマンス を実現することができない。

 次回は、レコード・アット・ア・タイム 法を説明する。

 

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