TOP>企業情報>コラム>技術情報>アクセス・パスから見るRDBMSの違い

アクセス・パスから見るRDBMSの違い


商用RDBMSのデファクト・スタンダードである「Oracle Database」、オープンソースRDBMSの両雄である「PostgreSQL」、「MySQL」には、それぞれのRDBMSの個性を活かせる適用領域があります。本稿では、RDBMSの「性能要件」に深く関係する「アクセス・パス」を題材に、「Oracle Database」、「PostgreSQL」、「MySQL」の特長を整理し、適材適所で活用するヒントを探ります。

アシストでは1987年に取り扱いを開始した「Oracle Database」に加え、2009年10月より「PostgreSQL(ポストグレスキューエル)」、2011年10月にはPostgreSQLをベースとしOracle Databaseとの互換性機能を有する「Postgres Plus(ポストグレスプラス)」、Webサービスのシステムにて採用されているRDBMSとしてはデファクト・スタンダードになりつつあるコミュニティ版の「MySQL(マイエスキューエル)」と、そのブランチである「MariaDB(マリアディービー)」のサポートを同年12月から開始しています。また、DWH専用に設計されたDBMSソフトウェアとして、2012年3月よりCalpont社の「InfiniDB(インフィニディービー)」の取り扱いを開始しました。

RDBMS領域で、商用RDBMSのデファクト・スタンダードである「Oracle Database」、オープンソースRDBMSの両雄である「PostgreSQL」、「MySQL」のサポート・サービスを開始したことで、それぞれの適用領域に関するご相談をいただくようになりました。RDBMSを採用する要因は、機能要件、非機能要件以外に、開発要員や運用人員のスキルの有無、移行コスト、開発コスト、同じ業界やシステムでの採用事例の有無、社内標準RDBMSであるかどうかなど、多種多様な選定ポイントがあります。

本稿では、「性能要件」に深く関係する「アクセス・パス」の観点から、「Oracle Database」、「PostgreSQL」、「MySQL」の特長を整理します。

アクセス・パス


「アクセス・パス」とはデータベースからデータを取り出す「経路」のことです。RDBMSでは、アプリケーションから発行されたSQLを「解析」して「実行」しており、「解析」では、SQLの構文チェック、参照されているオブジェクトの存在チェックが行われた後、データにアクセスするための経路であるアクセス・パスが決定されます。例えば、友人との待ち合わせ場所まで、どの経路を使って、どんな交通手段で移動するのが一番効率的かを考えるのと似ています。

代表的なアクセス・パスには、表の行データを1行、1行読み取って、条件に合うデータを取り出す「全表スキャン」と、本の巻末の索引と同じく、表の各列のデータとそのデータの格納位置を示すアドレス情報を持つ「索引」を利用した「索引スキャン」があります。このアクセス・パスは各RDBMSで実装されている種類ごとに異なり、また、各RDBMSのデータを保持する物理構造の違いと相まって、適用領域を考える際のポイントとなります。

全表スキャン


「全表スキャン」は表のすべての行が順に読み取られ、選択基準を満たす行が取り出される表データのスキャンです。シンプルな処理であるため、表データを格納する物理構造により特長が生まれます。

図1 全表スキャンの比較
(クリックで拡大します)

図1のように、Oracle Databaseと、PostgreSQLは、データ格納の最小単位であるデータ・ブロック(ページ)の構造、およびデータ・ブロックの連続した塊で表データが構成される構造が類似していますが、ブロックを読み取る方式が異なります。PostgreSQLはシングル・ブロック読み込みのため1回の読み込み命令で1つのデータ・ブロックにアクセスしますが、OracleDatabaseではマルチ・ブロック読み込みと呼ばれる、複数のデータ・ブロックを一回の読み込みで処理することで、全表スキャンでの読み込み回数を軽減する機能が実装されています。一方、MySQLのデフォルト・ストレージエンジンである「Innodb」では、表データはクラスタ・インデックス構造として格納されています。図1のようにクラスタ・インデックス構造では、表の主キー(主キーが存在しなければ、行を一意に識別する内部行ID)によって、いわゆるB-Tree構造のリーフ・ブロックに相当するデータ・ブロックに、主キーと行データが格納されています。全表スキャンでは、B-Tree構造のルート・ブロック、ブランチ・ブロックからリーフ・ブロックに存在する行データを読み込む方式となります。

