スポンサーリンク
TechGO（テックゴー）

【応用情報技術者試験】データベースを学ぼう！　　　　　~第7章~DBMS

DBMS（データベース管理システム）は、データの登録・検索・更新・削除を効率的かつ安全に行うためのソフトウェアです。利用者は直接データを操作する代わりに、SQL言語などを用いてDBMSへ命令し、大量のデータを整合性を持って管理します。MySQL, Oracle, PostgreSQLなどが代表的です。 

DBMSの主な機能

  • データ定義機能: データの構造（テーブルやデータ型）を設定する。
  • データ操作機能: データの検索・追加・更新・削除を行う。
  • データ制御機能: アクセス権限の管理や同時接続の管理（トランザクション処理）。
  • 障害回復機能: システム障害時にデータを保護・バックアップする。

画像参照：https://www.nttdata.com/jp/ja/trends/data-insight/2023/1219/

ACID

ACIDは、トランザクション処理においてデータの一貫性と信頼性を保証する4つの特性（原子性、一貫性、独立性、永続性）を備えたシステムです。銀行システムなどのデータの整合性が不可欠な環境で利用され、データの矛盾を防ぎます。 

ACIDの4つの特性

  • Atomicity（原子性）: トランザクション内の操作は「すべて実行」または「一つも実行されない」のどちらかの状態になること。
  • Consistency（一貫性）: トランザクション実行前後でデータの整合性が保たれ、定義された制約に違反しないこと。
  • Isolation（独立性）: 複数のトランザクションが同時に実行されても、互いに影響を受けないこと。
  • Durability（永続性）: コミットされたトランザクション結果は、システム障害が起きても失われないこと。

2相コミットメント制御

2相コミットメント（2PC：Two-Phase Commit）は、分散データベース環境において、複数のサイトにまたがるトランザクションの整合性（原子性・一貫性）を保証する技術です。中央の管理者（コーディネーター）が準備（第1相）と決定（第2相）の2段階で各拠点にコミットを指示し、全拠点の一斉確定か全取り消しを確実に行います。 

画像参照：https://itmanabi.com/2phase-commit/

2相コミットの仕組み（詳細）

  • 第1相：準備フェーズ
    • コーディネーターが各参加者（ノード）に「コミット可能か」を問い合わせます。
    • 各参加者は更新内容をログに記録し、コミット可能なら “Yes” (Ready状態)、不可能なら “No” (Abort) を返します。
  • 第2相：コミットフェーズ
    • コーディネーターは、全参加者から “Yes” を受け取った場合のみ、全員に「コミット（確定）」を通知します。
    • 1つでも “No” がある、または返答がない場合、全体を「ロールバック（取り消し）」に確定し、安全のためその旨を通知します。 

メリットと注意点

  • 整合性: 分散したデータが一部だけ更新される「不整合」を防ぐ。
  • デメリット: 全員の一致を待つため、通信コストが高く、ロック期間が長くなるためパフォーマンスが低下する可能性があります。 

銀行振込などの複数データベースをまたぐシステムで、全成功か全失敗かを保証するために不可欠な技術です。

同時実行制御

同時実行制御（コンカレンシーコントロール）は、データベースに複数のユーザーが同時にアクセス・更新を行う際、データの整合性（ACID特性）を保つ機能です。主な手法に、ロック（排他制御）を用いて競合を防ぐ方法や、データの複数バージョンを保持して読み取りをブロックしないMVCC（多版同時実行制御）があります。 

主な同時実行制御の方式

  • ロック（排他制御）: データを更新する際にロックをかけ、他のトランザクションのアクセスを制限し、衝突を未然に防ぐ方式。
  • MVCC（Multi-Version Concurrency Control）: データを更新する際、上書きせずに新しいバージョンを作成する方式。読み取り処理が書き込みの完了を待つ必要がないため、特にPostgreSQLやOracleなどの現代的なDBMSで主流。
  • タイムスタンプ順序付け: トランザクションにタイムスタンプを付与し、古い順に処理を行うことで矛盾を防ぐ。 

同時実行制御の必要性
もし制御を行わないと、以下のような問題が発生し、データの一貫性が失われます。

  • ダーティライト: コミットされていないデータを他のトランザクションが更新してしまう。
  • ファントムリード: 同じクエリを再度実行すると結果が変わってしまう。

近年では、高速化のためにMVCC（多版同時実行制御）が標準的に利用されています。

共有ロック

共有ロック（Shared Lock、Sロック）は、データベースやファイルシステムで、複数の実行主体（トランザクション）が同時にデータを読み込み（参照）することを許可しつつ、同時書き込み（更新・削除）や排他ロックを禁止する、データ整合性を保つためのロック方式です。 

主な特徴と詳細

  • 読み込みは同時OK: 同じデータに対して、複数のトランザクションが同時に共有ロックを取得し、読み取りを行うことができます。
  • 書き込みは禁止: 共有ロックされているデータに対して、他のユーザーが書き込み（UPDATE/DELETE）や排他ロック（Xロック）を取得することはできません。
  • 利用シーン: 主にデータの読み取り（SELECT）を実行する際、処理中に他の人にデータを変更されたくない場合に利用されます。
  • 対比機能: データを更新する際に使用され、他のユーザーの読み書きを一切禁止する「排他ロック」と対になる概念です。 

