2003年 7月16日 論理 I/O 回数の試算 >> 目次 (作成日順)


 
 前回述べたが (228 ページ 参照)、「INDEX-only」 を使う際には、更新 (追加、削除、変更) を前提にして、1つの テーブル に対して生成する 「CREATE INDEX」 の数を制限している。
 というのは、更新 (追加、削除、変更) を前提にすれば、「CREATE INDEX」 の多用は パフォーマンス を逆に低下することになるから。

 更新 (追加、削除、変更) を前提にして、「驚異的な」 パフォーマンス を実現するための 「CREATE INDEX」 の限界数が前回述べた制限数である。その制限数の枠内であれば、テーブル に対して更新が多くても、(「INDEX-only」 を使った) 「驚異的な」 パフォーマンス を実現することができる。

 データ 1件に対する I/O 回数は以下の計算式を参考にされたい。



I/O 回数
READ 2
UPDATE ADD 1 + N
CHANGE 3 (+ N)
DELETE 2 + N


 
 N は 「CREATE INDEX」 の数である。

 上述の I/O 回数の内訳に関する詳細な説明は割愛するが、たとえば、5つの 「CREATE INDEX」 が定義されている データ を ADD すれば 6 回の論理 I/O が起こるし、DELETE すれば、7 回の論理 I/O が起こるということを理解すればよい。ここで注目したい点は、更新 (UPDATE) では、ADD の論理 I/O 回数が一番に少ない、という点である。

 つまり、論理 I/O を削減するには、(CHANGE と DELETE を使わないで) ADD を使えばよい、ということである。
 したがって、RDB を使って正規形を実装したなら、以下の 2つの やりかた を使えばよい。
  (1) 「INDEX-only
  (2) 「ADD-only

 ちなみに、プログラム が出した更新の論理 I/O 回数を、RDB のなかでは、少ない物理 I/O 回数 (EXCP) にするために 「パイプライン 機能 (pipeline)」 が搭載されていることがある。たとえば、100 回の論理 I/O 回数をまとめて 1 回の物理 I/O 回数にする機能である。ただし、パイプライン 機能は READ に対しては適用されない。

 次回は、パイプライン 機能について説明する。




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