このように、どのRDBMSでもアクセス・パスとして全表スキャンは実装されていますが、物理構造とデータ・ブロックの読み取り方式に違いがあるため、特に大規模な表を全表スキャンする場合、Oracle Databaseに優位性があると考えられます。

一意索引スキャン


索引には主キーや一意キーに作成される列値の一意性を保証する一意索引と、一意性を保証しない非一意索引があります。

図2 主キーを利用した一意索引スキャン
(クリックで拡大します)

Oracle DatabaseとPostgreSQLの場合、いずれの索引も表とは異なるオブジェクトとして作成されます。図2のように、主キーを利用した一意索引スキャンの場合、一意索引のリーフ・ブロックから物理的な行の格納位置を示すアドレス情報を参照し、表を構成するデータ・ブロックにアクセスします。一方、MySQLの場合、行データは主キーによるクラスタ・インデックスのリーフ・ブロックに格納されているため、主キーを利用した一意索引スキャンでは、クラスタ・インデックスから行データを直接参照することができます。つまり、Oracle Databaseと、PostgreSQLでは一意索引のルート、ブランチ、リーフの各ブロックと表のデータ・ブロックの合計4ブロックへのアクセスが必要であるのに対し、MySQLではクラスタ・インデックスのルート、ブランチ、リーフの3ブロックで行データにアクセスできるため、主キーを利用した一意索引スキャンではMySQLに優位性があると考えられます。

非一意索引スキャン


図3 非一意索引の範囲走査
(クリックで拡大します)


非一意索引スキャンの場合も、図3のようにOracle Databaseと PostgreSQLの動作は一意索引スキャンと同様です。MySQLの場合、非一意索引のリーフ・ブロックには、索引を作成した列の値と、主キー値が格納されています。非一意索引スキャンでは、非一意索引のリーフ・ブロックから該当する主キー値が参照され、クラスタ・インデックス構造である表データに主キーでアクセスされます。つまり、Oracle Database、PostgreSQLでは、非一意索引のルート、ブランチ、リーフの各ブロックと表のデータ・ブロックの合計4ブロックへのアクセスが基本となるのに対し、MySQLでは非一意索引のルート、ブランチ、リーフ、クラスタ・インデックスのルート、ブランチ、リーフの6ブロックで行データにアクセスすることになるため、非一意索引スキャンではOracleDatabaseや PostgreSQLに優位性があると考えられます。

表結合の方法


表結合とは、ある表の行データと関連する、もう一方の表の行データをつなぎ合わせる処理のことです。結合対象となる表同士には、結合のキーとなる情報を格納する列が存在し、結合キーの列値が一致する行データ同士を、あたかも1つの表の行データのように扱うことができます。表結合の方法には図4のようにネスティッド・ループ結合、ソート・マージ結合、ハッシュ結合があります。

図4 結合方法

ネスティッド・ループ結合は、結合の駆動軸となる外側の表の行データに一致する行を内側の表から見つけ出す方法です。外側の表の行データに一致する行を内側の表から見つける走査を繰り返すため、外側の表には、件数の少ない表を配置して繰り返し回数を少なくすること、内側の表の結合条件となる列には索引を作成し、索引スキャンを採用することがネスティッド・ループ結合を効率化させるポイントです。ソート・マージ結合やハッシュ結合は、主に結合結果の行ソース同士を結合させる必要が生じるなど、索引を利用した結合を行うことができない場合や、索引を利用する結合が適切ではない場合に、効率的に結合を行う方法です。

