 |
|
| 徹底比較!! PostgreSQL vs MySQL |
第２回：データ構造の比較
著者：NTTデータ 藤塚 勤也 2006/4/18
|
|
|
| 前のページ 1 2 3 4 次のページ
|
|
| データ量が増えた場合の変化
|
PostgreSQLのテーブルとMySQL＋MyISAMエンジンのテーブルは、テーブル単位にファイルが存在し、そのファイル内にそれぞれのレコードデータを格納する構成です。よって、テーブル内のレコード件数が増加すると、そのテーブル用のファイルサイズが大きくなります。
またテーブルにインデックスが存在する場合、レコード件数の増加にあわせて、当然インデックの容量も増加します。PostgreSQLの場合はインデックスごとにファイルが分かれているため、それぞれのファイルサイズが増加します。MySQL＋MyISAMエンジンの場合は、「テーブル名.MYI」のファイルサイズのみが増加することになります。
これとは対照的にMySQL＋InnoDBエンジンのテーブルは、複数テーブルのレコードデータ並びにインデックスデータをまとめて、テーブルスペースと呼ぶデータファイル内に格納する構成です。
よってテーブル内のレコード件数が増加すると、テーブルスペース用のデータファイルの容量が増加します。ただし、テーブルスペース用のデータファイルは、レコード件数が増加するたびにファイルサイズが徐々に大きくなる仕組みではなく、設定した一定サイズのファイルを作成しておき、容量が不足した時にはじめてファイルサイズを大きくする仕組みになっています。
このように、データベースを作成する場合においてPostgreSQLとMySQLでは、ディスク上に構築するディレクトリやファイル構成がまったく異なります。さらにMySQLでは、作成するテーブルタイプの選択によってもファイル構成が異なるのです。
| |
PostgreSQL |
MySQL |
| MyISAM |
InooDB |
| データベース |
ディレクトリ |
| テーブル |
テーブル単位のファイル |
テーブルスペースファイル内 |
| インデックス
| インデックス単位のファイル
| 単一のインデックスファイル |
表3：ファイル構成
|
| PostgreSQLテーブルの特徴
|
PostgreSQLのテーブルの構造は、追記型と呼ばれる構造になっています。追記型とは、レコードの更新が発生した場合に更新対象のレコードデータを直接書き換えるのではなく、更新後の新たなレコードを次から次へと追加していく構造です。次に追記型における振舞いを、レコードを更新するSQL文と照らし合わせます。
- INSERT文
- テーブルファイルの空き領域に新たなレコードを追加します。
- UPDATE文
- UPDATE対象のレコードを更新せず、テーブルファイルの空き領域に更新後の新たなレコードを追加します。古いレコードには、削除印を付けることによってこのレコードが無効であることを記録します。
- DELETE文
- DELETE対象のレコードを削除せず、UPDATE文での古いレコードに対する処理と同様に、削除印を付けることによってこのレコードが無効であることを記録します。
表4：追記型におけるレコードの更新
このように、1度追加されたレコードデータは、削除されたり上書きされたりすることがありません。UPDATE文を実行した場合はテーブル内に存在するレコード件数は増加し、DELETE文を実行してもテーブル内に存在するレコード件数が減少することはありません。もちろんここでのレコード件数とは、削除印が付いた無効レコードを含めた件数のことです。
追記型の最大の欠点は、データ更新処理を行うアプリケーションを動作し続けると、無効レコードの件数が増加するため、時間の経過と共にテーブルやインデックス用のファイルサイズが肥大化することです。
ファイルサイズが肥大化すると、より多くのディスク容量が必要になるだけではなく、ディスクからの読み込みにより多くの時間を必要とするため性能を劣化させる原因にもなります。よってこの状況を回避するために、無効レコードが存在しているデータ領域を再利用もしくは、物理的に削除するためのVACUUMと呼ぶ処理を行う必要があります。
ただし、動作するアプリケーションによってファイルの肥大化速度は異なるため、どのような周期にてVACUUMを動作させるかは難しい問題です。
しかし追記型は、MVCC（Multiversion Concurrency Control）と呼ぶ機能を実現するために非常に重要な役割を果たしています。MVCCとは、データベースに対して検索要求トランザクションを実行した際、他トランザクションからの干渉を受けることなく、一貫性を保ったデータを読み込める機能で、Oracleでは読み取り一貫性と呼んでいます。
|
前のページ 1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
株式会社NTTデータ 藤塚 勤也
基盤システム事業本部 オープンソース開発センタ シニアスペシャリスト。
日本タンデムコンピューターズ（現日本HP）を経て、2003年よりNTTデータにてOSS分野に参画。日頃はオリジナルOSSの開発や、OSSを用いたシステム構築への技術支援に従事。「RDBMS解剖学」（翔泳社）を共著。
|
|
|
|
|
|