共有ロックは、データの一貫性を保ちながら、参照効率を最大化したいシーンで非常に有効です。

占有ロック

占有ロック（排他ロック/Xロック）は、データベースやファイルシステムで、あるトランザクションがデータを更新する際に使用され、その間は他の全ユーザーからの「読み取り」と「書き込み」を完全に禁止する仕組みです。ロックされたデータは更新が完了（コミット）されるまで保護され、データの一貫性を保持します。 

占有ロックの概要

  • 役割: 更新・削除（UPDATE/DELETE）の際に使用。
  • 他のロックとの関係: 別の占有ロックも共有ロックも、そのレコードにかけることはできない。
  • 影響: 他のタスクは、処理終了（コミット）まで待ち状態（ロック解除待ち）となる。 

共有ロックとの違い

  • 占有ロック: 更新用。他者は読めないし、書けない。
  • 共有ロック: 参照用。他者は読めるが、更新（占有ロック）はできない。 

主な使用シーン

  • SQLの SELECT ... FOR UPDATE や、明示的なデータ更新の際。
  • レコード単位、またはテーブル単位のロック。

注意点

  • 適切に管理しないと、双方が相手のロック解除を待つ「デッドロック」が発生する。
  • 処理はトランザクション終了時に自動で解除される。

デッドロック

デッドロック（Deadlock）とは、複数の処理（プロセスやスレッド）が互いに相手の保持する資源（データやメモリ領域）の解放を待ち続け、結果としてどの処理も進まなくなる「行き詰まり」や「膠着状態」を指すIT用語です。デッドロックの発生は、主にデータベースなどの排他制御において、2つ以上の処理が互いに相手のロック解除を待つ状況が原因となります。 

主な特徴と発生条件

  • 発生メカニズム: スレッドAが資源1をロックし資源2を待つ間に、スレッドBが資源2をロックし資源1を待つ、といった循環的な待ちが発生します。
  • 4つの必要条件: 「相互排他」「保持・待機」「不可分性（横取り不可）」「循環待機」の4つの条件が揃うとデッドロックが発生します。
  • 解決・回避策:
    • 順序の統一: ロックを取得する順番をすべてのプログラムで統一する。
    • 範囲の縮小: ロックする資源の粒度（範囲）を細かくする。
    • タイムアウト: 一定時間でロックを諦める設定を入れる。

MVCC（Multi-Version Concurrency Control）

MVCC（多版同時実行制御）は、データベースでデータ更新時に新旧バージョンを保持し、読取処理が書込処理のロック待ちをせずに一貫したデータを取得できる技術です。読み取りと書き込みが競合せずスループットが向上するため、PostgreSQLやMySQLなどで採用されています。 

主な特徴と仕組み

  • 読み取りと書き込みの非ブロッキング: 書き込み（UPDATE/DELETE）が行われても、読み取り（SELECT）は古いバージョン（スナップショット）を参照するため、処理待ちが発生しません。
  • バージョニング: データ行の更新時、既存のデータを上書きせず、新しいバージョンを作成して古いものを保持します。
  • システムの一貫性: トランザクション開始時点でのデータの「スナップショット」を参照するため、実行中に他からの更新があっても結果が安定します。
  • ゴミ掃除: 不要になった古いバージョンは、PostgreSQLのVACUUMのような仕組みで定期的に削除・整理する必要があります。 

主な利点

  • 高並行性: 読取専用クエリが頻繁なシステムで高いパフォーマンスを発揮します。
  • 整合性の維持: 複雑なクエリでも、一貫性のあるデータセット上で実行されます。
  • ロック競合の削減: 従来のロック手法と比較して、競合が少ないです。 

適用例

  • PostgreSQL: MVCCを利用し、行の表示/非表示をトランザクションID（xmin/xmax）で管理しています。
  • MySQL (InnoDB): データの変更履歴をアンデューログ（undo log）に保持し、MVCCを実現しています。
  • その他: Oracle、SQL Server、MariaDB、TiDBなど多くのモダンなデータベース。

障害回復

DBMSの障害回復は、ログファイル（更新前/更新後イメージ）とバックアップを用いて、障害直前の整合性のある状態へ戻す機能。主に「ロールフォワード（バックアップ＋更新後ログ）」でコミット済みデータを復旧し、「ロールバック（更新前ログ）」で未コミットの不正データを破棄する。 

主な障害と回復方法

  • 媒体障害（ディスク故障）: バックアップからリストアし、ログで最新までロールフォワード。
  • システム障害（停電・OS異常）: チェックポイント（ディスクへの確定タイミング）以降のログを使い、ロールフォワード（コミット済）とロールバック（未コミット）を実施。
  • トランザクション障害: 該当するトランザクションのみをロールバック（処理取り消し）。 