Oracle Database、PostgreSQLは、ネスティッド・ループ結合、ソート・マージ結合、ハッシュ結合が実装されていますが、MySQLはネスティッド・ループ結合のみ実装されているため、結合結果の行ソース同士を結合しなければならない多数表の結合の場合、Oracle DatabaseやPostgreSQLに優位性があると考えられます。

終わりに


主なアクセス・パスと結合方法だけにフォーカスして、Oracle Database、PostgreSQL、MySQLの違いを説明しましたが、同じRDBMSでも個性があり、適用領域が少しずつ異なることがわかると思います。

図5 結合方法と結合順序評価


例えば、MySQLのinnodbストレージ・エンジンでは、表は主キーを用いたクラスタ・インデックス構造であるため、主キーによるデータ操作に向いており、その特性を踏まえてデータ・モデルとSQLを設計すると期待した効果が得られます。一方、多数表の結合処理や副問い合わせを含む処理などは、アクセス・パスや結合方法が限られているのでMySQLの良さを発揮することが難しくなります。そのため、MySQLでは参照負荷を分散できるレプリケーション構成と合わせて、WebのバックエンドのデータベースとしてMySQLの特性を考慮したアプリケーションを開発しているケースが多いようです。

PostgreSQLはMySQLと比べるとOracle Databaseと類似した物理構造と索引アクセス、結合方法が実装されているため、より幅広く汎用的に利用できるRDBMSであると言えます。Webのバックエンドのデータベースとしても利用できますが、PostgreSQLのアクセス・パスの特性を考える場面は少なく、社内システムや業務システムなど、既存の商用RDBMSと同じような感覚で利用できるのが特長です。

Oracle Databaseは様々な用途で利用されているデファクト・スタンダードであり、実装されているアクセス・パスも多く、大量データ、大量の同時実行ユーザを扱うことを前提としたアーキテクチャが採用されているため、万能型で大規模向けRDBMSであると言えます。

RDBMSの採用ポイントは多岐にわたりますが、アクセス・パスでの適材適所を考えた場合、様々なタイプのアプリケーションからアクセスされるミッション・クリティカルな基幹システムのデータベースはOracle Database、特定業務の業務システムなどはPostgreSQL、主キー走査を主体としたアプリケーションを設計できるシステムの場合はMySQLを採用するなどの棲み分けが可能です。

また、参照負荷や更新負荷を分散させたい各サービスのフロントDBとしてMySQLやPostgreSQLを複数ノードに配置し、バックエンドのDBとしてOracle Databaseを採用することでシステム全体のワークロードを低コストで拡張、縮小できる柔軟性のある仕組みを実現できます。このように、適材適所でRDBMSの活用を検討してはいかがでしょうか。

  • Postgres Plus は、EDB Postgres の旧製品名です。

執筆者紹介

岸和田 隆(Takashi Kishiwada)

株式会社アシスト データベース技術本部

アシスト入社後、Oracle Database の研修講師、フィールド・ サポート、新バージョンの検証を経て、2007年 自社ブランド 「DODAI」の準アプライアンス製品の企画・開発、2009年 PostgreSQL、2011年 EDB Postgres、MySQL / MariaDB の事業立上を担当。 現在は「データベースのアシスト」を目指した活動を行っている。

岸和田の紹介記事はこちら

株式会社アシスト ソフトウェア・リサーチ・センターについて

ソフトウェア・リサーチ・センターはアシストの組織を横断するメンバーから構成され、アシストの特徴を活かした中立的な立場でのソフトウェア製品や市場動向の調査を行っています。


※本稿は弊社が信頼できると判断した情報源に基づいて執筆していますがその情報の正確性、完全性を保証するものではありません。また本稿に記載された、弊社意見、予測などは本稿作成時点における弊社の判断であり今後予告なく変更されることがあります。
※記載した製品名および社名は、各社の商標または登録商標です。


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る