データベースエンジン

最新のDBMSの多くは、同じデータベース内で複数のストレージエンジンをサポートしている。たとえば、 MySQLはInnoDBとMyISAMの両方をサポートしている。

ストレージエンジンにはトランザクション処理をサポートするものとしないものがある。

エンジンの種類には以下のようなものもある。

• 組み込みデータベースエンジン
• インメモリデータベースエンジン

データベース内の情報は、ハードウェアのプロパティを指定して効率的に読み書きできるストレージ内のデータ構造としてレイアウトされたビットとして保存される。通常、ストレージ自体は、データベースを含むストレージを広範囲に利用するさまざまな領域の要件を満たすように設計されている。動作中のDBMSは、それぞれのレイアウト方法で、常に複数のストレージの種類（メモリ、外部ストレージなど）を同時に利用する。

原則として、データベースストレージは線形アドレス空間と見なすことができ、データのすべてのビットがこのアドレス空間に一意のアドレスを持つ。実際には、アドレスのごく一部のみが初期参照ポイントとして保持される（これにもストレージが必要）。ほとんどのデータは、変位計算（参照ポイントからのビット単位の距離）と、必要なデータアクセス操作に最適化された効果的な方法ですべての必要なデータへのアクセスパス（ポインターを使用）を定義するデータ構造を使用した間接参照によってアクセスされる。

データベースは、動作中、複数のタイプのストレージに同時に存在し、ストレージ階層を形成する。現在のコンピューターの性質上、DBMSをホストするコンピューター内のデータベース部分のほとんどは、揮発性ストレージに存在する（部分的に複製される）。処理/操作されているデータ（データベースの一部）は、プロセッサ内、場合によってはプロセッサのキャッシュに存在する。これらのデータは、通常はコンピュータバス（これまでのところ、通常は揮発性ストレージコンポーネント）を介してメモリから読み取られたり、メモリに書き込まれたりする。コンピュータメモリは、通常、標準のストレージインターフェイスまたはネットワーク（ファイバチャネル、 iSCSIなど）を介して、外部ストレージとの間でデータを通信する（転送される）。一般的な外部ストレージユニットであるストレージアレイは、通常、揮発性で高速なDRAMのような高速キャッシュから、フラッシュドライブや磁気ディスクドライブ（不揮発性）のような、より低速な標準インターフェイスを介した接続まで、独自のストレージ階層を持つ。ドライブは、さらに低速の、磁気テープのようなすぐにアクセスできる場所が最も少ない部類の大規模データベース、つまりデータベースバックアップ世代に接続できる。

通常、ストレージの速度と価格の間には相関関係があり、より高速なストレージは通常、揮発性である。

データ構造は、明確に定義された方法でデータを埋め込む抽象的な構造である。効率的なデータ構造により、効率的な方法でデータを操作できる。データ操作には、さまざまなモードでのデータの挿入、削除、更新、および取得が含まれる。特定のデータ構造型は、特定の操作では非常に効果的であり、他の操作ではそうならない。データ構造型は、DBMSの開発時に、含まれるデータ型に必要な操作に最適になるように選択される。特定のタスク用に選択されたデータ構造型は、通常、それが存在するストレージの種類（たとえば、アクセス速度、アクセスされるストレージチャンクの最小サイズなど）も考慮に入れる。一部のDBMSでは、データベース管理者は、パフォーマンス上の理由から、データ構造のオプションからユーザーデータを含めるように柔軟に選択できる。データ構造には、データベースのパフォーマンスを調整するための選択可能なパラメーターがある場合がある。

データベースは、多くのデータ構造タイプでデータを格納できる^[1]。 一般的な例は次の通りである。

• 順序付けされた/順序付けられていないフラットファイル
• ハッシュテーブル
• B+木
• ISAM
• ヒープ

従来の行指向とは対照的に、関係データベースは、特定の構造にデータを格納する方法において、列指向または相関型にすることもできる。

一般に、通常一緒に使用されるさまざまな型のデータベースオブジェクトが「クラスター化」されて近接するストレージに配置されると、パフォーマンスが大幅に向上する。これにより、通常、最小限の入力操作でストレージから必要な関連オブジェクトを取得できる（それぞれがかなり時間がかかる場合がある）。インメモリデータベースの場合でも、メモリ内の入出力操作に大きなキャッシュを一般的に使用するため、クラスタリングによってパフォーマンスが向上し、同様の動作が得られる。

たとえば、在庫のある「アイテム」のレコードを、それぞれの「注文」レコードすべてとクラスター化すると便利な場合がある。特定のオブジェクトをクラスター化するかどうかの決定は、オブジェクトの使用率統計、オブジェクトサイズ、キャッシュサイズ、ストレージの種類などに依存する。

インデックス作成は、一部のストレージエンジンがデータベースのパフォーマンスを向上させるために使用する手法である。多くの種類のインデックスは、クエリを実行するときにすべてのエントリを調べる必要性を減らす点が共通である。大規模なデータベースでは、これによりクエリの時間/コストを桁違いに削減できる。インデックスの最も単純な形式は、本の裏にあるインデックスと同様に、エントリの場所への隣接する参照を使用して二分検索を使用して検索できる値のソートされたリストである。同じデータに複数のインデックスを付けることができる（従業員データベースは、姓と雇用日でインデックスを付けることができる）。

インデックスはパフォーマンスに影響するが、結果には影響しない。データベース設計者は、アプリケーションロジックを変更せずにインデックスを追加または削除できるため、データベースの拡張やデータベースの使用状況の変化に伴うメンテナンスコストを削減できる。インデックスはデータアクセスを高速化できるが、データベース内のスペースを消費するため、データが変更されるたびに更新する必要がある。したがって、インデックスはデータアクセスを高速化できるが、データの保守は遅くなる。これらの2つの属性は、特定のインデックスがコストに見合うかどうかを決定する。

• MySQL Storage Engine Architecture, Part 3: Details and Comparison
• MySQL管理者のバイブル第11章「ストレージエンジン」