キーワード

  • チェックポイント: ログとデータベースの同期タイミング。
  • WAL（Write Ahead Logging）: データ反映前にログを記録するプロトコル。

ロールフォワード

ロールフォワード（Roll-forward）とは、データベースの物理障害などでデータが破損した際、最新のバックアップデータに更新ログ（ジャーナルファイル）を再適用し、システムが停止した直前の状態までデータを復元する、前進復帰と呼ばれる回復手法です。 

ポイント

  • 目的: 障害直前の状態への復旧。
  • 必要なもの: 障害前の「バックアップファイル」＋「更新後ジャーナルファイル（ログ）」。
  • 適応シーン: 物理的な故障、データ破損の際。
  • 用語: ロールバック（処理を取り消す）と対になる言葉。 

動作手順

  1. 破損したデータベースの代わりに、最新のバックアップをリストア（書き戻し）する。
  2. その後のジャーナル（更新ログ）を適用し、コミット（確定）済みのトランザクションを再現する。 

主に、コミット済みのデータを完全に復旧させ、トランザクションの原子性を保証するために用いられます。

ロールバック

ロールバック（Rollback）とは、システム障害やデータ更新の失敗時に、処理を中断して、正常に動作していた以前の時点までデータを巻き戻して復旧させる機能のことです。IT分野、特にデータベース処理やゲームのサーバー管理において、データの不整合を防ぐ目的で利用されます。 

主な特徴・用途

  • データの安全性確保: トランザクション処理中にエラーが発生した際、データが中途半端な状態になるのを防ぎ、更新前の正常な状態に戻す。
  • 利用場面: データベース更新の失敗、ソフトウェアアップデート後の不具合、ゲームサーバーの障害復旧など。
  • 仕組み: 事前にログを保存し、そのデータを使用してコミット（確定）される前の処理を取り消す。
  • 類似機能: 障害発生時点まで戻して再適用する「ロールフォワード」とは対照的に、過去の状態に「巻き戻す」動作。

ロールバックとロールフォワードの違い

画像参照：https://it-life.net/term/rollback-rollforward/

チェックポイント

DBMSのチェックポイントとは、メモリ（RAM）上の未確定データ（ダーティページ）をストレージ上のデータファイルへ定期的に一括書き込みし、ログファイルと同期させる処理です。障害時の復旧（リカバリ）範囲を最後のチェックポイント以降に限定し、高速なロールフォワード・ロールバックを可能にするデータ保護機能です。 

概要と機能

  • 役割: メモリとストレージの不一致を解消し、システム障害発生時に最新状態への復旧を効率化する。
  • 動作原理: メモリ上の更新データ（ダーティページ）をディスクに書き込み、ログファイルに「この時点まで書き込んだ」という情報を記録する。
  • 頻度: 通常は一定間隔（数分ごと、またはトランザクション量依存）で自動実行される。
  • メリット: 障害発生時にチェックポイントより前のデータファイルが確実な状態であることが保証されるため、全てのログを再適用する必要がなく、復旧時間が短縮される。 

主な技術要素

  • WAL（Write-Ahead Log）: 変更データをデータファイルに書き込む前に、必ずログファイルを先行して更新する仕組み。
  • スナップショット: データベースシステムにおける一貫性のある既知の状態。
  • 非ブロッキング・チェックポイント: データベース操作を停止させずにバックグラウンドで処理を行う方式。

ストアドプロシージャ

ストアドプロシージャは、複数のSQL文をデータベース側に保存し、一つのプログラムのように呼び出せる機能です。処理を高速化し、ネットワーク通信量を削減、セキュリティ向上にも貢献する。複雑なデータ処理の自動化や、アプリケーション側での冗長なSQL記述を回避するのに有効です。 

主な利点

  • パフォーマンス向上: コンパイル済みのため、個別にSQLを実行するより高速。
  • ネットワーク負荷軽減: 複数SQLを一度に送受信するため、クライアント・サーバー間の通信量が減少。
  • 処理の一元化・保守性: DBにロジックをまとめるため、アプリ側がシンプルになり、変更も容易。
  • セキュリティ: DBへの直接アクセスを制限し、ストアド経由の安全な処理が可能。 

ストアド（ストアドルーチン）
SQLの命令群をひとまとめにし、データベース側に保存するプログラム機能です。

注意点・デメリット

  • ベンダー依存: SQL Server（T-SQL）やOracle（PL/SQL）など、DB製品ごとの独自言語で記述するため、他システムへの移行が困難。
  • DBサーバーの負荷: 複雑な処理を増やしすぎると、DB側の計算資源（CPU・メモリ）が圧迫される。 

利用シーン

  • 複数のテーブルにまたがる複雑なデータ操作
  • 定期的なデータバッチ処理や集計
  • セキュリティ要件の高いデータ更新 

通常のSQL文が1つ1つの操作を都度送信するのに対し、ストアドプロシージャは事前定義された「手順書（レシピ）」をサーバーに保持させ、実行するイメージです。

コメント