2003年 4月16日 クラスタ・キー >> 目次 (作成日順)


 
 クラスター 法 [ クラスタリング (clustering)] には、以下の 2つがある。

 (1) 分離格納式 (複数 テーブル を 1つの物理 データセット のなかに co-locate するやりかた)
 (2) JOIN 式 (複数の テーブル を 1つの物理 データセット として merge するやりかた)

 分離格納式は、複数の論理 ファイル を 1つの物理 データセット 内に分離格納する やりかた であり、JOIN 式は、複数の論理 ファイル を join して 1つの物理 データセット を生成する やりかた である。

 分離格納式は、大型汎用機系の データベース に搭載され (たとえば、DB2/MVS や DATACOM/DB など)、JOIN 式は、オープン 系の データベース に搭載されている (たとえば、ORACLE)。

 
1. 分離格納式

[ 前提 ]

(1) 従業員番号 (EMP-NO、5桁) は部門 コード (2桁) と連番 (3桁) 構成されている。
  [ こういう コード 化は 「適切ではない」 のだが、説明を簡単にするために使う。]

(2) 1つの物理 データセット のなかに 2つの テーブル が格納されている。
  それぞれの テーブル 名称は HNB (社長室用 テーブル) と DSSJ (データベース 営業部用 テーブル) である。

(3) 従業員番号が ネイティブ・キー および マスター・キー として定義されている。

(4) 1つの データ・ブロック には 3つの レコード を格納することができる。
  それぞれの ブロック には 「空き エリア (slack-area)」 が用意されている。

 さて、以上の前提にして、社長室に新たな データ (従業員番号 「01005」) を追加する (以下の図を参照されたい)。

 分離格納式は、最初に、追加される データ の キー 値 (ネイティブ・キー および マスター・キー) がすでに存在していないかどうかを検証して、同一の キー が存在していないなら、次に、既存の データ を納めている ブロック のなかに 「空き エリア」 があるかどうかを検証する。

 「空き エリア」 があれば当該 ブロック のなかに新規の データ を追加するし、「空き エリア」 がなければ、他の ブロック のなかに格納する。

 分離格納式を使う理由は、それぞれの テーブル のなかに納められている データ の シーケンス (native-sequence) を保証しながら、かつ、複数の テーブル 間の データ の シーケンス を実現するためにある。
 たとえば、独立採算制を導入している部門組織が、それぞれの部門の従業員 ファイル の シーケンス を前提にしながら、全社の従業員 ファイル の シーケンス を実現するようなときに使う。

 ただし、「複数 FILE = 1 AREA」 式は、「ディスク・スキップ の負荷」 および 「障害修復の迅速性」 という難点がある。



テーブル 名称 EMP-NO EMP-NM cluster-key
HNB 01 001 佐藤正美 001
01 002 佐藤恵美子 001
slack-area
DSJ 02 003 佐藤 敦 001
02 004 佐藤 剛 001
slack-area


HNB に納められる 01 005 佐藤大地 001


 
2. JOIN 式

[ 前提 ]

(1) 部門 テーブル と従業員 テーブル が存在する。

(2) それぞれの テーブル は、更新 (UPDATE) が少ないが照会 (READ) が多い。



unclustered
従業員 テーブル 部門 テーブル
EMP-NO DEP-CD DEP-CD DEP-NM
100 02 01 A
102 01 02 B
103 02    
104 02    
105 01    


clustered
部門. 従業員
DEP-CD DEP-NM EMP-NO
01 A 102
    105
02 B 100
    103
    104


 
 対 (a pair) で照会することが多い テーブル を照会のたびに join すれば パフォーマンス が悪くなるので──そういうふうに 「誤解」 されているが、実は、10,000,000件やそれ以上の データ に対して 「%値%」 (挟み込み ワイルドカード 検索) を 5つ以上使って join しても 「驚異的な (瞬きの)」 パフォーマンス を実現できるのだが、ここでは、世間一般の誤解を前提にして綴っていることを了承されたい──、JOIN 式は、join 対象となる テーブル を 1つの物理 データセット として マージ (merge) しておく やりかた である。
 JOIN 式には以下の利点がある。

 (1) I/O を削減できるので、照会に対して高 パフォーマンス を実現できる。
 (2) ストーレッジ を節約できる。
   なぜなら、クラスター・キー を 1回だけしか格納しないから (図のなかの部門 コード を参照されたい)。

 しかしながら、更新が多ければ、マージ された テーブル が物理的に再編成されるので、パフォーマンス が悪くなる。
 したがって、JOIN 式は、更新が少なくて照会が多い テーブル に使用するとされている。

[ 参考 ]
 JOIN 式では、マスター・キー を クラスター・キー として使うことはできない。というのは、JOIN 式の クラスター・キー は同一値が多数にある カラム を クラスター・キー として定義して テーブル を join し、クラスター・キー が 1回だけしか格納されないようにする やりかた なので、一意性を保証する マスター・キー を クラスター・キー として使うことはできない。
 また、referential integrity を検証している テーブル に対して JOIN 式の クラスター 法を使うことができない。なぜなら、referential integrity が保証されている テーブル を物理的に 1つの テーブル として生成したら、referential integrity を破ることになるから。

 
3. まとめ

(1) 分離格納式
 1つの物理 データセット のなかに複数の論理 テーブル を格納して、それぞれの論理 テーブル の データ の シーケンス を前提しながら、かつ、全体 (物理 データセット のなかに納められている データ) の シーケンス を実現する。
 ただし、「ディスク・スキップ の負荷」 という難点がある。

(2) JOIN 式
 複数の論理 テーブル を 1つの物理 データセット として マージ して join 操作の I/O を削減し、照会の高 パフォーマンス を実現する。
 ただし、「更新の物理的再編成」 という難点がある。

 さて、いずれにしても、クラスタリング は使わないほうが良い。
 データ の 「シーケンス の保証」 および 「join の驚異的な パフォーマンス」 は、ほかの単純な やりかた を使えば実現できる
(後日、述べる)。



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