［データベース設計編］レコード長×件数でデータ容量を決めてはいけない

　データベース設計の一つに，ディスク容量の見積もりがある。概算として，そのデータベースに格納する「テーブルのレコード長×件数」で見積もることがあるだろう。だが，こうして求めた値の容量を確保していると，後々ディスク容量不足になることが多いので注意が必要だ。

　その原因として，大きく二つの理由がある。一つは「論理レコード長」と「物理レコード長」の違い，もう一つは「ブロック」の考え方が入っていない点である。論理レコード長とは，簡単に説明すればディスクへの格納形式を考慮しないレコード長，物理レコード長とはディスクへの格納形式に基づいたレコード長である。ブロックとは，RDBMSがディスク入出力を行う際のデータ単位である。

物理サイズはRDBMSに依存

　レコード長は，テーブルを構成するカラム・サイズの合計で考えるのが基本である。カラムの定義は，例えば「カラム01 char(10)」（10バイトの文字列）や「カラム02 decimal(10,2)」（小数点部分が2ケタの固定小数点型）のように行う。論理レコード長だと，前者は10バイト，後者は（10ケタの数値なので文字列のように）10バイトと考える人がいるかもしれない。

　物理レコード長は，RDBMSによって異なるので注意が必要だ。「char(10)」カラムの場合は，ほとんどのRDBMSでディスク上の格納サイズは10バイトだと思われる。一方で「decimal(10,2)」カラムは，数値部分をバイナリ形式の4バイトで格納し，小数点位置を2バイトで示すような格納方法だと，物理サイズは6バイトとなる。違う格納方法としては，小数点も含め全体を文字列として格納していれば11バイトとなる。いずれにしても，論理的に10バイトと考えていたとしたら，異なるサイズになる。

　次に，ブロックの考え方とは何であろうか。レコードをディスクに格納する場合，RDBMSは「ブロック」と呼ぶ固定サイズの入れ物の中にレコードを格納する（図1）。ブロック・サイズはRDBMSによって異なるが，サイズの変更は可能である。基本的には，1レコードは複数ブロックにまたがないように格納される。

図1●ブロック単位でディスクに格納される

　ここで，物理レコード長が1500バイト，ブロック・サイズが4Kバイトの場合を考えてみよう。このケースだと，1ブロックの中に2レコードしか格納できない（1ブロックごとに1Kバイトの空きが生じることになる）。テーブルのレコード数が100件の場合，ブロックを考慮しないと必要なディスク容量は150Kバイト（＝1500×100）と計算するだろう。だが実際は，「ブロック・サイズ×レコード件数／1ブロックに収まるレコード件数」，すなわち200Kバイト（＝4K×100／2）のディスクが必要である。

　なお，今回説明したのはユーザー・テーブルのデータを格納するディスクについてのみである。このほか，インデックス用のディスクやトランザクション・ログ用のディスク，さらにはテンポラリ・データ用のディスクなどが必要になる。データベース全体のディスク容量を見積もる際にはこれらも考慮に入れるべきである。